Los mismos campos en la mayoría de las tablas

Question

En un prototipo de base de datos, tengo un conjunto de campos (como nombre, descripción, estado) que se requieren en varias tablas funcionalmente diferentes.

Estos campos siempre tienen la misma funcionalidad de usuario final para etiquetado, visualización, búsqueda, filtrado, etc. No son parte de una restricción de clave externa. ¿Cómo se debe modelar esto?

puedo pensar en las siguientes variantes:

• Cada tabla se lleva todos estos atributos. En este caso, ¿cómo los nombrarías? Lo mismo, en cada mesa, o con un prefijo de nombre de la tabla (como usrname, ProdName)

• los trasladan a una mesa de atributos, añadir una clave externa a las tablas "núcleo", haciendo referencia a Attributes.PK

• Como se indicó anteriormente, pero en lugar de una clave externa, use Attributes.PK como PK en la tabla principal correspondiente también.

Answer 1

Parece que podría estar llevando la idea de la normalización demasiado lejos. recuerde, es la idea de que está reduciendo la redundancia en su datos. su ejemplo parece indicar que le preocupa la "redundancia" en la metainformación del diseño de su base de datos.

en última instancia, sin embargo, user.name y user.description son funcionalidad diferente de product.name y product.description, y debe tratarse como tal. para status, depende lo que quieras decir con eso. es status solo un indicador de que un producto/registro del usuario está activo o no? si es así, entonces podría tener sentido dividirlo en una tabla diferente.

utilizando la información que ya ha proporcionado, si es "activo/expirado/borrado" no es más que una indicación de estado dentro de la base de datos, entonces yo definitivamente de acuerdo con una estructura de la tabla, así:

users   products   status 
    id    id    id 
    name    name    name 
    description  description 
    status_id  status_id 

sin embargo, Si status concebiblemente podría ser alterado para representar algo semánticamente diferente (es decir, para los usuarios, tal vez "Active/retirado/despedido", sugeriría que la división hasta prueba de futuro el diseño:

user_status  product_status 
    id    id 
    name   name 

en definitiva, a normalizar sus datos, no su base de datos desi gn.

Answer 2

La normalización suele ser la mejor práctica en cualquier base de datos relacional (dentro de lo razonable).

Si tiene campos como state (es decir, el estado dentro de un país), una tabla de referencia como "State" con (id, short_name, long_name, etc.) podría ser el camino a seguir, entonces cada registro Las referencias a un estado solo necesitan una columna state_id que, como mencionaste, es una referencia a un registro en la tabla State.

Sin embargo, en algunos casos no se requiere necesariamente la normalización de todos los datos, ya que simplemente complica las cosas, pero debería ser obvio dónde hacerlo y dónde no hacerlo.

Espero que esto ayude.

Answer 3

A menos que utilice el mismo nombre 0 descripción valores en las tablas, no debe normalizar esos datos. Los tipos de estado tienden a reutilizarse, por lo tanto, normalícelos. Por ejemplo:

order_status_types 
- id 
- name 
- description 

shipping_accounts 
- id 
- name 
- description 

orders 
- order_status_type_id 
- shipping_account_id 

preferences 
- shipping_account_id 

Answer 4

Daría a cada mesa su propio conjunto de columnas, incluso si tienen los mismos nombres y son lógicamente similares.

Si alguna vez tiene que cambiar una de las tablas agregando o eliminando algunas de estas columnas, o cambiando su tipo de datos, puede hacerlo solo en la tabla correspondiente, en lugar de averiguar cómo complicar su tabla de atributos compartidos.

Dar a cada mesa el control de sus propios atributos promueve Cohesion, lo cual es algo bueno. También evita su pregunta sobre la dirección de las teclas externas.

En cuanto a la denominación de columnas, no es necesario ni recomendable poner prefijos en los nombres de las columnas. Si alguna vez hace una combinación que da como resultado columnas del mismo nombre provenientes de dos tablas, use alias para distinguirlas.

Answer 5

Siempre he dado a cada tabla un código de 3 letras que luego uso en todos los nombres de campo. De esa manera en la tabla de productos tengo prdname, prddescription, prdstatus, y en el archivo del proveedor tengo venname, vendescription, venstatus. Cuando las cosas se unen, no hay necesidad de preocuparse por los mismos campos con nombre.

Por supuesto, todas las tablas tienen un campo llamado plain old id y la tabla del producto tendría un campo llamado veneid que hace referencia al campo id en la tabla del proveedor. En este caso, no pongo el prefijo prd porque venid tiene mucho sentido y no es ambiguo.