skillfactor-pipeline/adapters/claude/dist/database-administrator/competences/design-database-scheme.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/6c08403c-a5bb-4868-b8c2-b7d039c0e511	design database scheme	essential	15-1242.00	stackexchange	high	5	gemma3:27b (prompt-designed and spot-checked by Claude)	2026-07-10

design database scheme — Database Administrator

As a Database Administrator, 'design database scheme' isn’t just about knowing normalization rules – it’s applied problem solving daily. You’ll frequently be asked to translate business requirements into a functional data model. This means taking requests like “We need to track customer orders and their associated products” and turning that into tables (customers, orders, products), columns with appropriate datatypes, primary/foreign key relationships, and indexes for performance. A big part of the job is refactoring existing schemes too – optimizing slow queries often reveals design flaws needing correction. Think less 'blank canvas' and more 'ongoing renovation'.

Typical tasks involve using tools like database modeling software (ERwin, Lucidchart, draw.io) to visually represent the schema before implementing it in your RDBMS (SQL Server, PostgreSQL, Oracle, MySQL). You’ll write DDL scripts (CREATE TABLE, ALTER TABLE) and use the database's management interface for administration. A key skill is knowing when to deviate from strict normalization – sometimes denormalization improves read performance at the cost of some data redundancy, a trade-off you need to justify. Remember that storing large binary files directly in the database (like documents or images) should be carefully considered; often filesystem storage with references in the DB is more practical.

Pitfalls include over-indexing (which slows down writes), creating overly complex relationships that are hard to query, and not anticipating future data needs. The Stack Exchange insights highlight this: avoid storing lists within tables – use junction tables for many-to-many relationships. Also, think carefully about indexing strategies; sequential integer indexes can become performance bottlenecks with frequent updates or reordering (like in a drag-and-drop interface). Good design prioritizes data integrity, query performance, scalability, and maintainability.

What 'good' looks like is a schema that’s well-documented, easy to understand, performs efficiently under load, and can adapt to changing business requirements without major overhauls. It means proactively identifying potential bottlenecks before they impact users, and being able to clearly explain the design choices you made to developers and stakeholders. A successful DBA doesn't just build a database; they build a foundation for reliable data-driven decision making.

Praxiswissen (Stack Exchange, 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 user is designing a database for a task assignment system and struggling with how to represent many-to-many relationships between people and tasks without creating unwieldy table structures with numerous redundant columns.

Instead of storing lists of IDs within tables or adding excessive columns, the best practice is to create a separate 'junction' or 'linking' table. This new table establishes explicit relationships by referencing primary keys from both related tables, adhering to database normalization principles. This approach allows for flexible and scalable many-to-many associations without data duplication or management overhead.

Source: Is it ever okay to use lists in a relational database? — answer by whatsisname, CC-BY-SA 4.0

The user needs an efficient way to store a reorderable list (wishlist) in a Postgres database for a large user base, avoiding performance issues when items are rearranged.

Instead of using sequential integer indexes that require updating many rows upon reordering, leverage string-based or sparsely populated integer indexing. This approach avoids the need to shift all subsequent item positions during drag-and-drop operations by providing ample 'space' between index values. The key is to design an indexing system where inserting a new position doesn’t necessitate modifying existing records.

Source: Storing a re-orderable list in a database — answer by Alexander Bird, CC-BY-SA 4.0

The asker is considering using an Entity-Attribute-Value (EAV) data model for product features that vary significantly between items, but is concerned about its reputation as a design anti-pattern.

While EAV offers flexibility to adapt to changing or diverse data requirements, it introduces significant performance risks and complexity. It's best avoided unless absolutely necessary because the potential for misuse and difficulty in querying outweighs the benefits, especially considering future maintainability by less experienced developers. Prioritize simplicity and well-defined schemas whenever possible.

Source: EAV - is it really bad in all scenarios? — answer by maple_shaft, CC-BY-SA 4.0

The questioner is concerned about minimizing the number of tables in a database design and wonders if fewer tables are inherently better.

Database design should prioritize correctness and functionality over simply reducing table count. The optimal number of tables depends on the specific data relationships and requirements; focusing solely on minimization can lead to poor structure. Don't worry about having 'too many' tables unless there’s a very unusual technical constraint, and consider denormalization only when performance issues arise.

Source: Is it necessary to create a database with as few tables as possible — answer by FrustratedWithFormsDesigner, CC-BY-SA 4.0

Weitere Anreicherung

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