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

14

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

Uma coisa que está me incomodando é o design do banco de dados. Eu passei por normalização de banco de dados da escola e coisas assim, mas tem sido um par de anos atrás e eu nunca tive experiência com design de banco de dados relacional, exceto para 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 você procura? Quais são as bandeiras de cautela?

    
por bron 10.11.2010 / 18:50
fonte

10 respostas

14

O melhor livro que eu já comprei sobre design de banco de dados foi Design de banco de dados para Mere Mortals por Michael Hernandez ISBN: 0-201-69471-9. Amazon Listagem notei que ele tem uma terceira edição.

Link para a terceira edição

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

Você precisa aprender a ver as coisas em grupos ou partes. O design do banco de dados tem blocos de construção simples, assim como a programação. Se você obtiver uma compreensão completa desses blocos de construção simples, poderá resolver qualquer projeto de banco de dados.

Na programação você tem:

  • se construções
  • Se mais construções
  • Do While Loops
  • Do Until Loops
  • Construções de caso

Com bancos de dados você tem:

  • Tabelas de dados
  • Tabelas de pesquisa
  • Relacionamentos de um para um
  • De um a muitos relacionamentos
  • Muitos para muitos relacionamentos
  • Chaves primárias
  • Chaves estrangeiras

Quanto mais simples você faz as coisas, melhor. Um banco de dados nada mais é do que um lugar onde você coloca dados em buracos. Comece identificando quais são esses buracos e o tipo de coisas que você quer neles.

Você nunca criará o design de banco de dados perfeito na primeira vez que tentar. Isto é um fato. Seu design passará por vários refinamentos 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 errados de processos que começam mas nunca são concluídos.

    
por 11.11.2010 / 00:42
fonte
11

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

Praticar 3nf normalização 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 uns com os outros, de modo que eles tentem imitar a realidade; Por exemplo, se eu estiver criando um sistema em que um cliente possa ter 0 ou muitas atividades, crie uma tabela de clientes e uma tabela de atividades. A tabela de atividades possui um relacionamento de chave estrangeira para a tabela Customer. Quando estou construindo procedimentos armazenados, asseguro-me de usar uma associação externa para ingressar no Cliente e na atividade, porque o requisito comercial de um Cliente pode ter 0 atividades.

Também estou 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 poderia ter um número ilimitado (variável) de autores, criaria uma Tabela de livros, uma tabela de autor e uma tabela de ponte / vínculo com referências de chave estrangeira para ambos Livro e Autor.

Além disso, uso chaves substitutas em todas as tabelas (geralmente colunas de identidade de incremento automático, mas talvez Guids - a compensação com guias no código é que elas ocupam mais espaço de memória do que um inteiro simples) e evito confiar em chaves para minhas pesquisas (exceto com Bridge / Link Tables). Por padrão, também crio índices em colunas de chave estrangeira comuns e reviso procedimentos / consultas de sistema armazenados de tempos em tempos para otimizar estratégias de indexação. Outra estratégia de indexação que uso é procurar locais no meu código onde eu construo uma coleção com base em uma coluna de pesquisa e adicionar índices apropriados para pesquisar colunas.

    
por 10.11.2010 / 19:16
fonte
10

Eu projeto meu esquema de banco de dados primeiro, depois uso um ORM para criar os objetos dele. Eu sou um pouco old school assim; Não confio nos 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.

    
por 10.11.2010 / 19:50
fonte
5

Eu encontrei o livro de Bill Karwin, SQL Antipatterns , para ser realmente útil para o planejamento de banco de dados. O ponto mais abrangente é que o banco de dados oferece muitas oportunidades para proteger a integridade e o significado de seus dados, e que é um erro comum dos projetistas ignorar esses recursos por várias razões tentadoras. Considerando essas questões desde o início e deixando que elas informem todo o projeto, vale a pena e é melhor tentar recapear as rachaduras depois.

Eu prefiro usar um banco de dados que tenha restrições abrangentes para impor a lógica e integridade de negócios no nível do banco de dados. Muitas vezes eu vejo o banco de dados como o aplicativo e qualquer coisa que o acessa como uma mera interface. Isso faz com que a adição de outras "interfaces" seja 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 a mudança e acomodar o banco de dados no seu sistema de versão. Há uma boa redação sobre isso: Evolutionary Database Design de Martin Fowler & Pramod Sadalage (e também um livro inteiro sobre o assunto de Sadalage, embora eu não tenha lido isto).

Por último, os problemas periféricos de contas / funções de usuário, hardware / localização / conexão do host etc. são importantes e, às vezes, negligenciados. Tenha isso em mente também ao planejar.

    
por 10.11.2010 / 23:45
fonte
5
O design do banco de dados

não pode ser feito completamente sem considerar como os dados serão usados. Por isso, aqui está uma pequena lista de etapas:

  • escreva frases curtas capturando o relacionamento entre as entidades
  • desenhe um diagrama de entidade-relacionamento representando as sentenças
  • crie um modelo de dados lógico normalizado a partir do diagrama E-R
  • crie uma matriz CRUD para aplicativos e entidades
  • use a matriz para verificar a cobertura do ciclo de vida de cada entidade
  • extrai subschemas para cada aplicativo
  • examine os caminhos de navegação sobre os subschemas para cada operação principal / CRUD
  • considere os relatórios que serão necessários
  • projete o modelo de dados físico com base em todos os itens acima; desnormalizar, particionar e usar esquemas em estrela quando apropriado
por 24.11.2010 / 09:55
fonte
3

Para projetar com sucesso um banco de dados, você precisa considerar várias coisas primeiro:

  • Quais dados eu preciso armazenar e como está relacionado com os outros dados que eu loja. Como esses dados precisam Muda com o tempo? Eu preciso ser capaz de ver um instantâneo no tempo (que ordem de 2009) ou eu só preciso o que é atual (somente usuários ativos)?
  • Como posso ter certeza de que meus dados estão significativo e mantém significado sobre tempo (integridade de dados)?
  • Como posso ter certeza de que o acesso a dados é rápido?
  • Como posso manter meus dados seguros?

Portanto, antes de começar a projetar um banco de dados, primeiro você 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 quando você tem 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 de maneira mal-intencionada ou para garantir que você possa acompanhar as alterações ao longo do tempo para descobrir quem e quando uma alteração foi feita e para poder reverter para versões anteriores.

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

Em geral, os dados sobrevivem ao aplicativo por muitos anos, ele é o coração do aplicativo e não devem ser considerados como algum armazenamento de dados estúpido que é praticamente irrelevante.

    
por 26.04.2011 / 17:30
fonte
2
Em termos gerais, um bom design de banco de dados é um bom design de banco de dados - a questão maior para o uso da web será como você acessa os dados e gerencia as coisas que alguém pode considerar requerem estado que basicamente a web não possui.

Pensando nisso, minha abordagem é baseada em muita experiência ... mas se você começa com esquemas ou objetos, você está realmente tentando fazer a mesma coisa, ou seja, construir um modelo utilizável de seus dados - para um Um número substancial de projetos pode ser um relacionamento bastante direto entre modelo e esquema (não em todos os casos, e provavelmente não para todas as tabelas / objetos) então é realmente uma questão de construir um modelo decente a partir de onde você está confortável e trabalhando de lá.

Em termos de construção de um modelo decente - @Tim o faz para baixo em bancos de dados e construir fundamentalmente seu modelo de objeto será similar - o que é único, o que é uma hierarquia, onde há muitos relacionamentos, etc. , no entanto você chegar a um banco de dados, certifique-se de fazer todas as coisas boas.

Certifique-se também de ter scripts ou ddl no código para permitir que você crie o esquema a partir do zero e atualize conforme você faz alterações (ddl no código é meu método preferido - eu tenho um sistema e ele funciona). p>     

por 10.11.2010 / 22:19
fonte
2

Eu começo com uma grande lousa e um monte de cores diferentes de caneta. Cores diferentes significam coisas diferentes. E eu acabei de começar a desenhar. Normalmente eu desenho coisas que são definidas em preto, coisas que são provavelmente em azul e coisas que são improváveis em verde. Vermelho é para notas importantes. Eu apago e redesenhei copiosamente. Penso em que tipos de coisas preciso consultar e me certifico de que o modelo o suporte. Se isso não acontecer, vou ajustar até que isso aconteça.

Eventualmente, se o modelo ficar muito grande, movo-o para o Visio e trabalho em partes no quadro branco.

Por fim, penso em pontos de extensão. O maior erro que eu vejo a maioria das pessoas faz é projetar seu banco de dados e depois dizer "eu sou feito com o banco de dados" e seguir em frente. Você nunca terminou com o banco de dados. Cada solicitação de mudança que você recebe provavelmente chegará até esse nível. Então, pense em como adicioná-lo. Pense em quais tipos de solicitações são prováveis e veja se é possível envolvê-los. Se você não pensa em extensibilidade, vai entrar em grandes dívidas de design quando essas solicitações de mudança surgirem.

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

    
por 11.11.2010 / 01:38
fonte
1

Eu desenho objetos primeiro, então eu uso um ORM (como o 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.

Já faz muito tempo desde que eu vi um projeto onde as tabelas do banco de dados foram projetadas primeiro.

    
por 10.11.2010 / 19:23
fonte
1

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

  • É melhor ter o design do banco de dados feito por alguém que seja profissional. Não há problema em aprender, é claro, mas eu não sugeriria criar 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 permitir que o DB cuide. Isso é necessário para que você defina o valor 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 chaves simples quando puder.

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

  • Considere o uso de modelos de dados universais e siga os padrões da indústria em nomenclatura e tamanho de coluna de dados.

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

  • Ter seu modo analisado por outras pessoas.

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

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

por 17.02.2012 / 21:16
fonte