skillfactor-pipeline/adapters/claude/dist/database-administrator/competences/mysql.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/4da171e5-779c-4983-a76f-91c16751e99f	MySQL	optional	15-1242.00	stackexchange	high	5	gemma3:27b (prompt-designed and spot-checked by Claude)	2026-07-10

MySQL — Database Administrator

For a Database Administrator (DBA), 'MySQL' isn’t just knowing the software exists; it's about deep operational mastery. Daily tasks revolve around ensuring MySQL databases are highly available, performant, and secure. This means things like user access management (granting/revoking privileges), performance tuning via query optimization (using EXPLAIN to understand execution plans is key!), backup & recovery strategies (using tools like mysqldump, Percona XtraBackup, or replication setups), and monitoring database health with tools like Prometheus + Grafana or MySQL Enterprise Monitor. You'll be constantly analyzing slow query logs, identifying bottlenecks, and adjusting configuration parameters (my.cnf) to maximize throughput.

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

The user questions the need for databases when they can easily store and retrieve data using simple file serialization (like JSON), finding it faster and more straightforward.

While basic data storage works initially, databases offer significant advantages as projects grow in complexity. They provide powerful tools for querying, relating, and analyzing data efficiently, ensuring consistency and reliability through features like ACID compliance and fault tolerance. Utilizing a database leverages decades of development and optimization, offering scalability and concurrent access that simple file-based solutions cannot easily match.

Source: Why use a database instead of just saving your data to disk? — answer by Robert Harvey, 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 deciding whether to store user-uploaded files (1-10MB) directly within their MySQL database or store them on the filesystem and reference them with paths in the database, concerned about performance impacts.

While storing files in a database offers transactional consistency and simplifies backups, it significantly increases database size and maintenance complexity. Larger databases require more resources, specialized knowledge to manage, and can hinder portability. Storing files on the filesystem avoids these issues, offering simpler access and reducing database overhead, but requires careful management of file synchronization and potential orphan records.

Source: Is it a bad practice to store large files (10 MB) in a database? — answer by Thomas, CC-BY-SA 4.0

The questioner is deciding between traditional text-based logging (using log4net and MySQL) versus structured logging (Serilog/Bunyan with Fluentd/Elasticsearch) for a new application, weighing the benefits against implementation complexity.

Structured logging provides significant advantages in data analysis by preserving event types and individual data fields. While text logs require complex pattern matching to extract meaningful information, structured logs allow direct querying of specific properties (like quota values or usernames) without relying on fragile string searches. This capability becomes increasingly valuable as log volume grows and diagnostic needs become more sophisticated.

Source: Benefits of Structured Logging vs basic logging — answer by Nicholas Blumhardt, CC-BY-SA 4.0

The questioner debated with a hobby programmer about using SELECT * in database queries, believing it to be poor practice. They sought validation of their view and an explanation for why it's discouraged.

Relying on SELECT * creates brittle code vulnerable to schema changes; adding or removing columns can silently break applications or return unexpected data. Explicitly selecting only needed columns improves performance by reducing unnecessary data transfer, clarifies the query’s purpose for maintainability, and provides immediate feedback when database structure evolves – making debugging easier and preventing subtle errors.

Source: Why is "Select * from table" considered bad practice — answer by the baconing, CC-BY-SA 4.0

Weitere Anreicherung

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