Peço desculpas se o título da pergunta é vago, mas não consegui formulá-lo melhor. O que eu gostaria de ter é uma alternativa ao TSQL CREATE TYPE, para poder usá-lo na definição de coluna.
Por exemplo, preciso do tipo "dinheiro" no Oracle, que está tecnicamente NUMBER(18,4)em meu sistema, e cada tabela terá a coluna "dinheiro" em vez de subjacente NUMBERpara fins de consistência. Existem alguns outros "tipos" que eu gostaria de ter aliases em vez de usá-los diretamente.
Infelizmente, ainda não encontrei uma solução aceitável, exceto desistir e usar tipos padrão com restrições (ou especificação de tamanho) para cada coluna. A única abordagem que parece funcionar é criar OBJECTtipo, mas adicionará complexidade desnecessária ao sistema que estou tentando evitar.
Um recurso muito bom do Oracle SUBTYPE, não funciona neste caso. Tanto quanto eu entendo, SUBTYPE(e subtipos de STANDARD) cria tipo de dados PL/SQL que não pode ser usado em SQL. Eu entendo que há várias razões para isso.
Eu me pergunto qual é a melhor prática para tal problema.
Obrigada.
Atualização
Parece até agora que listei todas as abordagens possíveis e prefiro encerrar a questão. Não tenho certeza se pode ser útil para alguém; caso seja, não retiro a pergunta por enquanto.
Esta é uma pergunta muito boa e não apenas porque mostra o esforço de sua parte para respondê-la. Obrigado por perguntar e, por favor, não o remova.
A resposta que você já descobriu é -- Você não pode fazer isso .
Você identificou corretamente vários conceitos semelhantes, incluindo...
Por que os subtipos SQL podem ser úteis? Você mencionou consistência. Aqui estão algumas ideias:
Erros são evitados ao inserir um campo de uma tabela em outra.
A definição do campo não precisa ser lembrada ou pesquisada.
Há menos digitação.
A alteração da definição pode ser feita em um só lugar.
O nome do tipo de dados fornece documentação.
Aqui estão alguns pensamentos sobre isso:
As definições de tabela não são alteradas com frequência. Sim, eles mudam, mas a quantidade de mudança é consideravelmente menor do que em PL/SQL (onde você pode usar subtipos e %tipos) ou código do lado do aplicativo.
Os bancos de dados geralmente são normalizados para eliminar a duplicação de dados e limitar a exigência de que várias tabelas tenham campos com definição idêntica. É claro que algo tão genérico quanto um tipo Money seria usado em muitos lugares, mas alguns tipos seriam movidos para uma tabela de pesquisa e apenas a chave seria repetida em vários lugares.
Freqüentemente, há benefícios em usar tamanhos distintos para tabelas diferentes. Uma loja de descontos pode ter uma tabela de produtos com um campo definido como Número(4,2), pois eles nunca vendem nada acima de dez dólares. A própria definição é uma restrição nos dados, uma restrição que melhora a precisão, documenta o sistema, é rápida, não pode ser contornada e é melhor do que qualquer restrição do lado do aplicativo. Se a empresa decidir remover essa restrição aumentando o tamanho do campo, isso não significa necessariamente que ela precise alterar o tamanho de outros campos, como Salary, SalesAmount etc.
Os dados desnormalizados geralmente são agregados e podem exigir tamanhos de campo diferentes. Uma coluna de salário não precisa ser Number(18,4) e até mesmo uma soma de todas as colunas salariais em toda a empresa não precisa ser Number(18,4) (pouco menos de 100 trilhões). Mesmo que você precise aumentar o campo agregado contendo informações de Salário devido ao crescimento da empresa, ainda não precisaria necessariamente aumentar o campo Salário ao mesmo tempo, mas se eles forem baseados no mesmo subtipo SQL, então você teria sem escolha. Os campos de tamanho certo têm a vantagem de usar menos armazenamento e memória, além de ter pesquisas de índice e tabela mais rápidas.
Lembrar ou procurar um tipo personalizado é semelhante em dificuldade a lembrar ou procurar uma definição de campo usada anteriormente.
O Oracle converte o tipo SQL Server Money em Number(19,4) ao usar o 10.2 Transparent Gateway , portanto, mesmo padronizar em Number(18,4) seria errado ao trabalhar com o gateway.
No Oracle, frequentemente são criadas colunas de tabelas que incluem definições que poderiam estar no nome do tipo de dados para outros sistemas. Por exemplo, Wholesale com um tipo de dados Money pode ser WholesaleCost no Oracle para que fique claro que o campo contém relação a dinheiro. Às vezes, essa desabiguação seria necessária de qualquer maneira, como se houvesse campos UnitCount, UnitVolume e UnitCosts. Outras vezes, o próprio nome revela o tipo (como Salário). Finalmente, comentários podem ser colocados nas colunas da tabela para fornecer mais esclarecimentos, se necessário.
Digo tudo isso não para dizer que o conceito de um subtipo SQL é ruim, apenas que não é tão útil quanto parece.
Outra abordagem (ainda em um nível superior) pode ser usar uma ferramenta de modelagem ER que suporte domínios.
Em seguida, você pode definir um domínio "dinheiro" (ou o que for necessário) em seu modelo e a ferramenta criará o tipo "nativo" correspondente fora do domínio quando você projetar seu modelo.