Padrões de banco de dados [duplicado]

Question

Essa pergunta já tem resposta aqui:

• Padrões de design de banco de dados relacional? 10 respostas

Alguém sabe de artigos/livros/etc.que documenta padrões para bancos de dados?Por exemplo, uma regra prática comum é que toda tabela deve ter uma chave primária e que a chave deve ser desprovido de conteúdo informativo.Então, eu queria saber se alguém escreveu um livro ou publicou artigos sobre padrões de design para projetar bancos de dados relacionais?

---

@ Caio,

Essa é a questão que um projetista de banco de dados precisa avaliar: qual é a provável estabilidade da estrutura do banco de dados?Dado um horizonte suficientemente longo, nada é estável.Ou, para dizer o contrário, dado um horizonte suficientemente longo, tudo está sujeito a mudanças.Uma chave substituta (em teoria) nunca deveria mudar seu significado porque, para começar, nunca teve significado.

Acho que a outra coisa a considerar nesse cenário de design específico é quem verá a chave primária?Se a chave primária for algo que os usuários finais realmente precisarão consultar, então faz sentido torná-la algo que eles possam entender.Mas não consigo pensar em muitos casos em que um usuário final precise ver uma chave primária;geralmente a chave primária está presente para permitir que o mecanismo do banco de dados acelere determinadas operações.

Meu pensamento original ao fazer a pergunta era encontrar padrões de design para design de banco de dados que fossem codificados por designers de banco de dados mais experientes do que eu, para, esperançosamente, evitar alguns erros facilmente evitáveis.Seria uma leitura interessante se alguém já tivesse codificado antipadrões de design de banco de dados.

Answer 1

Especificamente, em relação às chaves:Discordo veementemente da estranha ideia de que as chaves devem não ter significado.Em geral, considero uma base de dados uma coleção de fatos;assim que você começar a adicionar números arbitrários (como chaves geradas) e outras informações irrelevantes, isso deverá ser um sinal de alerta.Eu recomendo isso artisticamente por Joe Celko para saber mais sobre chaves.

Notas mais gerais:

Sugestões para designs de esquema/modelos de dados para diferentes negócios:Davi C.Feno:Padrões de modelo de dados:Convenções de pensamento bastante antigas, mas há uma razão pela qual ainda está impressa
http://www.dorsethouse.com/books/dmp.html

Talvez não muito parecido com um padrão, mas ainda assim muito bom:Stéphane Faroult, Peter Robson:A Arte do SQLhttp://oreilly.com/catalog/9780596008949/

Outro que posso recomendar:Vadim Tropashko:Padrões de design SQL – O guia especializado para programação SQLhttp://www.rampant-books.com/book_2006_1_sql_coding_styles.htm

Livro-texto sistemático sobre modelagem de dados:Graeme Simsion e Graham Witt, "Fundamentos para modelagem de dados"http://www.elsevierdirect.com/product.jsp?isbn=9780126445510

Talvez você esteja realmente procurando um "guia de estilo"?Eu nesse caso:Joe Celko:Estilo de programação SQLhttp://www.elsevierdirect.com/product.jsp?isbn=9780120887972

Answer 2

Livros de E. F.Codd e C.J.Data são as respostas mais óbvias.Não li este livro em particular, mas conheço os autores, provavelmente é muito bom.

Matemática Aplicada para Profissionais de Banco de Dados por Lexx de Haan e Toon Koppelaars.

Answer 3

Na verdade, acho que a regra geral é usar uma chave natural em vez de uma substituta sempre que possível...

Portanto, se eu tiver, por exemplo, uma tabela Invoice e uma tabela InvoiceDetail, provavelmente poderemos usar InvoiceNumber como nossa chave primária na primeira.Já existe em nossos dados e (presumo?) Seria único.Para a segunda tabela, provavelmente precisaremos de uma chave substituta - independentemente de ela estar associada ao número da fatura como composta ou não.

De qualquer forma, voltando à pergunta original...o link do hometoast deve começar.

-Kevin Fairchild

Answer 4

Para responder exatamente: sim.Existem toneladas de informações escritas sobre 'bom' design de banco de dados.Embora seu exemplo de regra prática seja certamente questionável.

Answer 5

Antipadrões SQL de Bill Karwin é muito fácil de ler (não seco) e explica em termos bastante claros uma série de diferentes armadilhas potenciais, como você pode usá-las e como/por que fazer as coisas corretamente.

Answer 6

Usar chaves primárias com significado comercial ("chaves naturais") certamente tem seus méritos, mas pode tornar a refatoração do seu banco de dados muito difícil.Tenha cuidado, especialmente se houver algum motivo para acreditar que a estrutura do banco de dados mudará com o tempo.