Bom lugar para procurar, por exemplo, Modelos de bases de Dados - melhores práticas

Antes de começar a ler sobre normalização até não ter dúvidas sobre isso. Se você só fez isso na escola, você provavelmente não sabe o suficiente sobre ele para projetar ainda.

Reúna cuidadosamente as suas necessidades para cada módulo. Precisas de saber: ([1]) as regras comerciais (que são específicas dos pedidos e que devem ser aplicadas na base de dados, dado que devem ser aplicadas em todos os registos, independentemente da fonte),

Existem preocupações legais ou regulamentares (HIPAA) por exemplo, requisitos Sarbanes-Oxley) segurança (os dados precisam ser criptografados?)

Que dados precisa de armazenar e porquê (estes dados estão disponíveis em qualquer outro lugar)

Que pedaços de dados só terão uma linha de dados e que terão de ter linhas múltiplas

Como pretende impor a singularidade da linha em cada tabela? Tem uma chave natural ou necessita de uma chave substituta (sugira uma chave substituta em quase todos os casos) {[[2]}

Precisas replicação?

Precisas de auditoria? Como é que os dados vão ser introduzidos na base de dados? Será que ele vem da aplicação um registro de cada vez (ou mesmo de várias aplicações)ou será que parte dele vem de inserções em massa a partir de uma ferramenta ETL ou de outro banco de dados.

Você precisa saber quem entrou no registro e quando (altamente provável que isso será necessário em um sistema de empresa.

Que tipo de mesas de pesquisa vai precisar? Entrada de dados é muito mais precisa quando você pode usar tabelas de pesquisa e restringir os usuários aos valores. De que tipo de validação de dados precisa? Quantos registos terá o sistema? Você precisa ter uma idéia para saber quão grande criar seus dados de teste. Como é que vais consultar os dados? Você estará usando procs armazenados ou uma ORM ou consultas dinâmicas?

Algumas coisas muito básicas para lembrar no seu design. Escolha o tipo de dados certo para os seus dados. Não guardar as datas ou números que você pretende fazer matemática em campos de string. Armazene números que não são candidatos para matemática (números de peças, códigos zip, números de telefone, etc) como dados de string como você pode precisar de zeros líderes. Não armazenar mais de uma informação em um campo. Assim, nenhuma lista comma-concatenada (estes indicam a necessidade de uma tabela relacionada) e enquanto você está nela se você se encontrar fazendo algo como phone1, phone2, phone 3, pare imediatamente e projetar uma tabela relacionada. Usar chaves estrangeiras para os dados propósitos de integridade.

Todo o caminho através do seu design considere a integridade dos dados. Os dados que não têm integridade são inúteis e sem sentido. Fazer design para o desempenho, isso é fundamental no projeto datbase e não é otimização prematura. Banco de dados não refactor facilmente, por isso é importante obter as partes mais critcal da equação de desempenho direito da primeira vez. Na verdade, todas as bases de dados precisam ser projetadas para a integridade dos Dados, Desempenho e segurança.

Não tenhas medo de ter múltiplas ligações, devidamente indexadas estas irão funcionar muito bem. Não tente colocar tudo em uma tabela do tipo de valor da entidade. Use - os o mais moderadamente possível. Tente aprender a pensar em termos de manipulação de conjuntos de dados, ele vai ajudar o seu design. Bases de dados são otimizadas para fazer coisas em conjuntos. Há mais, mas isto é suficiente para começar a digerir.