Pessoal,
Vamos ter um hangout sobre Banco de Dados X Regras de Negócio, onde teremos abordagens sobre regras de negócio aplicadas no banco de dados. Pra quem quiser participar, segue o link do Hangout:
https://plus.google.com/events/cn7etgade3490f4lie1t385naqg?hl=pt-BR
Será no próximo sábado, 27/08 às 10h.
Grato.
Se tudo der certo estarei lá como ouvinte.
Será uma honra pra mim, Alexandre!
Demorei Kleyber. Mas vi.
Parabéns.
Valeu Alexandre.
Um assunto legal de abordar também hoje é a técnica de tabelas únicas: (Pessoas > Clientes, Fornecedores, Funcionários, etc),
(Movimentação > Compras, Saídas, Ordem de Serviço), etc, com sequência ID direta, separada do número das Notas, etc.
Usar esses tipos de tabelas únicas depois tanto para multi-empresa e no Scriptcase facilita muito o trabalho desenvolvimento e manutenção.
Jailton,
Até concordo, desde que o modelo do banco de dados seja esse. Se não, então vai depender muito da forma como foi (ou como vai ser) desenvolvido o modelo do banco. Eu, por exemplo, não uso o conceito de tabelas únicas, pra mim existe a tabela Clientes e a de Fornecedores. Então isto vai da modelagem de cada um.
Jailton este tipo de modelagem esta se espalhando.
Até facilita porque uma pessoa pode ao mesmo tempo ser cliente e fornecedor.
Se não me engano este sistema http://www.sajadv.com.br usa este conceito.
Você tem algum lugar com mais material sobre este tipo de modelagem?
Sim por isso que até comentei aqui, achei que o Kleyber ia abortar isso, todos os novos sistemas e sistemas legados que estamos convertendo, estamos passando para este padrão,
facilita muito depois o desenvolvimento e manutenção, tanto a nível de banco quando as app dos SC, já que aproveitamos muito mais código só mudando os filtros, ehehe
Mas modelo em si documentando, não tenho, isso foi sendo analisado por todas as SoftHouse com o tempo e prática.
aqui um exemplo: http://www.cwork.com.br/produto/gestao << Olha embaixo em diferenciais, e outra softhouse http://www.digisat.com.br que trabalho adotou isso também.
Mas para sistemas futuros talvez o Kleyber adote este padrão único, mas não vai ser comentado neste Hangout como ele já explicou.
Talvez escrevam um livro de SQL futuramente sobre isso também.
para um grande sistema é tiro no pé
Porque é um tiro no pé?
Talvez ele esta falando de bases com 5 bilhões de registro e 1TB, para dar um SELECT, heheeh
Em normalização clientes é uma entidade e fornecedor outra, e ambas possuem alguns campos em comuns e outros campos diferenciados.
É muito raro casos onde o cliente é também fornecedor, nesse caso exceções vale a redundância.
de qualquer forma os formulários devem ser distintos pois cada um é utilizado em setores diferentes (comercial e compras)
Essa regra deve valer para representantes, vendedores, funcionários.
mas já vi muitos sistemas que unem todas essas entidades e uma única tabela.
Mas Jailton dependendo do SGDB dar um select * é um tiro no pé:
Vou reproduzir aqui este parte: http://www.scriptcase.com.br/forum/index.php/topic,5689.msg34780.html#msg34780
Bom dia,
Fiz testes com postgresql, mysql e firebird em uma base que tem uma tabela com 1Gb de dados.
"Segue alerta de desempenho do scriptcase com Firebird e postgresql.
Em formulários e grids o scriptcase para fazer a paginação usa um select count() from tabela tal.
Para usuário do mysql isto nem faz cosquinhas.
Mas o tipo de versionamento do postgresql e firebird tornam o uso do count() lento.
Ver:
http://wiki.postgresql.org/wiki/Slow_Counting
http://www.firebirdfaq.org/faq5/
Então sempre use o where em seus selects nestes SGDBS com o scriptcase, nunca use um select * from xxxx.
Acredite! Tem gente que ainda faz o select * from como se fosse a coisa mais normal do mundo.
Com muitos registros é um desastre.
No firebird e postgresql na tabela de 1gb o count(*) chegava a demorar 43 segundos. Para depois executar a query em menos de 1 segundo.
No mysql tudo era executado em menos de 1 segundo no myisam e de alguns microsegundos a 3 segundos no innodb
Aproveito para lembrar que isto não é uma situação onde se deva considerar o mysql ótimo para tudo.
Lembro que o mysql é sempre rápido para consultas.
Mas em testes de desempenho para insert ou update com volume alto de transações ele costuma se sair pior que o firebird e o postgresql.
Além do que ele não trabalha com tabelas com campos blob e text em memória e sim sempre em disco.
E etc, etc, etc
De qualquer forma o melhor banco para trabalhar é aquele que você conhece e sabe suas fraquezas, forças, como otimizá-lo e em que situação aplicá-lo.
Para os novatos aconselho também a não utilizar mais de três selects com lookup num form.
Não importa qual seja o SGDB usado, mais de três selects com lookup em base de dados é uma lentidão."
[b]Logo, acho que ele deve ter falado de outra coisa.
PS: Mesmo que você esteja falando de um select com where os indices tem que dar conta do recado.
E há testes que demonstram que eles dão.[/b]