skillfactor-pipeline/adapters/claude/dist/database-administrator/competences/sql-server.md

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/c062bab3-3ea0-4291-9220-a2d8fef4bead	SQL Server	optional	15-1242.00	stackexchange	high	5	gemma3:27b (prompt-designed and spot-checked by Claude)	2026-07-10

SQL Server — Database Administrator

For a Database Administrator (DBA), 'SQL Server' competence isn’t just knowing the language, it’s about being able to reliably operate and optimize Microsoft SQL Server databases in production. Daily tasks revolve around performance tuning – writing and analyzing queries using tools like SQL Server Management Studio (SSMS) or Azure Data Studio to identify bottlenecks, indexing strategies, and query plan optimization. You'll spend significant time monitoring server health (CPU, memory, disk I/O), proactively identifying potential issues before they impact users, and implementing high availability solutions like Always On Availability Groups. A key part is also managing security – user permissions, auditing changes, and ensuring data integrity.

Praxiswissen (Stack Exchange, CC-BY-SA 4.0)

The questioner was surprised to learn their firm discouraged using stored procedures, despite understanding their benefits like code reuse and security, and is seeking justification for this unusual practice within an Agile development context.

Maintaining a clear separation of concerns is crucial in large projects; business logic should reside consistently in one layer – typically the application/business object layer – to avoid complexity. While stored procedures can offer performance gains, they shouldn't be used indiscriminately. Instead, focus on strategically employing them only where performance bottlenecks are identified through testing and benchmarking.

Source: Stored Procedures a bad practice at one of worlds largest IT software consulting — answer by Eric J., CC-BY-SA 4.0

The user is questioning whether to establish a single database connection for an entire web page load or create a new connection for each query executed.

While intuitively reusing a single connection seems efficient, it introduces risks with stability and concurrent access. Modern frameworks like .NET utilize connection pooling – automatically managing a set of open connections that are borrowed and returned as needed. The best practice is to open a connection when required and properly dispose of it; the framework then handles returning it to the pool for reuse, simplifying management and improving reliability.

Source: Creating database connections - Do it once or for each query? — answer by pdr, CC-BY-SA 4.0

The asker is questioning an architect’s decision to remove foreign key constraints from a SQL Server database, arguing that these are data integrity features, not business logic, and also finds the stated goal of adopting a 'NoSQL approach' within a relational database system illogical.

Database constraints enforce data correctness and should be handled at the database level, separate from application-level business rules. Confusing these concepts leads to fragile systems prone to data corruption and maintenance headaches. While you can voice concerns, ultimately respecting poor technical decisions may require accepting the situation or seeking alternative employment.

Source: NoSQL within SQL Server — answer by Mason Wheeler, CC-BY-SA 4.0

A junior developer implemented a flexible validator using the strategy pattern in Java, but their manager wants all validation logic moved to SQL configuration (tables/stored procedures) to avoid code releases for every change.

Effective leadership involves understanding what needs to be built, not just avoiding development work. While configurable data should reside in databases, complex or algorithmically different logic rightfully belongs in the application code; attempting to implement all validation within SQL will create a far more complicated and unmaintainable system over time. It's important to distinguish between simple value changes (which should be configurable) and fundamentally new logical rules that require code updates.

Source: SQL as a means of avoiding "releases" — answer by Flater, CC-BY-SA 4.0

The user is confused about the subtle differences between JOIN, INNER JOIN, and FULL OUTER JOIN in SQL, suspecting a simple JOIN might be causing issues with their query.

In most SQL dialects, simply using JOIN is equivalent to specifying INNER JOIN; the keyword 'INNER' is redundant. The core distinction lies between inner and outer joins: an inner join only returns rows where there’s a match in both tables, while a full outer join includes all rows from both tables, filling in missing values with nulls when no match exists.

Source: JOIN vs. INNER JOIN and FULL OUTER JOIN — answer by Ryathal, CC-BY-SA 4.0

Weitere Anreicherung

Stage-2 source for future practitioner grounding: arXiv cs.SE (software-engineering preprints).