Comentários abaixo:
On 27/02/2015 17:39, Leandro Guimarães Faria Corcete DUTRA wrote:
Le 27 février 2015 17:13:42 GMT-03:00, "Flávio Silveira" <[email protected]> a
écrit :
Certo, é que eu resolvi dar muita atenção ao modelo relacional e
comprrende-lo bem, antes de me aventurar
pelo mundo SQL em si.
Entendo, mas é o contrário. O modelo relacional nada tem a ver com diagramas.
Embora o SQL também não seja relacional, é muito mais próximo do modelo
relacional que qualquer diagrama.
Isso caiu como uma bomba para mim, mas são esses conceitos que eu
estava procurando a pelo menos 3 anos.
Tenho certeza que seria, mas eu preciso praticar e futuramente isso
será integrado num ERP
que estou desenvolvendo para a empresa.
Exatamente, seria melhor você começar com um ERP já pronto, e aprender a
adaptá-lo. Veja os ERPs que funcionam com PostgreSQL. Aliás, lembrei doutro:
o Adempière.
Obrigado pela dica, vou dar uma pesquisada. O ERP que eu imaginei
para a empresa está modelado com Scrum (digo, tenho as áreas de negócio
e o backlog). Para o Banco de Dados eu estou irredutível quanto a
PostgreSQL, pode ser birra minha mas não consigo levar a sério quando me
oferecem MySQL. Quanto ao front-end, pretendo usar JSF, já que Java é a
linguagem que escolhi para me dedicar.
É por causa desse ERP que
comecei a estudar Banco de Dados e
também a razão pela qual comecei uma faculdade de Análise e
Desenvolvimento de Sistemas.
Cuidado, essas faculdades são 90% caça níqueis, e costumam ensinar dados muito
erradamente. Até hoje, só vi no Brasil algumas poucas universidades públicas
onde um ou outro professor ensina isso corretamente.
Não que faculdade seja dispensável neste país, mas quanto a dados você aprende
mais com os livros do Date.
Concordo com você, eu só decidi fazer a faculdade por não ter
encontrado um "mentor" na questão de banco, e minha dificuldade com
livros era não ter com quem validar o conceito que eu aprendi com o livro.
Exemplo: Esse caso do sistema de controle de financiamento, para mim
parecia correto baseado no que li, mas tenho o costume de querer alguém
experiente validando aquilo que faço, pois detesto perder tempo levando
um conceito errado para frente.
Como sou novato e para não complicar muito a validação dos cadastros
eu pensei em usar IDs para garantir unicidade, futuramente pretendo
trocar ID por CNPJ, CPF e código do Banco respectivamente assim que eu
for evoluindo. Parece sensato, concorda?
Só parece. Primeiro, que você não deve criar algo sabendo que já terá de
mudar; melhor entender primeiro as razões das coisas. Invista no livro do
Date, gaste algumas semanas nisso, daí continue. Queimar etapas não vai te
ajudar.
Segundo, ID nunca garante unicidade. O que garante unicidade são chaves
naturais. CPF, CNPJ e código do banco (aquele que é 1 para o BB, por exemplo)
costumam ser chaves naturais razoáveis, em muitos casos.
Pense: se você tiver apenas IDs, o que te impede de inserir a mesma informação
várias vezes, cada vez gerando uma nova tupla com um novo ID?
Exatamente, pode ser excesso de zelo meu, mas estou me dedicando
bastante a modelagem relacional para ter coisas com qualidade, mesmo
que
simples. Comecei lendo o livro Projeto Banco de Dados do Carlos Alberto
Heuser, depois comprei o Modelagem Lógica de Dados do Eduardo Bernardes
de Castro e para tentar intensificar um pouco meu conhecimento além da
leitura, comprei o curso Modelagem Relacional do Eduardo Morelli e
oferecido pela DevMedia.
Não conheço livro bom de dados de autores brasileiros. Geralmente, até livros
de professores da USP estão cheios de meias verdades que geram muita confusão.
Guarde esses livros numa caixa, e os substitua pelo Date. Sério.
Só para dar um exemplo, vários empregos atrás me louvaram muito um professor da
USP que seria muito rigoroso e tinha um livro muito bom. Peguei a última
edição e havia um erro óbvio. Aí conheci o tal professor e descobri o que
aconteceu: o filho dele virou consultor Oracle. Aí ele deixou o rigor de lado.
Quanto ao livro do Date, seria Chris Date? Vi que existem vários
livros dele, pode me sugerir um pra começar? Não tenho preguiça de ler
pois quero montar uma base boa.
Acha que a lista seria o lugar apropriado para usar de "validador" de
conceitos? Vejo que o pessoal ajuda bastante aqui, mas com coisas mais
avançadas, não sei se coisas básicas como as minhas não irritariam vocês
heheh
Basicamente todos são claros nesse ponto de definir bem as entidades
e colocar atributos que só dependem da entidade, caso contrário tem de
ir para o relacionamento entre as entidades.
Relacionamento não é um conceito relacional. Se os livros não explicam isso,
só servem para peso de porta.
Fico um pouco triste por ter desperdiçado um bom tempo e dinheiro com
porcaria, mas acho que foi necessário para eu chegar no lugar correto.
Mais uma vez muito obrigado!
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
