Simpler story (slide decks unread -> three-bullet status email), proper Claude-chat look with avatars and bubbles on both sides. Canonical trigger prompt switched to English everywhere (homepage, architecture, both adapter generators rebuilt) - V7 consistency green, all checks pass. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PDKeXvpT6tENSvyQGLV1Uq
2.9 KiB
esco_uri, esco_label, relation, onet_soc, source, confidence, qa_count, generator, generated
| esco_uri | esco_label | relation | onet_soc | source | confidence | qa_count | generator | generated |
|---|---|---|---|---|---|---|---|---|
| http://data.europa.eu/esco/skill/9cf681c7-89ec-470c-b651-7fe03786f586 | query languages | essential | 15-1242.00 | model-knowledge | high | 0 | gemma3:27b (prompt-designed and spot-checked by Claude) | 2026-07-10 |
query languages — Database Administrator
As a Database Administrator, 'query languages' isn’t about learning SQL once – it’s about mastering its nuances for performance, security, and data integrity. Daily tasks revolve around writing, optimizing, and troubleshooting queries (primarily SQL, but potentially NoSQL variants like MongoDB Query Language or SPARQL depending on the database systems managed). You'll be analyzing slow-running queries using tools like execution plans in SQL Server Management Studio, MySQL Workbench, or PostgreSQL’s EXPLAIN, identifying bottlenecks (missing indexes, inefficient joins), and rewriting them for speed. It also means understanding how different query structures impact resource usage – a poorly written query can cripple an entire database server.
Beyond basic data retrieval, you'll use queries extensively for administrative tasks: monitoring database health (checking table sizes, identifying long-running transactions), auditing changes (using triggers and audit trails accessed via SQL), performing backups/restores (often scripted with SQL commands), and implementing security policies (granting/revoking permissions based on query results). You'll frequently be asked to extract specific data sets for reporting or application needs, requiring complex joins, subqueries, and window functions. Knowing how to write queries that avoid locking issues is critical.
A common pitfall is writing queries that are functionally correct but perform terribly in production with large datasets. Another is failing to account for SQL injection vulnerabilities when building dynamic queries (especially those used by applications). Good DBA practice means not just getting the data, but doing so safely and efficiently – using parameterized queries, appropriate indexing strategies, and understanding database-specific optimization techniques. It also involves being able to read complex queries written by others (developers, analysts) and quickly understand their intent and potential impact.
Finally, staying current is key. SQL standards evolve, and different database vendors implement features differently. A good DBA continuously learns new query language features (like Common Table Expressions or JSON functions) and understands how to leverage them for improved performance and functionality. This isn't just about syntax; it’s about understanding the underlying data access methods and how the query engine works.
Weitere Anreicherung
Stage-2 source for future practitioner grounding: arXiv cs.SE (software-engineering preprints).