Início / dba / Perguntas / 58308
Accepted
starlocke
Asked: 2014-02-06 12:00:53 +0800 CST

Existe um nome conhecido para esse padrão de design de esquema "referência do pobre homem"?

  • 772

Existe um nome para o seguinte design/padrão de esquema de banco de dados? Meu objetivo final é encontrar mais literatura sobre o assunto. A pesquisa superficial de hoje estava muito cheia de palavras genéricas para definir o termo (se houver) para esse tipo de coisa:

Fruit (id, farm)

Apple (fruit_id, color)
    [fruit_id => Fruit.id]

Banana (fruit_id, length)
    [fruit_id => Fruit.id]

Orange (fruit_id, is_seedless)
    [fruit_id => Fruit.id]

FruitPack (id, destination)

FruitPackFruits (fruitpack_id, fruit_id, fruit_type)
    [fruit_id => Fruit.id, fruit_type => VARCHAR]

Onde fruit_type seria uma coluna varchar preenchida com valores como "Apple, Banana, Orange, Cherry". É uma espécie de "integridade referencial do pobre homem". Obviamente, uma das falhas desse tipo de projeto é poder inserir valores que não resultam em uma junção útil (ou seja: não há cerejas para falar aqui).

Aqui está outro exemplo de tal padrão: Uma única tabela "log (id, table_name, record_id, timestamp)" que atua como uma espécie de rastreador de tempos de modificação em várias outras tabelas. Estritamente falando, não tem integridade de referência, mas a parte (table_name, record_id) deve se referir a algum registro em outra tabela, exigindo uma junção para realmente obter os dados completos.

Vou assumir que o esquema é uma caricatura suficiente de algum tipo de coleção de grupos de itens para as pessoas aqui.

A questão é: como se chama esse tipo de "integridade referencial do pobre homem"?

Não estou tentando aprender sobre integridade referencial. Quero identificar o nome desse design ruim e examinar mais detalhadamente os aspectos "vamos projetar um esquema de banco de dados" (ex: prós, contras, opiniões, ensinamentos, etc.) que têm a ver com esse desastre de esquema comumente visto.

database-design design-pattern

2 respostas

  1. Seu design se parece um pouco com o padrão "supertipo/subtipo" . Pesquise por isso e por "herança de tabela" . No entanto, ele precisa de muito trabalho para poder impor restrições de integridade.

    Está faltando uma Fruittabela genérica (que é o "supertipo" ) e uma FruitTypetabela para armazenar os tipos de frutas permitidos:

    FruitType 
    fruit_type PK

Fruit
    fruit_type PK, FK -> FruitType (fruit_type)
    fruit_id   PK

    Então as 3 (ou 4 ou mais) tabelas seriam (as tabelas "subtipo" ):

    Apple
    fruit_type 
    fruit_id PK
    (fruit_type, fruit_id) FK -> Fruit (fruit_type, fruit_id)
    CHECK (fruit_type = 'Apple')

Banana 
    fruit_type PK
    fruit_id PK
    (fruit_type, fruit_id) FK -> Fruit (fruit_type, fruit_id)
    CHECK (fruit_type = 'Banana')

Orange
    fruit_type PK
    fruit_id PK
    (fruit_type, fruit_id) FK -> Fruit (fruit_type, fruit_id)
    CHECK (fruit_type = 'Orange')

    E qualquer outra tabela pode referenciar a Fruittabela:

    FruitPack 
    fruitpack_id PK 
    destination

FruitPackFruits 
    fruitpack_id FK -> FruitPack (fruitpack_id)
    fruit_id     
    fruit_type
    (fruit_type, fruit_id) FK -> Fruit (fruit_type, fruit_id)

    Não parece muito bom e uma coluna em cada tabela "fruta" parece redundante, pois tem um e apenas um valor permitido. E toda vez que você precisar adicionar uma nova fruta (digamos, cereja), você deve adicionar uma linha na tabela FruitTypee uma nova tabela ( Cherry), semelhante às outras. Portanto, funciona melhor se o seu design for mais ou menos estável. Se você achar que precisa adicionar uma nova "fruta" a cada poucos dias ou se tiver mil (ou mais!) Frutas diferentes, não é a melhor maneira.

    Por outro lado, reforça a integridade e você não pode inserir cerejas nas bananas ou laranjas nas maçãs.

    • 5
  2. Best Answer

    Ah! Graças ao comentário de @ypercube sobre "herança", consegui dar um salto de lógica/contexto e encontrei alguns exemplos concretos que dão o nome de "Associações Polimórficas" a esse tipo de design de esquema.

    Na verdade, isso é "uma coisa" a ser reconhecida no mundo DBA e, IMHO, isso também é algo a ser odiado e até queimado no fogo do inferno.

    No cenário "vamos registrar tudo", provavelmente é bom seguir a sabedoria da IBM e criar um conjunto de tabelas "_history" (anexadas) 1 para 1 mais acionadores. Parece que isso também se aplica a tabelas que atuam como armazenamentos de tradução "i18n + L10n".

    Não tenho certeza do que pensar sobre o cenário "vamos agrupar diferentes tipos de itens" neste momento, além de "associações polimórficas provavelmente são uma má ideia a longo prazo". Eles são extremamente desagradáveis ​​de rastrear/seguir/entender/consultar, no meu contexto de um aplicativo baseado em MVC.

    • 4

relate perguntas