Representação do campo Choice- ou ids-list-

Até certo ponto, qualquer solução dependerá muito exatamente do que você está fazendo e de qual RDBMS está usando. Em geral, embora usar um campo de texto para armazenar uma lista de números inteiros separados por vírgulas seja uma má ideia.

A solução do ponto de partida é sempre uma referência baseada em id. Este é um bom lugar para começar porque obedece a regras relacionais apropriadas e permite que você lide com coisas como valores múltiplos quebrando-os em novas relações. Na verdade, eu diria que é sempre melhor começar por aqui.

As alternativas, entretanto, funcionam bem em alguns casos e com alguns RDBMSs. Campos ENUM (ou, alternativamente, domínios de texto com uma marca para mantê-los dentro de alguns valores) são úteis se você nunca precisar descartar opções. Se o fizer, você deve determinar o que deseja fazer sobre isso antes de descartá-los. Em segundo lugar, os tipos de array também podem ser úteis em certos casos (e eles não necessariamente quebram 1NF se o array como um todo for um valor atômico de um domínio, por exemplo, se representarmos um endereço IPv4 como um array de 4 inteiros de 8 bits ). As abordagens baseadas em array dependem muito do que você está fazendo e do suporte em nível de banco de dados, mas no PostgreSQL eu escolheria um array em que a cardinalidade é importante (ou seja, um array é uma tupla em vez de um conjunto) e onde a semântica é totalmente independente .

Você não nos deu muito com o que trabalhar aqui, sobre o que é a "outra mesa"? Vamos supor que seja uma prioridade personalizada por enquanto.

Para poder definir uma chave estrangeira em vários tipos, você precisa usar Table Inheritance . Haverá uma tabela mestre e ambos os tipos "herdarão" dela, usando o mesmo campo de chave primária.

Existem alguns tipos de herança de tabela. A herança de tabela única usa nulos, mas é muito mais simples. A herança da tabela de classe é normalizada, mas é mais trabalhosa.

PRIORITY
id
type {generic, custom}


PRIORITY_GENERIC
id pk fk PRIORITY
name


PRIORITY_CUSTOM
id pk fk PRIORITY
name
created_at timestamp


USER
id pk
name
priority_id fk PRIORITY


insert into priority values
(1, 'Generic'),
(2, 'Generic'),
(3, 'Generic'),
(4, 'Custom');


insert into priority_generic values 
(1, 'Low'),
(2, 'Medium'),
(3, 'High');


insert into priority_custom values
(4, 'Crazy Super High', current_timestamp);


insert into user values (1, 'neil', 3);
insert into user values (2, 'chris', 4);

A solução "Colunas emparelhadas XOR"

Esta solução consiste em duas colunas que funcionam em conjunto:

• Um caractere anulável variando a coluna "ENUM" que pode ter o valor "Alto", "Médio" ou "Baixo".
• Uma coluna virtual que na verdade seria representada por uma terceira tabela que faz a relação entre a tabela do usuário e a tabela estrangeira. Assim como faria uma clássica relação Muitos-para-Muitos.

Se o primeiro valer "Alto", "Médio" ou "Baixo", o aplicativo apenas aceitaria esse valor e o último seria simplesmente ignorado. Por outro lado, se for NULL, a relação M2M seria usada.