[firebase-br] PARADOX para FIREBIRD 3.0 - varchar em chaves primarias

[Gladiston Santana]

Olá gustavo

PKs serem compostas é até comum e não vejo problema com isso em qualquer
banco de dados.
Apenas PKs não poderão ser nulos porque isso impediria o uso da integridade
referencial, mas se não fosse isso, dados ou indices com nulos são normais.

Se você quer uma validação de dados com nulos/vazios não poderá usar
integridade referencial.
Nesse caso você precisa criar constraints que são regras de validação de
dados que são aplicados aos campos, o mais comum no firebird é criar
dominios com essas constraints.
Dominios são tipos de dados que se repetem, ao inves de ficar criando
varchar(255) para todo campo de descrição que uma tabela precise, eu crio
um dominio com esse tipo e o referencio todas as vezes que precisar dum
varchar(255) para usa-lo como descrição em qualquer tabela ou codigo
procedural sql.
Isso você pode fazer para todos os tipos de dados que for usar.
Você pode criar um dominio e nele já fazer uma validação, por exemplo,
imagine uma tabela de cliente que tem o campo chamado 'UF' e que ele tem
que ter um valor que exista na tabela UF, mas que por motivos obscuros deva
ser permitido branco e nulo:
CREATE DOMAIN D_END_UF AS CHAR(2) DEFAULT 'SP'
CHECK ((COALESCE(VALUE,'')='') OR
       (EXISTS(SELECT * FROM UF WHERE UF=VALUE)));
No exemplo acima criei um DOMINIO com o nome D_END_UF com a regra que
mencionei.
O Default 'SP' só será usado por omissão no insert, isto é, quando alguem
faz o insert into(...) mas esquece de mencionar o campo.

Agora vamos usá-lo em nossa tabela de clientes:
create table clientes(
  razao_social varchar(255),
  (....),
CAMPO_UF   D_END_UF  );

Dessa forma poderá contornar, se for preciso, as validações por PK/FK.

[]´s e sucesso.

Em qua, 1 de mai de 2019 às 15:05, Gustavo Novaes <gutonovaes19 em gmail.com>
escreveu:

> No banco de dados legado, muitas tabelas possui como chave primaria,
> composta de 2 ou mais campos varchar(8) que podem ou não estarem
> preenchidos.
> Por exemplo hipotetico.
> tabela de empresas - CODEMPRESA (VARHAR 8) , nomeempresa (varchar(30))
> tabela de departamentos (CODEMPRESA (FK), CODDEP (VARCHAR(8))
>
> Tabela qualquer do banco de dados, onde eu poderia incluir parâmetros para
> a aplicação que seriam válidos para empresa toda ou para um determinado
> departamento.
> TABELA DE PARAMETROS (CODEMPRESA(FK-EMPRESAS), CODDEPTO (FK-DEPARTAMENTOS),
> PARAMETRO1 (INTEGER, PARAMETRO2 (INTEGER)
>
> PARAMETROS.CODEMPRESA - não permite NULL
> PARAMETROS .DEPARTAMENTO - permite nullo
>
> Enfim, é só para exemplificar minha dúvida.
> Ao migrar para FIREBIRD, "sei" que não seria correto manter essa estrutura
> mas, diante da necessidade de apenas trocar banco e aproveitar ao máximo os
> códigos delphi existentes, como eu poderia trabalhar com essa situação?
>
> Obrigado mais uma vez.
>
>
> *Gustavo Novaes *
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas:
> http://www.firebase.com.br/pesquisa_lista.html
>


-- 
A Vidy possui um Sistema de Gestão da Qualidade estruturado e com
Certificação ISO 9001 há mais de 10 anos, mantendo seu foco na Qualidade e
na Melhoria Continua.

Em março de2018 migramos com sucesso para a nova versão da ISO 9001.

Somos a única Empresa Brasileira de Engenharia de Laboratórios com
certificação com o Escopo Completo; desde Projetos, Engenharia, Construção,
Fabricação e Instalação de Laboratórios.