VISUAL BASIC TABELA AJUDA !!!!
Sou amador no VB, Estou fazendo um programa de cadastro para pet shop, tenho o cadastro certinho do usuário já com banco de dados, porem se o usuário tiver mias de um pet, como eu faço? primeiramente pensei e ligar duas tabelas do banco de dados e possÃvel? a outro jeito?
Fazer esse relacionamento por outras formas que não seja no próprio banco de dados é totalmente impróprio. Primeiro porquê torna o banco de dados um mero repositório, e para isso, um arquivo de texto seria sufuciente. Em segundo lugar, porquê você sera obrigado á escrever códigos que são desnecessários para cumprir o papel de gerenciador de informações, e isso em todos os lugares onde as duas entidades (animais e proprietários) forem utilizados, tornando a manutenção mais difÃcil e aumentando a possibilidade de erros de lógica.
E, respondendo, sim, você deve ter criado uma entidade ou tabela para os proprietários e outra para os animais de estimação e em tese, para este primeiro caso, onde um animal tem apenas um proprietário e um proprietário tem vários animais (um-para-muitos), bastaria que você gravasse o código do proprietário na tabela de animais de estimação, criando, claro, o relacionamento respective entre elas.
Agora, vamos á questão prática da coisa. Um animal de estimação pode ter - mas nem sempre tem - apenas um proprietário. Em outras palavras, todos os membros da famÃlia são os proprietários do mesmo animal, e eventualmente vão [Ô]aparecer[Ô] com ele na PetShop, o que se caracteriza como uma relação de muitos-para-muitos. Assim a questão muda, de acordo com a forma como você planeja sua aplicação. Nesse segundo caso, você já não gravaria mais o código do proprietário na tabela de Animais de Estimação. Para que essa segunda situação se torne viável em sua aplicação, é necessária uma terceira tabela, a de [Ô]Animais de Estimação dos Proprietários[Ô], que teria, esta sim, os códigos tanto dos proprietários quanto dos animais, e que podem ambos compôr uma mesma chave primária ou ser complementados por outro campo, este de autonumeração e servindo como chave primária.
Agora cabe á você escolher um dos modelos para implementar em sua base de dados.
Mas atenção: Lembre-se de que, ao criar um relacionamento, ele pode ou não demandar operações em cascata. Por exemplo, na relação um-para-muitos (primeiro caso), se você [Ô]matar[Ô] um proprietário, e o relacionamento entre ele e seus animais for em cascata, todos os animais também serão excluÃdos, o que pode acabar gerando erro, se o animal já tiver alguma ficha de atendimento.
Gaste todo o tempo que for preciso com seu banco de dados, não crie as entidades apenas, faça ele evoluir até que ele [Ô]fale[Ô] com você. Para esse fim, incorpore á ele consultas e procedimentos que permitam á você fazer todas as operações que sejam necessárias ou desejadas sem requerer o uso de nenhuma outra aplicação que não seja o próprio SGDB.
Só depois de ter a mais absoluta certeza de que a [Ô]conversa[Ô] entre você e o banco de dados está fluindo muito bem é que você deve começar á pensar em códigos, aplicações, formulários etc.
E, respondendo, sim, você deve ter criado uma entidade ou tabela para os proprietários e outra para os animais de estimação e em tese, para este primeiro caso, onde um animal tem apenas um proprietário e um proprietário tem vários animais (um-para-muitos), bastaria que você gravasse o código do proprietário na tabela de animais de estimação, criando, claro, o relacionamento respective entre elas.
Agora, vamos á questão prática da coisa. Um animal de estimação pode ter - mas nem sempre tem - apenas um proprietário. Em outras palavras, todos os membros da famÃlia são os proprietários do mesmo animal, e eventualmente vão [Ô]aparecer[Ô] com ele na PetShop, o que se caracteriza como uma relação de muitos-para-muitos. Assim a questão muda, de acordo com a forma como você planeja sua aplicação. Nesse segundo caso, você já não gravaria mais o código do proprietário na tabela de Animais de Estimação. Para que essa segunda situação se torne viável em sua aplicação, é necessária uma terceira tabela, a de [Ô]Animais de Estimação dos Proprietários[Ô], que teria, esta sim, os códigos tanto dos proprietários quanto dos animais, e que podem ambos compôr uma mesma chave primária ou ser complementados por outro campo, este de autonumeração e servindo como chave primária.
Agora cabe á você escolher um dos modelos para implementar em sua base de dados.
Mas atenção: Lembre-se de que, ao criar um relacionamento, ele pode ou não demandar operações em cascata. Por exemplo, na relação um-para-muitos (primeiro caso), se você [Ô]matar[Ô] um proprietário, e o relacionamento entre ele e seus animais for em cascata, todos os animais também serão excluÃdos, o que pode acabar gerando erro, se o animal já tiver alguma ficha de atendimento.
Gaste todo o tempo que for preciso com seu banco de dados, não crie as entidades apenas, faça ele evoluir até que ele [Ô]fale[Ô] com você. Para esse fim, incorpore á ele consultas e procedimentos que permitam á você fazer todas as operações que sejam necessárias ou desejadas sem requerer o uso de nenhuma outra aplicação que não seja o próprio SGDB.
Só depois de ter a mais absoluta certeza de que a [Ô]conversa[Ô] entre você e o banco de dados está fluindo muito bem é que você deve começar á pensar em códigos, aplicações, formulários etc.
Vlw cara, muito bom sua resposta !!!!!!
Mas como eu relaciono duas tabelas? teria algum tutorial para me passar? vlw
Mas como eu relaciono duas tabelas? teria algum tutorial para me passar? vlw
PROFESSOR,
Falou como sempre com propriedade, eu com conhecimento de causa, já que tenho clientes de PET SHOP a mais de 9 anos, posso dizer que particularmente sistema para pet é bem complexo. O PROFESSOR citou apenas uma delas a questão dos clientes e seu animais, depois vem o banho a tosa, a comissão do banhista e do tosador na mesma OS, depois entra a parte de veterinaria com agendamentos de vacinas e por ai vai, para vc ter uma ideia eu reescrivi meu sistema em vb6 para .nte Pet e vet juntos, demorei quase dois anos.
E como vc disse que ainda é amador vou te dar uma dica que os novatos costumam ignorar, não só novatos até alguns com bons conhecimentos, aprenda antes de tudo a fazer transações , Transação.begintrans/ transação.rollback , commit etc.
Sem querer assustar, mas eu em meus primeiros anos e projetos , por falta de uma esquema de transação mal feito, e olha que sempre utilizei, mas estava mal feito, quase dei e tomei um prejuizo alto.
Falou como sempre com propriedade, eu com conhecimento de causa, já que tenho clientes de PET SHOP a mais de 9 anos, posso dizer que particularmente sistema para pet é bem complexo. O PROFESSOR citou apenas uma delas a questão dos clientes e seu animais, depois vem o banho a tosa, a comissão do banhista e do tosador na mesma OS, depois entra a parte de veterinaria com agendamentos de vacinas e por ai vai, para vc ter uma ideia eu reescrivi meu sistema em vb6 para .nte Pet e vet juntos, demorei quase dois anos.
E como vc disse que ainda é amador vou te dar uma dica que os novatos costumam ignorar, não só novatos até alguns com bons conhecimentos, aprenda antes de tudo a fazer transações , Transação.begintrans/ transação.rollback , commit etc.
Sem querer assustar, mas eu em meus primeiros anos e projetos , por falta de uma esquema de transação mal feito, e olha que sempre utilizei, mas estava mal feito, quase dei e tomei um prejuizo alto.
Veja, ainda que a linguagem SQL pretenda ser universal, cada mecanismo de dados tem um [Ô]dialeto[Ô] próprio e que pode variar de forma substancial. Mas basicamente, relacionar duas tabelas significa que um dos campos da tabela-filhote deve sempre conter um valor válido, existente como campo de chave primária na sua tabela-pai.
E com relação á [Ô]como fazer[Ô], há duas formas para a maioria dos mecanismos de dados: Uma por meio de seus SGDBs e outra por meio de instruções SQL.
Todos os mecanismos de dados são conectáveis e portanto, permitem a execução de instruções SQL, mas nem todos possuem um aplicativo SGDB, ou seja uma [Ô]interface[Ô], um aplicativo de gerenciamento, como o Microsoft SQL Server ou o Oracle. Se você busca explorar, conhecer e entender o que está fazendo, usar a linguagem SQL é muito mais interessante. Quando você já possui um nÃvel de conhecimento maior, o uso dos aplicativos SGDBs acelera, ás vezes muito, os procedimentos. E assim, entender a linguagem SQL é o primeiro passo.
Uma vez que uma aplicação criada por você conecta-se á um banco de dados, desde que essa conexão tenha direitos para isso, já pode executar instruções SQL. Assim, você mesmo pode criar o seu aplicativo SGDB particular, e na verdade, é bem simples. Mas já estou fugindo do assunto.
Traduzindo para o [Ô]SQLês[Ô] (no caso, usando o dialeto do Microsoft SQL Server), para criar duas tabelas relacionadas e indexadas, por exemplo, contatos e seus telefones, você faria algo como:
Simples, não é? Com as linhas acima criamos as duas tabelas, ambas indexadas por seus campos textuais para agilizar as filtragens, onde CONTATOS pode ter vários TELEFONES, onde dois CONTATOS não podem ter o mesmo nome (o que não é correto, mas é só para exemplo) e onde dois TELEFONES não podem ser idênticos em DDI, Prefixo, Numero E Ramal, mas podem ser idênticos se ao menos um desses campos for diferente.
Mas, apesar de PROFESSOR, de gostar de ensinar e de ter uma certa [Ô]queda[Ô] por bases de dados, acho que o mais adequado é você ter algo sempre á mão, primeiro para não [Ô]ficar na mão[Ô] numa hora em que precise, e depois para ir aprendendo aos poucos, conforme o seu próprio ritimo ditar.
E neste caso, além, claro de algumas centenas de cursos, videos e apostilas que eu poderia indicar, acredito que este site pode ser bem interessante. Não estou dizendo que seja [Ô]o melhor[Ô], mas na minha opinião, é [Ô]o melhor para começar[Ô].
Valew?
NILSONTRES - Agradeço as palavras, e principalmente ao fato de você confirmar o que eu sempre digo: A análise de um problema é a fase mais crÃtica na construção de uma solução. Falhas de análise não são propositais, não são exclusividade dos neófitos e muitas vezes são causadas pelos próprios clientes. Você só se [Ô]livra[Ô] dessas falhas quando não lida com desenvolvimento de sistemas. Mas isso não quer dizer que não deva minimizá-las, sempre.
AOS DEMAIS LEITORES
Aproveitando, quero reforçar que não há como, para uso sério e profissional, desenvolver uma aplicação, sem dar á esse desenvolvimento o devido tempo de estudo, maturação e avaliação. Por mais que as ferramentas sejam RAD, mesmo o intoxicante SIENA ou o ótimo LightSwitch (Microsoft), ou ainda o Infobarn (Google) e outros tantos (e ainda as promessas como AppMachine, FabricaDeAplicativos etc), desenvolver algo, seja cloud, local, web, desktop ou mobile, requer tempo, como os dois anos que você investiu em sua aplicação.
Não é que não seja possÃvel criar, até em minutos, algo que funciona. é possÃvel sim, mas toda essa facilidade e agilidade também induz á problemas de lógica, e principalmente, á falhas de conceito. Tão rápido é feito e tão rápido se percebe que algo faltou, ou que devia ser diferente, e tudo deve ser reformulado.
No fim das contas, eu acredito é que a longevidade do seu aplicativo é proporcional ao tempo que você investe nele.
Assim, da próxima vez que lhe encomendarem um [Ô]simples controle de estoque[Ô], pense muito bem, converse muito mais, peça todas as toneladas de informações que puder, antes de estimar um prazo. Depois de estimar, multiplique por três, para evitar os desencontros e as eventualidades. Se o cliente busca algo bom, ele vai acabar concordando. Se não concordar, o que ele quer é qualquer coisa que tenha baixo custo. E para esses casos, sempre sem se comprometer com garantias nem com manutenção, você até pode negociar prazos menores, mas lembre-se de cobrar mais do que o normal, para não acabar só perdendo seu tempo.
E com relação á [Ô]como fazer[Ô], há duas formas para a maioria dos mecanismos de dados: Uma por meio de seus SGDBs e outra por meio de instruções SQL.
Todos os mecanismos de dados são conectáveis e portanto, permitem a execução de instruções SQL, mas nem todos possuem um aplicativo SGDB, ou seja uma [Ô]interface[Ô], um aplicativo de gerenciamento, como o Microsoft SQL Server ou o Oracle. Se você busca explorar, conhecer e entender o que está fazendo, usar a linguagem SQL é muito mais interessante. Quando você já possui um nÃvel de conhecimento maior, o uso dos aplicativos SGDBs acelera, ás vezes muito, os procedimentos. E assim, entender a linguagem SQL é o primeiro passo.
Uma vez que uma aplicação criada por você conecta-se á um banco de dados, desde que essa conexão tenha direitos para isso, já pode executar instruções SQL. Assim, você mesmo pode criar o seu aplicativo SGDB particular, e na verdade, é bem simples. Mas já estou fugindo do assunto.
Traduzindo para o [Ô]SQLês[Ô] (no caso, usando o dialeto do Microsoft SQL Server), para criar duas tabelas relacionadas e indexadas, por exemplo, contatos e seus telefones, você faria algo como:
CREATE TABLE [Contatos] ([ContatoID] int IDENTITY(1,1) PRIMARY KEY, [Nome] varchar(255) DEFAULT N[ô]Novo cliente[ô] NOT NULL);
go
CREATE UNIQUE INDEX [ukContatosNomes] ON [Contatos]([Nome]);
go
CREATE TABLE [Telefones] ([TelefoneID] int IDENTITY(1,1) PRIMARY KEY, [ContatoID] int NOT NULL, [DDI] varchar(2), [Prefixo] varchar(2), [Numero] varchar(10), [Ramal] varchar(3), CONSTRAINT [fkTelefoneDoCliente] FOREIGN KEY ([ContatoID]) REFERENCES [Contatos] ([ContatoID]) ON UPDATE CASCADE ON DELETE NO ACTION);
go
CREATE INDEX [ixTelefonesDDI] ON [Telefones]([DDI] ASC);
go
CREATE INDEX [ixTelefonesDDD] ON [Telefones]([Prefixo] ASC);
go
CREATE INDEX [ixTelefonesNumero] ON [Telefones]([Numero] ASC);
go
CREATE INDEX [ixTelefonesRamal] ON [Telefones]([Ramal] ASC);
go
CREATE UNIQUE INDEX [ukTelefones] ON [Telefones]([DDI],[Prefixo],[Numero],[Ramal] ASC);
goSimples, não é? Com as linhas acima criamos as duas tabelas, ambas indexadas por seus campos textuais para agilizar as filtragens, onde CONTATOS pode ter vários TELEFONES, onde dois CONTATOS não podem ter o mesmo nome (o que não é correto, mas é só para exemplo) e onde dois TELEFONES não podem ser idênticos em DDI, Prefixo, Numero E Ramal, mas podem ser idênticos se ao menos um desses campos for diferente.
Mas, apesar de PROFESSOR, de gostar de ensinar e de ter uma certa [Ô]queda[Ô] por bases de dados, acho que o mais adequado é você ter algo sempre á mão, primeiro para não [Ô]ficar na mão[Ô] numa hora em que precise, e depois para ir aprendendo aos poucos, conforme o seu próprio ritimo ditar.
E neste caso, além, claro de algumas centenas de cursos, videos e apostilas que eu poderia indicar, acredito que este site pode ser bem interessante. Não estou dizendo que seja [Ô]o melhor[Ô], mas na minha opinião, é [Ô]o melhor para começar[Ô].
Valew?
NILSONTRES - Agradeço as palavras, e principalmente ao fato de você confirmar o que eu sempre digo: A análise de um problema é a fase mais crÃtica na construção de uma solução. Falhas de análise não são propositais, não são exclusividade dos neófitos e muitas vezes são causadas pelos próprios clientes. Você só se [Ô]livra[Ô] dessas falhas quando não lida com desenvolvimento de sistemas. Mas isso não quer dizer que não deva minimizá-las, sempre.
AOS DEMAIS LEITORES
Aproveitando, quero reforçar que não há como, para uso sério e profissional, desenvolver uma aplicação, sem dar á esse desenvolvimento o devido tempo de estudo, maturação e avaliação. Por mais que as ferramentas sejam RAD, mesmo o intoxicante SIENA ou o ótimo LightSwitch (Microsoft), ou ainda o Infobarn (Google) e outros tantos (e ainda as promessas como AppMachine, FabricaDeAplicativos etc), desenvolver algo, seja cloud, local, web, desktop ou mobile, requer tempo, como os dois anos que você investiu em sua aplicação.
Não é que não seja possÃvel criar, até em minutos, algo que funciona. é possÃvel sim, mas toda essa facilidade e agilidade também induz á problemas de lógica, e principalmente, á falhas de conceito. Tão rápido é feito e tão rápido se percebe que algo faltou, ou que devia ser diferente, e tudo deve ser reformulado.
No fim das contas, eu acredito é que a longevidade do seu aplicativo é proporcional ao tempo que você investe nele.
Assim, da próxima vez que lhe encomendarem um [Ô]simples controle de estoque[Ô], pense muito bem, converse muito mais, peça todas as toneladas de informações que puder, antes de estimar um prazo. Depois de estimar, multiplique por três, para evitar os desencontros e as eventualidades. Se o cliente busca algo bom, ele vai acabar concordando. Se não concordar, o que ele quer é qualquer coisa que tenha baixo custo. E para esses casos, sempre sem se comprometer com garantias nem com manutenção, você até pode negociar prazos menores, mas lembre-se de cobrar mais do que o normal, para não acabar só perdendo seu tempo.
Faça seu login para responder