none
Tabelas tbENDERECO e tbCLIENTE RRS feed

  • Pergunta

  • Boa noite, estou fazendo uma query para estudos e não sei resolver esse problema. Para ligar a tbCLIENTE à tbENDERECO recomendaram criar uma tabela separada, mas como eu faço para inserir os dados do endereço na tabela do cliente? Tipo, quando for inserir os dados do cliente já puxa os atributos da tabela endereço. Agradeço desde já.

    create table tbENDERECO(
    CEP numeric(8) primary key,
    Cidade varchar(50) not null,
    UF char(2) not null,
    Complemento varchar(50) not null,
    Rua varchar(200) not null,
    Bairro varchar(50) not null
    );
    go;

    create table tbCLIENTE(
    CPF_Cliente numeric(11) primary key,
    Nome_Cliente varchar(50) not null,
    TelCelular_Cliente numeric(12) not null,
    TelFixo_Cliente numeric(15) not null,
    RG_Cliente numeric(15) not null,
    Email_Cliente varchar(200) not null
    );
    go;

    quinta-feira, 26 de julho de 2018 21:39

Respostas

  • Apenas pra complementar, tenho algumas observações

    1) O modelo conforme está desenhado faz uma relação de 1 endereço por cliente.o que e pouco usado comercialmente.

    2) o campo CPF_Cliente numeric(11) primary key, ou o campo CPF_Cliente char(11).

    força sua tabela somente receber dados de pessoas físicas,  assim caso seja um cliente CNPJ dará erro.

    o mais correto será  CPFCNPJ_Cliente varchar(14)

    3)E mais importante, não faça modelos de dados onde a primary key da tabela representa algo para o negócio. o que eu quero dizer que a função da PK é somente identificar unicamente uma tupla no banco.Logo o melhor a se fazer e criar um IDCliente PK Identity ,e o campo CPFCNPJ_Cliente 

    podendo "A depender do negócio" um índice UNIQUE.



    Wesley Neves - Brasilia-DF     

    https://wesleyneves.wordpress.com/

    SELECT Tab.[that's me:]

    FROM

    (

        VALUES

            ('Wesley Neves'),

            ('Analista.NET'),

            ('Pós Graduando em Banco de Dados com ênfase em BI'),

            ('MTA -SQL Server'),

            ('MTA -Web Developed')

    ) AS Tab ("that's me:");


    "Se a resposta for útil ou ajudar ,não esqueça de marcar"





    Wesley Neves


    sexta-feira, 27 de julho de 2018 11:14
  • Deleted
    sexta-feira, 27 de julho de 2018 01:09
  • Apenas pra complementar, tenho algumas observações

    1) O modelo conforme está desenhado faz uma relação de 1 endereço por cliente.o que e pouco usado comercialmente.

    2) o campo CPF_Cliente numeric(11) primary key, ou o campo CPF_Cliente char(11).

    força sua tabela somente receber dados de pessoas físicas,  assim caso seja um cliente CNPJ dará erro.

    o mais correto será  CPFCNPJ_Cliente varchar(14)

    3)E mais importante, não faça modelos de dados onde a primary key da tabela representa algo para o negócio. o que eu quero dizer que a função da PK é somente identificar unicamente uma tupla no banco.Logo o melhor a se fazer e criar um IDCliente PK Identity ,e o campo CPFCNPJ_Cliente 

    podendo "A depender do negócio" um índice UNIQUE.



    Wesley Neves - Brasilia-DF     

    https://wesleyneves.wordpress.com/

    SELECT Tab.[that's me:]

    FROM

    (

        VALUES

            ('Wesley Neves'),

            ('Analista.NET'),

            ('Pós Graduando em Banco de Dados com ênfase em BI'),

            ('MTA -SQL Server'),

            ('MTA -Web Developed')

    ) AS Tab ("that's me:");


    "Se a resposta for útil ou ajudar ,não esqueça de marcar"





    Wesley Neves


    Wesley,

    Concordo com quase todas as suas observações, menos quando se referi a utiliza um único campo para armazenar tanto o CPF como também o CNPJ, neste caso eu faria bem diferente.

    Criaria uma tabela para armazenar os tipos de pessoas:

    1 - Pessoa Física

    2 - Pessoa Jurídica

    Na tabela de clientes eu guardaria justamente o código que identifica o tipo de pessoa, pois o mesmo cliente pode ser pessoa física e jurídica o que nos poderia forçar a ter dois cadastros, para esta situação poderíamos pensar nos conceitos de generalização ou especialização, onde podemos ter tabelas específicas para armazenar nossos clientes ou então em uma única tabela guardar os dados de todos os clientes.

    Por outro lado, podemos pensar de outra forma, ter uma outra tabela por exemplo chamada DadosComplementaresClientes, e neste tabela, guardados o ID do Cliente cadastrado previamente e complementamos os dados campos justamente com todos os dados referentes aos documentos, independente de ser pessoa física ou jurídica.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    segunda-feira, 30 de julho de 2018 11:33

Todas as Respostas

  • Deleted
    quinta-feira, 26 de julho de 2018 23:38
  • O relacionamento seria de 1:1
    sexta-feira, 27 de julho de 2018 00:43
  • Deleted
    sexta-feira, 27 de julho de 2018 01:09
  • Apenas pra complementar, tenho algumas observações

    1) O modelo conforme está desenhado faz uma relação de 1 endereço por cliente.o que e pouco usado comercialmente.

    2) o campo CPF_Cliente numeric(11) primary key, ou o campo CPF_Cliente char(11).

    força sua tabela somente receber dados de pessoas físicas,  assim caso seja um cliente CNPJ dará erro.

    o mais correto será  CPFCNPJ_Cliente varchar(14)

    3)E mais importante, não faça modelos de dados onde a primary key da tabela representa algo para o negócio. o que eu quero dizer que a função da PK é somente identificar unicamente uma tupla no banco.Logo o melhor a se fazer e criar um IDCliente PK Identity ,e o campo CPFCNPJ_Cliente 

    podendo "A depender do negócio" um índice UNIQUE.



    Wesley Neves - Brasilia-DF     

    https://wesleyneves.wordpress.com/

    SELECT Tab.[that's me:]

    FROM

    (

        VALUES

            ('Wesley Neves'),

            ('Analista.NET'),

            ('Pós Graduando em Banco de Dados com ênfase em BI'),

            ('MTA -SQL Server'),

            ('MTA -Web Developed')

    ) AS Tab ("that's me:");


    "Se a resposta for útil ou ajudar ,não esqueça de marcar"





    Wesley Neves


    sexta-feira, 27 de julho de 2018 11:14
  • Apenas pra complementar, tenho algumas observações

    1) O modelo conforme está desenhado faz uma relação de 1 endereço por cliente.o que e pouco usado comercialmente.

    2) o campo CPF_Cliente numeric(11) primary key, ou o campo CPF_Cliente char(11).

    força sua tabela somente receber dados de pessoas físicas,  assim caso seja um cliente CNPJ dará erro.

    o mais correto será  CPFCNPJ_Cliente varchar(14)

    3)E mais importante, não faça modelos de dados onde a primary key da tabela representa algo para o negócio. o que eu quero dizer que a função da PK é somente identificar unicamente uma tupla no banco.Logo o melhor a se fazer e criar um IDCliente PK Identity ,e o campo CPFCNPJ_Cliente 

    podendo "A depender do negócio" um índice UNIQUE.



    Wesley Neves - Brasilia-DF     

    https://wesleyneves.wordpress.com/

    SELECT Tab.[that's me:]

    FROM

    (

        VALUES

            ('Wesley Neves'),

            ('Analista.NET'),

            ('Pós Graduando em Banco de Dados com ênfase em BI'),

            ('MTA -SQL Server'),

            ('MTA -Web Developed')

    ) AS Tab ("that's me:");


    "Se a resposta for útil ou ajudar ,não esqueça de marcar"





    Wesley Neves


    Wesley,

    Concordo com quase todas as suas observações, menos quando se referi a utiliza um único campo para armazenar tanto o CPF como também o CNPJ, neste caso eu faria bem diferente.

    Criaria uma tabela para armazenar os tipos de pessoas:

    1 - Pessoa Física

    2 - Pessoa Jurídica

    Na tabela de clientes eu guardaria justamente o código que identifica o tipo de pessoa, pois o mesmo cliente pode ser pessoa física e jurídica o que nos poderia forçar a ter dois cadastros, para esta situação poderíamos pensar nos conceitos de generalização ou especialização, onde podemos ter tabelas específicas para armazenar nossos clientes ou então em uma única tabela guardar os dados de todos os clientes.

    Por outro lado, podemos pensar de outra forma, ter uma outra tabela por exemplo chamada DadosComplementaresClientes, e neste tabela, guardados o ID do Cliente cadastrado previamente e complementamos os dados campos justamente com todos os dados referentes aos documentos, independente de ser pessoa física ou jurídica.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    segunda-feira, 30 de julho de 2018 11:33
  • Boa tarde,

    Por falta de retorno essa thread está encerrada.

    Se necessário, favor abrir uma nova thread.

    Atenciosamente,

    Filipe B de Castro

    Esse conteúdo é fornecido sem garantias de qualquer tipo, seja expressa ou implícita

    MSDN Community Support

    Por favor, lembre-se de Marcar como Resposta as postagens que resolveram o seu problema. Essa é uma maneira comum de reconhecer aqueles que o ajudaram e fazer com que seja mais fácil para os outros visitantes encontrarem a resolução mais tarde.

    sexta-feira, 3 de agosto de 2018 19:28
    Moderador