Para domínio ou não para domínio

15

Os padrões SQL92 e SQL99 definem CREATE DOMAIN DDL . Nem todos os bancos de dados suportam isso ou têm um nome diferente para ele (o SQL Server tem Tipos definidos pelo usuário , por exemplo).

Isso permite que se defina um tipo de dados restrito a ser usado em seu banco de dados, para simplificar e aplicar regras relativas aos valores permitidos. Tal tipo de dados poderia ser usado em declarações de coluna, em entradas e saídas para procedimentos armazenados e funções, etc ...

Eu gostaria de saber:

  • As pessoas realmente usam domínios em seus projetos de banco de dados?
  • Se sim, em que medida?
  • Quão úteis são eles?
  • Quais armadilhas você encontrou?

Estou tentando avaliar a viabilidade de usá-los no futuro desenvolvimento de banco de dados.

    
por Oded 23.09.2011 / 21:10
fonte

7 respostas

2

Como de costume ...

Depende

Você tem uma entidade de domínio usada em mais de um lugar que o suporte nativamente exigiria esforços consideráveis e / ou restrições e comportamentos redundantes ?

Em caso afirmativo, ignore o domínio. Se não, não se incomode.

Achei necessário criar um tipo definido pelo usuário no SQL Server exatamente uma vez, com base na heurística acima. Eu nem lembro mais o que era - mas economizou mais trabalho do que causou.

    
por 01.10.2011 / 19:26
fonte
5

Como usuário do SQL Server e do C #, não usei Tipos definidos pelo usuário no banco de dados, pois sou bem mais poderoso no lado do aplicativo. Evento após ORMs como o LINQ to SQL e o Entity Framework, meu uso dos recursos do servidor diminuiu muito.

Por exemplo, eu estava usando a integração CLR para carregar algumas funções de conversão DateTime para o SQL Server para transferir datas de Gregoriano para outros formatos, com base no poder de Globalização do .NET. Mas agora as coisas são diferentes e eu não faço mais isso. Eu simplesmente carrego os dados e faço a transformação, diretamente na minha camada de aplicação.

Então, depois de quase 4 anos de programação e inspecionando todas as equipes em que posso pensar, não encontrei nenhuma amostra do uso de tipos definidos pelo usuário. Eu também não o vi em ação em muitos blogs .NET.

Embora isso não signifique que as pessoas não usem Domínio de banco de dados , isso certamente significa que pelo menos o domínio de banco de dados não é tão comum.

    
por 23.09.2011 / 21:59
fonte
3

Já existe um resposta detalhada no Stack Overflow. Eu principalmente concordo com isso, mas não com o exemplo dado, cito:

“For example, I define a "GenderType" (char(1), not nullable, holding "M" or "F") that ensures that only appropriate data is permitted in the Gender field.”

Pessoalmente, sinto-me mais à vontade ao definir char(1) type e ao definir uma restrição na coluna. Quando a restrição é violada, sei exatamente onde procurar para encontrar o que fiz de errado. Também é mais conhecido que os tipos definidos pelo usuário, portanto, o banco de dados que usa apenas restrições seria mais fácil de entender para um iniciante.

Claro, apenas é apenas uma opinião pessoal. Outras pessoas diriam que uma restrição in ('M', 'F') não é auto-documentada e pode ser muito obscura para um desenvolvedor novo que descobre o banco de dados.

IMO, use tipos definidos pelo usuário para tipos mais complicados e restrições para algo básico. Além disso, quando você não consegue encontrar facilmente um nome explícito para um tipo, há uma chance de que uma restrição se ajuste melhor.

    
por 23.09.2011 / 22:00
fonte
1

Eu mesmo não usei esse recurso, mas acho que você precisa se certificar de que:

  1. Se o seu banco de dados for usado por um único sistema, talvez faça sentido não usar esse recurso e adicionar a lógica de verificação em sua camada comercial ou equivalente. Isso lhe dará mais flexibilidade na validação (digamos, usando expressões regulares) e tornará possível encapsular toda a lógica de validação em um só lugar. Se o seu banco de dados é compartilhado por vários sistemas, você pode usar gatilhos que são adequados para esta tarefa.

  2. Não tenho certeza se o UDT permite personalizar as mensagens de erro retornadas ao cliente quando um erro de validação é encontrado.

  3. Os UDTs são muito úteis se a mesma regra de validação se aplicar a várias colunas. Na minha opinião, não vejo isso como um caso muito comum em aplicativos comerciais com design de banco de dados normalizado.

Você pode estar interessado em verificar "Qual é o objetivo do [SQL Server]? Tipos definidos? " artigo de blog.

    
por 24.09.2011 / 00:24
fonte
0

Quando você diz "nem todos os bancos de dados suportam isso", acho que uma maneira melhor de colocá-lo é a seguinte:

Cada grande banco de dados suporta isso, já que eles suportam gatilhos, funções e outros recursos avançados extensivamente.

Isso nos leva à conclusão de que isso faz parte do SQL avançado e faz sentido em algum momento.

Do people actually use domains in their database designs?

O menos possível, devido à extensa cobertura requerida (considerando operadores, índices, etc.)

If so to what extent?

Mais uma vez, por mais limitado que seja, se um tipo existente combinado com um pouco de lógica adicional definida (por exemplo, cheques, etc.) pode resolver o problema, por que ir tão longe?

How useful are they?

Muita coisa. Vamos considerar por um segundo um DBMS não tão bom como o MySQL, que escolhi para este exemplo por um motivo: ele não tem um bom suporte para o tipo inet (endereço IP).

Agora você quer escrever um aplicativo que é mais focado em dados IP como intervalos e tudo isso, e você está preso com o tipo padrão e sua funcionalidade limitada, você pode escrever funções e operadores adicionais (como aqueles suportados nativamente no postgreSQL por exemplo) ou escreva consultas muito mais complexas para todas as funcionalidades que você precisa.

Este é um caso onde você facilmente justificará o tempo gasto na definição de suas próprias funções (inet > > inet no PostgreSQL: range contido no operador range).

Nesse ponto, você já justificou a extensão do suporte a tipos de dados, há apenas uma outra etapa para definir um novo tipo de dados.

Agora, de volta ao PostgreSQL, que tem suporte de tipo legal, mas sem int não assinado ... o que você precisa, porque você está realmente preocupado com armazenamento / desempenho (quem sabe ...), bem, você precisa adicioná-lo como bem como os operadores - embora, claro, isso é principalmente derivando operadores int existentes.

What pitfalls have you encountered?

Eu não brinco com isso, pois até agora não tive um projeto que exigisse e justificasse o tempo necessário para isso.

Os maiores problemas que posso ver com isso seria reinventar a roda, introduzindo bugs na camada "segura" (db), suporte de tipo incompleto que você só perceberá meses depois quando o seu CONCAT (cast * AS varchar) falha porque você não definiu um cast (newtype as varchar), etc.

Há respostas falando sobre "incomum" etc. Definitivamente, elas são e devem ser incomuns (caso contrário, o dbms não possui muitos tipos importantes), mas, por outro lado, deve-se lembrar que um (bom) db é Compatível com ACID (ao contrário de um aplicativo) e que qualquer coisa relacionada à consistência é melhor mantida lá.

Existem muitos casos em que a lógica de negócios é tratada na camada de software e isso pode ser feito em SQL, onde é mais seguro. Os desenvolvedores de aplicativos tendem a se sentir mais confortáveis com a camada de aplicativos e, muitas vezes, evitam soluções melhores implementadas em SQL. Isso não deve ser considerado uma boa prática.

UDT's podem ser uma boa solução para otimização, um bom exemplo é dado em outra resposta sobre o tipo m / f usando char (1). Se tivesse sido um UDT, poderia ser um booleano (a menos que queiramos oferecer a terceira e quarta opções). É claro que todos nós sabemos que isso não é realmente otimização por causa da sobrecarga da coluna, mas a possibilidade existe.

    
por 27.09.2011 / 09:18
fonte
0

No papel, os UDTs são um ótimo conceito. Eles permitem que você realmente normalize seu banco de dados (por exemplo, quando você tem duas colunas que dependem umas das outras) e também para encapsular qualquer lógica relacionada ao seu novo tipo.

Na prática, o preço que você paga (hoje) é muito alto. Obviamente, há a sobrecarga de desenvolvimento, mas, além disso, você perde o suporte de uma variedade de ferramentas de relatórios e ORM e aumenta bastante a complexidade geral da solução. Não há muitos desenvolvedores por aí que estão intimamente familiarizados com os UDTs, e eu nunca vi UDTs gerenciados usados fora dos exemplos.

Um dos melhores exemplos de um tipo que é melhor feito como um UDT (se já não existir) teria que ser hierarchyid ( Link do MSDN . Para se manter eficiente, ele armazena seu valor em um formato binário (em oposição às implementações customizadas usuais do varchar), o que seria difícil de manter sem as funções do tipo. Os 10 ou mais métodos que o tipo fornece também são melhor fornecidos como parte do tipo, em oposição a funções externas. Eu consideraria o uso de UDT gerenciado personalizado em casos como esse - em que há um ganho significativo a ser obtido ao fornecer uma implementação eficiente e organizada como um tipo separado.

    
por 27.09.2011 / 11:58
fonte
0

Uma pergunta / resposta mais prática. Sua empresa permite usá-lo?

A sua empresa trabalha com vários D.B. S.Q.L. marcas que lidam com diferentes DDL (s)?

Cada marca de banco de dados pode oferecer bons recursos adicionais, como os tipos definidos pelo usuário, mas, se sua empresa usar vários D.B., você poderá ter problemas com os recursos não padrão.

Se a empresa é sua única você, ou você pode decidir quais bancos de dados & características que você vai usar, então você pode usar D.D.L.

Tenho trabalhado com vários projetos nos quais um tipo definido pelo usuário pode ser útil, mas devo me ater a mais recursos padrão, já que tivemos que lidar com vários bancos de dados. (s).

    
por 27.09.2011 / 17:15
fonte