Como você aborda o design do banco de dados? [fechadas]

Sou principalmente um desenvolvedor web e tenho alguns projetos pessoais que quero iniciar.

Uma coisa que está me incomodando é o design do banco de dados. Passei pela normalização de banco de dados da escola e coisas assim, mas isso foi há alguns anos e nunca tive experiência com o design de banco de dados relacional, exceto a escola.

Então, como você aborda o banco de dados de uma perspectiva de aplicativo da web? Como você começa e o que procura? O que são sinalizadores de cautela?

O melhor livro que eu já comprei sobre design de banco de dados foi Design de Banco de Dados para Meros Mortais, de Michael Hernandez ISBN: 0-201-69471-9. Listagem da Amazon Notei que ele tem uma terceira edição.

Link para terceira edição

Ele o orienta por todo o processo (do início ao fim) do design de um banco de dados. Eu recomendo que você comece com este livro.

Você tem que aprender a ver as coisas em grupos ou pedaços. O design do banco de dados possui blocos de construção simples, assim como a programação. Se você obtiver uma compreensão completa desses componentes básicos simples, poderá abordar qualquer design de banco de dados.

Na programação você tem:

• Construções If
• Se Else Constrói
• Loops do While
• Fazer até loops
• Construções de caso

Com bancos de dados você tem:

• Tabelas de dados
• Tabelas de pesquisa
• Relações individuais
• Um para muitos relacionamentos
• Muitos para muitos relacionamentos
• Chaves primárias
• Chaves estrangeiras

Quanto mais simples você melhorar as coisas. Um banco de dados nada mais é do que um local onde você coloca dados em cubículos. Comece identificando o que são esses buracos de cubos e que tipo de material você deseja.

Você nunca criará o design de banco de dados perfeito na primeira vez que tentar. Isto é um fato. Seu design passará por vários aprimoramentos durante o processo. Às vezes, as coisas não parecem aparentes até você começar a inserir dados e então você tem um momento ah ha .

A web traz seus próprios conjuntos de desafios. Problemas de largura de banda. Apatridia. Dados incorretos de processos que iniciam, mas nunca são concluídos.

Eu faço programação orientada a objetos e design de banco de dados (principalmente transacional, mas alguns OLAP) e, para as minhas circunstâncias, há muitos temas recorrentes (pelo menos com OLTP).

Praticar a normalização 3nf me ajuda a praticar alguma variante do princípio da responsabilidade única. Uma tabela deve representar um conceito em seu sistema - e os conceitos devem estar relacionados entre si, de modo que eles tentem imitar a realidade; por exemplo, se estou construindo um sistema em que um cliente pode ter 0 ou várias atividades, crio uma tabela de clientes e uma tabela de atividades. A tabela de atividades possui um relacionamento de chave estrangeira com a tabela Customer. Ao criar procedimentos armazenados, certifique-se de usar uma junção externa para ingressar no Cliente e na atividade, porque o requisito comercial de que um Cliente possa ter 0 atividades.

Também atento a oportunidades de extensibilidade usando tabelas de ponte (link). Por exemplo, se eu estivesse tentando representar uma regra de negócios em que um livro pudesse ter um número ilimitado (variável) de autores, eu criaria uma Tabela de livros, uma tabela de autor e uma tabela de ponte / link com referências de chave estrangeira a ambos. Livro e Autor.

Além disso, uso chaves substitutas em todas as tabelas (normalmente colunas de identidade com auto-incremento, mas talvez Guids - a desvantagem dos guias no código é que eles ocupam mais espaço de memória que um número inteiro simples) e evito depender de chaves naturais para o meu pesquisas (exceto com tabelas Bridge / Link). Por padrão, também crio índices em colunas de chave estrangeira comuns e reviso periodicamente os procedimentos armazenados / consultas do sistema para otimizar estratégias de indexação. Outra estratégia de indexação que eu uso é procurar lugares no meu código onde construo uma coleção com base em uma coluna de pesquisa e adicionar índices apropriados às colunas de pesquisa.

Primeiro, projeto meu esquema do banco de dados e, em seguida, uso um ORM para criar os objetos a partir dele. Eu sou um pouco velha escola assim; Não confio em ORMs para criar um esquema de banco de dados inteligente e eficiente. Esse é o trabalho dos humanos e parte do ofício do design de software.

Eu achei o livro de Bill Karwin, SQL Antipatterns , muito útil para o planejamento de bancos de dados. O argumento mais abrangente é que o banco de dados oferece muitas oportunidades para proteger a integridade e a significância de seus dados e que é um erro comum dos designers ignorar esses recursos por vários motivos tentadores. Considerar esses problemas desde o início e deixá-los informar que todo o design vale a pena e é melhor tentar encobrir as rachaduras mais tarde.

Prefiro usar um banco de dados que tenha restrições abrangentes para reforçar a lógica e a integridade dos negócios no nível do banco de dados. Muitas vezes, vejo o banco de dados como o aplicativo e qualquer coisa que o acesse como uma mera interface. Isso torna a adição de outras "interfaces" uma experiência mais agradável e direta e traz benefícios positivos para a segurança.

Também acho importante considerar a estrutura do banco de dados como uma entidade em mudança, em vez de assumir que você precisa envolvê-lo e selá-lo antes de iniciar qualquer outra coisa. Você deve planejar as alterações e acomodar o banco de dados em seu sistema de versão. Há um belo ensaio sobre isso: Design de Banco de Dados Evolucionário, de Martin Fowler & Pramod Sadalage (e também um livro inteiro sobre Sadalage, embora eu não tenha lido isso).

Por fim, questões periféricas de contas / funções de usuário, hardware / localização / conexão do host etc. são importantes e às vezes ignoradas. Lembre-se disso também ao planejar.

o design do banco de dados não pode ser feito completamente sem considerar como os dados serão usados, então aqui está uma pequena lista de etapas:

• escreva frases curtas capturando o relacionamento entre entidades
• desenhar um diagrama de entidade-relacionamento representando as frases
• criar um modelo de dados lógicos normalizado a partir do diagrama ER
• faça uma matriz CRUD para aplicativos e entidades
• use a matriz para verificar a cobertura do ciclo de vida de cada entidade
• extrair subschemas para cada aplicativo
• examine os caminhos de navegação nos subschemas para cada operação principal / CRUD
• considere os relatórios que serão necessários
• projetar o modelo de dados físicos com base em todos os itens acima; desnormalizar, particionar e usar esquemas em estrela, quando apropriado

Para projetar um banco de dados com sucesso, primeiro considere várias coisas:

• Quais dados eu preciso armazenar e como eles estão relacionados aos outros dados que eu armazeno. Como esses dados precisarão mudar com o tempo? Preciso ser capaz de ver um instantâneo a tempo (dessa ordem a partir de 2009) ou preciso apenas do que é atual (somente usuários ativos)?
• Como posso garantir que meus dados sejam significativos e mantenham significado ao longo do tempo (integridade dos dados)?
• Como posso garantir que o acesso aos dados seja rápido?
• Como posso manter meus dados seguros?

Portanto, antes de começar a projetar um banco de dados, você primeiro precisa aprender sobre a normalização e os recursos de um banco de dados usado para manter a integridade dos dados.

Então você precisa entender o ajuste de desempenho. Isso não é prematuro, o desempenho é o ponto crítico de falha da maioria dos bancos de dados e é muito difícil de corrigir uma vez que você possui milhões de registros.

E, finalmente, você precisa entender como proteger os dados e quais dados precisam ser protegidos e quais controles internos são necessários para garantir que os dados não sejam alterados com intuito malicioso ou para garantir que você possa acompanhar as alterações ao longo do tempo para descobrir quem e quando foi feita uma alteração e poder reverter para versões anteriores.

Também é útil ler um pouco sobre a refatoração de bancos de dados antes de iniciar, pois será necessário refatorar mais tarde e é útil saber como configurar as coisas para que você possa refatorar o mais facilmente possível.

Em geral, os dados sobrevivem ao aplicativo por muitos anos, é o coração do aplicativo e não devem ser considerados como um armazenamento de dados idiota que é principalmente irrelevante.

Em termos gerais, um bom design de banco de dados é um bom design de banco de dados - a grande questão para o uso da Web será como você acessa os dados e gerencia coisas que se pode considerar exigir um estado que basicamente a Web não possui.

Pensando nisso, minha abordagem é baseada em muita experiência ... mas, se você começa com um esquema ou objetos, está realmente tentando fazer a mesma coisa, ou seja, constrói um modelo utilizável de seus dados - para um número substancial de Nos projetos, é provável que exista uma relação bastante direta entre modelo e esquema (nem todos os casos e provavelmente não para todas as tabelas / objetos); portanto, é uma questão de construir um modelo decente a partir de onde você estiver confortável e trabalhando a partir daí.

Em termos de construção de um modelo decente - o @Tim o reduz para bancos de dados e, fundamentalmente, a construção de seu modelo de objetos será amplamente semelhante - o que é único, o que é uma hierarquia, onde existem muitos relacionamentos, etc. chegar a um banco de dados, certifique-se de fazer todas as coisas boas.

Além disso, verifique se você possui scripts ou ddl no código para permitir que você crie o esquema do zero e atualize à medida que faz alterações (o ddl no código é o meu método preferido - eu tenho um sistema e funciona).

Começo com um grande quadro branco e várias cores diferentes de caneta. Cores diferentes significam coisas diferentes. E eu apenas começo a desenhar. Geralmente, desenho coisas definidas em preto, coisas prováveis ​​em azul e coisas improváveis ​​em verde. Vermelho é para notas importantes. Eu apago e redesenho copiosamente. Penso em quais tipos de coisas eu preciso consultar e verifique se o modelo suporta isso. Se não, eu vou mexer até que faça.

Eventualmente, se o modelo ficar muito grande, eu o moverei para o Visio e trabalhará nas peças no quadro branco.

Por último, penso em pontos de extensão. O maior erro que vejo a maioria das pessoas cometendo é projetar seu banco de dados e depois dizer "Estou pronto com o banco de dados" e seguir em frente. Você nunca terminou o banco de dados. É provável que cada solicitação de alteração recebida vá até esse nível. Então pense em como adicionar isso. Pense em quais tipos de solicitações são prováveis ​​e veja se você pode conectá-las. Se você não pensa em extensibilidade, terá uma grande dívida de design quando essas solicitações de mudança surgirem.

Quanto a "SQL then ORM" ou vice-versa, isso é com você. Apenas certifique-se de que seu modelo faça uma boa base primeiro.

Projeto objetos primeiro e depois uso um ORM (como nHibernate) para criar o esquema. Isso me dá muito mais flexibilidade do que fazer o inverso.

O próximo passo é a otimização do esquema gerado.

Faz muito tempo desde que eu vi um projeto em que as tabelas do banco de dados foram projetadas primeiro.

Poucas coisas ainda não declaradas explicitamente até agora por outros bolsistas:

• É melhor ter o design do banco de dados feito por alguém profissional. Não há problema em aprender, é claro, mas eu não sugeriria a construção de um modelo médio ou grande se alguém não for bem versado em modelagem ou design de banco de dados. A razão para isso é que o custo de um projeto errado geralmente é muito alto.

• Conheça bem os objetivos do sistema e os requisitos do usuário. Sem conhecer os requisitos, você não pode projetar o modelo de dados correto.

• Saiba qual código fazer nos programas e qual código deixar o banco de dados cuidar. Isso é necessário para que você defina nulo, não nulo, etc. da coluna de dados corretamente. Isso também é necessário para que você especifique seu RI corretamente.

• Determine bem suas chaves primárias. Escolha teclas simples quando puder.

• Considere as necessidades de integração com outros aplicativos.

• Considere usar modelos de dados universais e siga os padrões do setor em nomes e tamanho da coluna de dados.

• Pense nas necessidades futuras (quando conhecidas e quando aplicáveis)

• Tenha seu modo revisado por outras pessoas.

• Use uma ferramenta para modelagem - uma ferramenta ERD ou UML.

• Revise e entenda o código DDL gerado. Não tome como garantido.