A continuación, les presento una serie de puntos a considerar al diseñar una base de datos, sin embargo, cabe decir que no hay una regla que indique que tiene que ser de tal manera o de otra, estos puntos les servirán a que su diseño tenga consistencia entre todas las entidades.
Tablas: Llamarla según la entidad a la que representa, algunos diseñadores optan por nombrar las tablas en singular pero no hay una regla fija para ello por lo que también podría ser en plural, lo más importante es usar un nombre con significado. Si la tabla tiene más de 2 palabras se pueden poner juntas en notación camelCase o snake_case.
Ejemplo: estudianteCurso ó estudiante_curso.
Si la tabla es una tabla muchos a muchos se deben de utilizar los nombres de las tablas que generan la relación, deberán de ir con guiones bajos, el guion nos ayudará a identificar las relaciones.
Ejemplo: users, costumers, students, products, orders, order_details, orderDetails, productCategories, product_categories.
Nota: En postgresql se recomienda usar nombres de tablas en minúsculas para evitar confusiones al momento de crear las tablas o al hacer consultas hacía una tabla.
Columnas: El campo/columna debe de ir en singular y si deseas agregar una segunda palabra para describir más el campo puedes hacerlo con la notación camelCase o snake_case.
Las llaves primarias pueden ir con el nombre de la tabla seguido de un guion bajo e id por ejemplo product_id
o simplemente puede ir id
, esto es más cuestión de gustos.
Las llaves foráneas en tablas pueden ir con el mismo nombre con el que fueron definidas en la tabla de origen (en caso de que haya sido nombrada nombretabla_id) si el nombre para llave es id
entonces lo recomendable sería colocar el nombre de la tablaorigen_id
.
Todas las llaves foraneas FK deben de tener relación con restricciones de updates en cascada y borrado restringido y deben de ser del mismo tipo de dato y longitud que la llave primaria a la que hace referencia.
Se trata de un conjunto de técnicas desarrolladas por Edgar Frank Codd con la finalidad de evita anomalías en las bases de datos, redundancia de datos y asegurar la integridad, se les denominó formas normales.
Sin normalizar: