6b3b2abe4f
73 stackexchange-grounded, 516 model-knowledge (ESCO-seeded gemma3), 0 review_needed (calibration caveat documented). Adapters rebuilt with the full competence sets; final REPORT numbers; all verify checks pass. Known gap: engineering-manager lacks an ESCO package counterpart. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PDKeXvpT6tENSvyQGLV1Uq
2.7 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/c7d24594-0c11-4b27-9039-fe0bb903da8e | LINQ | optional | 15-1242.00 | model-knowledge | high | 0 | gemma3:27b (prompt-designed and spot-checked by Claude) | 2026-07-10 |
LINQ — Database Administrator
For a Database Administrator, LINQ isn't about writing applications with it – it’s about understanding how developers are accessing your databases. You won't typically be authoring complex LINQ queries directly, but you will encounter them in application logs, performance traces (like those from SQL Server Profiler or Extended Events), and potentially within stored procedure definitions if developers have embedded LINQ-to-Entities calls. Being able to 'read' LINQ translates to quickly diagnosing slow queries; recognizing inefficient data access patterns that are hammering your server; and understanding why a particular application is behaving the way it is.
Specifically, you’ll use LINQ knowledge to interpret execution plans generated from translated LINQ queries. LINQ-to-Entities (or similar) often generates complex SQL – knowing the original LINQ intent helps you decipher what the developer was trying to achieve and identify areas for optimization at the database level (indexes, statistics updates, query rewrites). You might also be involved in reviewing application code changes that heavily utilize LINQ to proactively spot potential performance bottlenecks before they hit production. Tools like SQL Server Management Studio (SSMS) are key here – you’ll use them to examine the generated SQL and its execution plan.
A common pitfall is assuming a slow query is always a database problem. LINQ's lazy evaluation can sometimes lead to N+1 select problems, where multiple small queries are executed instead of one efficient join. This looks like database load but originates in the application code. Good DBA practice with LINQ means being able to distinguish between these scenarios and communicate effectively with developers about how to improve their query structure before suggesting database changes.
What 'good' looks like is a DBA who can quickly triage performance issues, identify if they stem from inefficient LINQ usage (e.g., unnecessary data retrieval), and collaborate with development teams to resolve them. It’s about being a bridge between the application layer and the database engine, ensuring both work optimally together – not just knowing SQL but understanding how modern applications generate that SQL.
Weitere Anreicherung
Stage-2 source for future practitioner grounding: arXiv cs.SE (software-engineering preprints).