estrutura de banco para novo projeto

[WellingtonSilva 4]

Amigos,

 

Vou iniciar a criação de um novo projeto para um cliente e estamos discutindo o desenho do projeto do banco.

 

Minhas dúvidas são as seguintes:

 

* Tabela única para vários "assuntos". Por exemplo: ter uma única tabela para Clientes, Fornecedores, etc. controlando por informações adicionais. ISSO É UM MÉTODO CORRETO?

 

* Quanto menos tabelas existirem no banco melhor?

 

* A criação de Procedures e Triggers se fazem obrigatórias para o banco ou não?

 

Estou pedindo a ajuda dos amigos porque já desenhei diversos projetos onde eu tinha tabelas separadas por assunto e sempre gostei de construir Prodedures e Triggers.

 

Grande abraço.

 

[Motta 645]

* Tabela única para vários "assuntos". Por exemplo: ter uma única tabela para Clientes, Fornecedores, etc. controlando por informações adicionais. ISSO É UM MÉTODO CORRETO?

 

Na minah opinião não, modele, normalize , use o métido de Jack (The Ripper) separe por parte

 

* Quanto menos tabelas existirem no banco melhor?

 

O Sistema deve ter as tabelas necessárias para seu funcionamento

 

* A criação de Procedures e Triggers se fazem obrigatórias para o banco ou não?

 

Isto depende, em um Sistema feito para ser distribuído e que acesse multiplos BDs é ruim pois requer versões diferentes (BDs usam linguagens diferentes) , em um BD de um Sistema Proprietário pode ser uma abordagem interessante

[advaldomesquita 93]

Uma boa aplicacao começa com um bom desenho, seja da parte de infra, aplicação e db. Ainda bem que a maioria faz isso :coolio:

 

Vamos as dúvidas:

 

* Tabela única para vários "assuntos". Por exemplo: ter uma única tabela para Clientes, Fornecedores, etc. controlando por informações adicionais. ISSO É UM MÉTODO CORRETO?

A segmentação de tabelas pode ser necessária para consultas mais rápidas ou até mesmo para facilitar o trabalho do DBA (ou AD).

Qual a volumetria total de dados? Volumetria de escrita, volumetria de leitura. As tabelas vao estar em filesgroups diferentes ou no msm file?

Muitas vezes em uma tabela de 1 milhão de registros segmentar pode ser a única solução, mas não em uma tabela de 10 mil registros, por exemplo.

 

* Quanto menos tabelas existirem no banco melhor?

Agora cai um pouco na estrutura que está o seu DB. Citei acima os filesgroups, que é a segmentação dos objetos de banco de dados em diversos discos.

Então se você tiver um hardware compatível com o tamanho do seu DB e ele estiver estruturado também para seu crescimento, a quantidade de tabelas não importa <b>A NIVEL DE HARDWARE.</b>

A nível de estrutura de tabelas, vai depender do volume de dados em cada tabela.

Por exemplo: É muito mais oneroso para o DB um JOIN entre uma tabela de 2 milhões de registros com outra de 1 milhão onde o resultado final é 10 mil

Do que uma tabela única de 3 milhões de registros. Pq? Pq a consulta através do JOIN dependendo da estrutura dos índices vai “varrer” as duas tabelas.

 

 

* A criação de Procedures e Triggers se fazem obrigatórias para o banco ou não?

Aqui vai uma opinião pessoal:

Prefiro fazer toda a regra de negocio no DB do que deixar na aplicação. Se eu precisar alterar alguma estrutura de tabelas, eu altero somente no DB e não preciso alterar na aplicação. Ganha-se tempo e também segurança, pois posso fazer com que o usuário da aplicação tenha acesso somente aos objetos necessários.

[WellingtonSilva 4]

 

 

Qual a volumetria total de dados? Volumetria de escrita, volumetria de leitura. As tabelas vao estar em filesgroups diferentes ou no msm file?

Motta e A.Jr desculpem minha demora no retorno.

 

A.Jr será um único file.

A volumetria é que vem a ser o "problema", como é para PDV em supermercado não dá para dizer, pois pode haver um movimento grande em finais de semana e datas de vencimento de cartões e um movimento menor em outros dias.

 

Eu vim até vocês pedir estas informações porque é o cliente que quer tabelas únicas.

A razão disso é que disseram para ele que esta é a melhor forma e estou tentando angariar o máximo de informações com profissionais (vocês) para tentar pelo menos dialogar com ele e expor as opções como você A.Jr fez em sua resposta.

 

Como Motta aconselhou ("método Jack") eu também gosto desta forma.

[advaldomesquita 93]

Independente do "numero" de tabelas (ou objetos) vc teria um unico disco para gravacao e leitura, ou se tiver em RAID, alguns discos.

Para PDV eu cheguei a modelar um db com mais ou menos 30 a 40 tabelas e toda a estrutura de programacao ficou no DB.

O trabalho maior se concentrou em tunning e possiveis gargalos, mas tudo a nivel de banco.

Deste modo, foi mais rapido programar e assim liberar mais rapido a apliacacao.

[Motta 645]

No caso de um PDV mais tabelas é uma boa implementação (física), um exemllo :

 

A tabela produtos tem " n kapa pi" colunas, necessárias para os aspectos gerais da empresa, mas na boca do caixa só interessa código , descrição resumida e preço, vale a pena manter uma replicação desta tabela que no final vai tender a ficar em memória facilitando a leitura.

 

Cuidado com que o cliente quer , pois não sendo ele técnico ele pode estar pedindo uma coisa querendo outra.

 

Cabe sempre a pergunta, mas "por que" ...

 

Muito cuidado com "economias" pois armazenamento hoje é relativamente barato mas a mão-de-obra é cara, já vi "economias" que precisam de queries mágicas para responder demandas trivias. Tem de pensar no todo , fiscal , gerencial , BI , negócias, cliente etc.

 

Isto tudo claro na minha mui modesta opinião.

[WellingtonSilva 4]

A.Jr

 

 

Independente do "numero" de tabelas (ou objetos) você teria um unico disco para gravacao e leitura, ou se tiver em RAID, alguns discos.

Para PDV eu cheguei a modelar um db com mais ou menos 30 a 40 tabelas e toda a estrutura de programacao ficou no DB.

O trabalho maior se concentrou em tunning e possiveis gargalos, mas tudo a nivel de banco.

Deste modo, foi mais rapido programar e assim liberar mais rapido a apliacacao.

 

Motta

 

 

A tabela produtos tem " n kapa pi" colunas, necessárias para os aspectos gerais da empresa, mas na boca do caixa só interessa código , descrição resumida e preço, vale a pena manter uma replicação desta tabela que no final vai tender a ficar em memória facilitando a leitura.

Cuidado com que o cliente quer , pois não sendo ele técnico ele pode estar pedindo uma coisa querendo outra.

Cabe sempre a pergunta, mas "por que" ...

Muito cuidado com "economias" pois armazenamento hoje é relativamente barato mas a mão-de-obra é cara, já vi "economias" que precisam de queries mágicas para responder demandas trivias. Tem de pensar no todo , fiscal , gerencial , BI , negócias, cliente etc.

 

Valeu meus amigos vocês ajudaram bastante, inclusive no que diz respeito a falar com o cliente.

 

Muito obrigado!

 

Grande abraço