Mesmos campos na maioria das mesas

Question

Em um protótipo de banco de dados, eu tenho um conjunto de campos (como nome, descrição, estado) que são necessários em múltiplos, funcionalmente diferentes tabelas.

Estes campos têm sempre a mesma funcionalidade do usuário final para a rotulagem, display, pesquisa, filtragem etc. Eles não são parte de uma restrição de chave estrangeira. Como isso deve ser modelada?

Eu posso pensar das seguintes variantes:

• Cada tabela recebe todos esses atributos. Neste caso, como você iria nomeá-los? O mesmo, em cada mesa, ou com um prefixo ao nome do quadro (como usrname, ProdName)

• Mover-los em uma tabela de atributos, adicionar uma chave estrangeira para as tabelas "core", fazendo referência Attributes.PK

• Como acima, mas em vez de uma chave estrangeira, use o Attributes.PK como PK na tabela núcleo respectivo bem.

Answer 1

parece que você pode tomar a idéia de normalização um pouco longe demais. lembre-se, é a idéia de que você está reduzindo a redundância em seus dados . seu exemplo parece indicar que você está preocupado com a "redundância" nas informações meta de seu projeto de banco de dados.

em última análise, no entanto, user.name e user.description são funcionalidade diferente da product.name e product.description, e devem ser tratados como tais. para status, depende do que você quer dizer com isso. é status apenas um indicador de registro de um produto / usuário ser ativo ou não? se assim for, então ele poderia fazer sentido para dividir isso com uma tabela diferente.

usando a informação que você forneceu, se "/ ativo expirado / excluído" é apenas uma indicação de estado no banco de dados, então eu definitivamente concordo com uma estrutura de tabela assim:

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

No entanto, se status poderia concebivelmente ser alterada para representar algo semanticamente diferente (ou seja, para os usuários, talvez "ativo / aposentado / despedido", eu sugiro divisão que até à prova de futuro o projeto:

user_status     product_status
  id              id
  name            name

Em suma, normalizar seus dados, não o seu projeto de banco de dados.

Answer 2

A menos que você use o mesmo nome ou descrição valores em mesas, você não deve normalizar os dados. tipos de status tendem a ser reutilizados, assim, normalizar os. Por exemplo:

order_status_types
- id
- name
- description

shipping_accounts
- id
- name
- description

orders
- order_status_type_id
- shipping_account_id

preferences
- shipping_account_id

Answer 3

A normalização é muitas vezes a melhor prática em qualquer banco de dados relacional (dentro da razão).

Se você tem áreas como estado (ou seja, o estado dentro de um país), em seguida, uma tabela de referência como "Estado" com (id, short_name, long_name etc ...) pode ser o caminho para ir, então cada registro que as referências um estado só precisa de uma coluna state_id que, como você mencionou, é uma referência a um registro na tabela de Estado.

No entanto, em alguns casos, a normalização de todos os dados não é necessariamente obrigatório, uma vez que apenas complica as coisas, mas deve ser óbvio onde fazê-lo e onde não fazê-lo.

Espero que isso ajude.

Answer 4

Eu daria cada tabela seu próprio conjunto de colunas, mesmo que tenham os mesmos nomes e são logicamente similar.

Se você precisar alterar uma das mesas, adicionando ou excluindo algumas dessas colunas, ou alterar seu tipo de dados, então você pode fazê-lo apenas na mesa onde ele pertence, em vez de descobrir como complicar a sua compartilhada mesa -attribute.

Dar a cada controle de tabela de seus próprios atributos promove Coesão , que é uma coisa boa. Ele também evita a sua pergunta sobre qual direção as chaves estrangeiras ir.

Quanto à nomeação de coluna, não é necessário ou aconselhável colocar prefixos em nomes de coluna. Se você nunca fazer uma junção que resulta em colunas de mesmo nome provenientes de duas tabelas, use aliases para distingui-los.

Answer 5

Eu sempre dado a cada mesa de um código de 3 letras que eu então usar em todos os nomes de campo. Dessa forma, na tabela de produtos que tenho prdname, prddescription, prdstatus, e no arquivo fornecedor tenho venname, vendescription, venstatus. Quando as coisas se juntaram, não há necessidade de se preocupar com mesmos campos nomeados.

É claro, as tabelas têm um campo denominado velho liso id e a tabela de produtos teria um Venid campo denominado que se refere ao campo id na tabela de fornecedor. Neste caso, eu não colocar o prd prefixo sobre ele, porque Venid faz todo o sentido e é nonambiguous.