Após muito estudo, cursos e videos creio estar pronto para minha primeira tentativa de programação com SQL.
O caso em questão é um módulo do meu sistema, módulo que gera ordens de produção, consiste na pessoa selecionar um produto e dizer que caracteristicas ele terá.
Inicialmente pensei em criar uma tabela com os campos Produto, Caracteristica1, Caracteristica2 e assim por diante. Acontece que apenas alguns produtos tem mais de três caracteristicas.
O que é recomendado fazer? Seguir minha idéia e passar parametro nulo para produtos que não tem a caracteristica? Isso não dificultaria a consulta ou a montagem da interface em si?
Sei que antes de por a mão na massa eu deveria tentar resolver isso primeiramente no Excel, mas a vontade de fazer meu primeiro programa que será usado em produção é maior hehehe
repasso o conselho de meu mentor: “quando estiver modelando alguma coisa… pense se está fácil de gravar as informações e se é fácil de recuperá-las. Se de um jeito ou de outro der muito trabalho… remodele”
O primeiro de tudo, que é fundamental você parece já ter: bom entendimento do problema. Se sabe que seu produto poderá ter até no máximo três características, está de muito bom tamanho ter tudo em uma tabela, com a identificação do produto, caracteristica1, caracteristica2 e caracteristica3 gravando nulo onde não houver conteúdo. Isso por si só já resolve e ponto. Você só precisaria separar isso em duas tabelas (produto e caracteristicas neste contexto) se tivesse que prever um número indeterminado com grandes variações de características entre um produto e outro.
E acredite sempre: algum tempo depois de ter escrito a primeira versão de qualquer software, você perceberá que poderia ter sido melhor em uma coisa ou outra. É natural. É evolução. É por isso que são lançadas várias versões de um software.
Nesse caso se um produto tiver uma carateristica vai possuir um registro nessa tabela, no caso de um produto possuir n caracteristicas vai possuir n registros nessa tabela, essa tabela produto_caracteristica seria composta pelas chaves da tabela produto e tabela caracterisitca.
Hum, interessante esse negócio de utilizar duas tabelas, mas no curso básico que eu estudei só tinha exemplos com uma. Vou pesquisar mais sobre como interagir com mais de uma tabela.
Vou ver se consigo postar uma modelagem simples da minha idéia com o caso real, dai vocês avaliam se uma tabela é suficiente ou 2 ou mais tabelas.
[quote=augustoneto]Eu vejo uma relação N x N entre duas tabelas:
produto
caracteristica
Que no caso geraria uma terceira tabela:
produto_caracteristica
Nesse caso se um produto tiver uma carateristica vai possuir um registro nessa tabela, no caso de um produto possuir n caracteristicas vai possuir n registros nessa tabela, essa tabela produto_caracteristica seria composta pelas chaves da tabela produto e tabela caracterisitca.[/quote]
Concordo com o augustoneto, acho q o relacionamento no seu caso seria N x N, um exemplo seria:
Nesse caso vc pode ter N características para N produtos. A não ser q cada produto tenha uma característica específica, ou seja, a característica não se repete para nenhum produto, aí seria uma relação de 1 produto contém N características, seria uma relação simples de 1 x N.
Pergunta idiota #1: É comum no começo só enxergar tabelas com 2 campos?
Pergunta idiota #2: É comum utilizar tabelas com apenas 2 campos?
É o seguinte, comecei a montar a idéia no Excel, mas devido a complexidade, pensei em montar várias tabelas, mas tudo que vejo não tem muitos campos.
Por exemplo:
Tabela 1 com campos Código e Produto
Tabela 2 com campos Marca, Modelo, Telefone de Suporte, Site, Painel, Gabinete
Tabela 3 com campos Código e Opcional (para opcionais disponiveis)
Tabela 4 seria montada consultando os dados das 3 tabelas.
Na minha opinião a quantidade de campos das tabelas é indiferente, eu particularmente procuro manter as tabelas conforme os objetos q necessito, por exemplo, tabela PESSOA contém os dados de uma pessoa, porém, o endereço fica na tabela ENDERECO, já a cidade (do endereço) tem uma tabela separada tbm, e essa geralmente só tem ID, NOME e FKESTADO para referenciar a tabela ESTADO, entendeu?
Já sobre a tabela 4, q vc disse q é usada montando uma consulta em cima de 3 tabelas, é melhor utilizar VIEW, não sei se foi isso q vc quis dizer mas se não foi dá uma pesquisada e cria VIEWS para esses procedimentos, é mais recomendável principalmente por questões de performance.
De duas uma, ou a coisa se tornou complexa ou eu a tornei complexa.
Tentei validar a idéia no Excel, mas só consegui relacionar uma tabela até agora.
Tabela 1 está assim:
Codigo, Categoria
A tabela 2 vai pegar a Categoria da tabela 1 e jogar em Categoria_id:
Codigo, Categoria_id, Marca, Modelo, Telefone, Site
A tabela 3 deveria ser a tabela de caracteristicas, mas não consigo enxergar direito como fazer e relacionar com a tabela 2 ou vice-versa, veja:
Codigo, Opcional, ValorPadrao
A idéia que tive com ValorPadrao é deixar Sim ou Não dependendo do Opcional e do Modelo. Mas acabei de pensar que isso não vai funcionar, pois podem existir diversos modelos para a mesma categoria, eu não tenho como determinar o valor pelo Modelo, mas pela categoria talvez.
PS: Alguma sugestão de como postar a tabela do Excel aqui? Acho que ninguem baixaria se eu anexasse hehehe
Camarada, existe uma coisa chamada normalização de banco de dados. São 5 formas normais e que regulam como e o que deve ser feito para criação de uma estrutura de banco de dados.
Se você não segue essas regras, muito facilmente você terá sobrecarga ou terá inconsistência nos dados.
As regras de normalização são facilmente encontradas na internet, basta uma busca rápida e você encontra diversos exemplos aplicados.
Tenta utilizar uma ferramenta de modelagem, acho q vai clarear suas idéias, existem várias ferramentas free ótimas como o MySQL Workbench.
Se vc usa o Eclipse eu tenho um ótimo plugin free q faz a modelagem porém esqueci o nome dele em casa dou uma olhada e depois posto aki blz.
[quote=drsmachado]Camarada, existe uma coisa chamada normalização de banco de dados. São 5 formas normais e que regulam como e o que deve ser feito para criação de uma estrutura de banco de dados.
Se você não segue essas regras, muito facilmente você terá sobrecarga ou terá inconsistência nos dados.
As regras de normalização são facilmente encontradas na internet, basta uma busca rápida e você encontra diversos exemplos aplicados.[/quote]
Bem lembrado drsmachado, normalização é um dos fundamentos mais importantes na criação de um bd.
Segui a dica do drsmachado e li, reli, rabisquei, tentei e o resultado é esse da imagem abaixo. Tenho certeza que dá para melhorar, principalmente porque eu gostaria de amarrar marca com os modelos e tipos de produtos (categoria), mas para tipo de produto existem varios modelos, inclusive modelos diferentes para algumas marcas, eu ainda estou pensando nisso, mas quis mostrar aqui minha evolução (ou não hehehe). Se tudo estiver correto, normalizei até 3FN.
Vale lembrar que é apenas um esboço no Excel, quero ver se faz sentido antes de partir para o SQL mesmo.
A primeira tabela seria a Ordem de Produção em si.
A segunda tabela seriam mais detalhes da Ordem de Produção.
A terceira tabela um cadastro simples das marcas, apenas com a personalização que vai no produto.
A quarta tabela são os modelos.
A quinta são os tipos de produto (ou a que categoria o produto pertence).
A sexta e última (ufa!) são os itens que vão acompanhar ou não o produto.
[quote=fabiocortolan]Tenta utilizar uma ferramenta de modelagem, acho q vai clarear suas idéias, existem várias ferramentas free ótimas como o MySQL Workbench.
Se vc usa o Eclipse eu tenho um ótimo plugin free q faz a modelagem porém esqueci o nome dele em casa dou uma olhada e depois posto aki blz.[/quote]
Lembrei o nome do plugin do Eclipse, é ERMaster, para quem interessar o link é http://ermaster.sourceforge.net/. É um ótimo plugin para modelagem de dados, prefiro ele ao Workbench (principalmente pq o Workbench não roda no linux sem wine e o forge dele p/ Linux não é lá essas coisas).
Sobre a modelagem q vc fez, estou sem tempo para ver com calma e dar uma opinião, mas assim q conseguir eu posto uma opinião a respeito blz.
Obrigado pelo plugin Fábio, ainda não uso Eclipse pois acredito que ferramentas ágeis são mais interessantes quando já se tem domínio da coisa, não é o meu caso. Fico no aguardo do seu comentário sobre a modelagem, sem pressa, não é nenhuma prioridade.
Me corrijam se eu estiver errado, mas o silêncio por parte dos mais experientes é como dizer “Implemente e teste”? Digam “Meu Deus, que coisa horrível” pelo menos heheheh
Brincadeira, eu não tive tempo p/ analisar ainda, estou extremamente ocupado ultimamente, mas acho q facilitaria se vc fizesse a modelagem em um sistema próprio p/ isso, acho q o pessoal iria analisar com mais facilidade p/ vc.
Claro, vou baixar o MySQL Workbench e tentar heheheh
Minha tentativa foi montar o conceito, antes de encarar o MySQL mesmo, mas pelo jeito não animou o pessoal a olhar ou comentar, apenas 4 downloads hehehe
em casa dou uma olhada e depois posto aki blz.
