Uma tabela de uma coluna é um bom design? [fechadas]

Tudo bem ter uma tabela com apenas uma coluna? Eu sei que não é tecnicamente ilegal, mas é considerado um design ruim?

EDITAR:

Aqui estão alguns exemplos:

• Você tem uma tabela com os 50 códigos de estado dos EUA válidos, mas não precisa armazenar os nomes de estado detalhados.
• Uma lista negra de e-mail.

Alguém mencionou a adição de um campo-chave. A meu ver, essa única coluna SERIA a chave primária.

Sim, certamente é um bom design projetar uma mesa de forma a torná-la mais eficiente. "Projeto RDBMS ruim" geralmente é centrado na ineficiência.

No entanto, descobri que a maioria dos casos de design de coluna única poderia se beneficiar de uma coluna adicional. Por exemplo, os Códigos de estado geralmente podem ter o nome completo do estado escrito em uma segunda coluna. Ou uma lista negra pode ter notas associadas. Mas, se o seu projeto realmente não precisa dessa informação, então é perfeitamente normal ter uma coluna única.

Em termos relational algebradisso, seria uma relação unária, o que significa que " essa coisa existe "

Sim, é bom ter uma tabela definindo tal relação: por exemplo, para definir um domínio.

Os valores de tal tabela devem ser chaves primárias naturais, é claro.

Uma tabela de pesquisa de prime numbersé o que vem à minha mente primeiro.

Eu os usei no passado. Um cliente meu queria bloquear automaticamente qualquer pessoa que tentasse se inscrever com um número de telefone dessa grande lista que ele tinha, então era apenas uma grande lista negra.

Se houver uma necessidade válida para isso, não vejo nenhum problema. Talvez você queira apenas uma lista de possibilidades para ser exibida por algum motivo e queira poder alterá-la dinamicamente, mas não precisa vinculá-la a outra tabela.

Um caso que encontrei às vezes é algo assim:

A tabela countries_id contém apenas uma coluna com ID numérico para cada país.

A tabela countries_description contém a coluna com o ID do país, uma coluna com o ID do idioma e uma coluna com o nome do país localizado.

A tabela company_factories , contém informações para cada fábrica da empresa, incluindo o país em que está localizada.

Portanto, para manter a coerência dos dados e os dados independentes do idioma nas tabelas, o banco de dados usa esse esquema com tabelas com apenas uma coluna para permitir chaves estrangeiras sem dependências de idioma.

Neste caso acho que se justifica a existência de tabelas de uma coluna.

Editado em resposta ao comentário de: Quassnoi

_{(fonte: ggpht.com )}

Neste esquema, posso definir uma chave estrangeira na tabela company_factories que não exige que eu inclua a coluna Language na tabela, mas se eu não tiver a tabela countries_id, devo incluir a coluna Language na tabela para definir a chave estrangeira .

Haveria casos raros em que uma tabela de coluna única faria sentido. Fiz um banco de dados em que a lista de códigos de idioma válidos era uma tabela de coluna única usada como chave estrangeira. Não fazia sentido ter uma chave diferente, já que o próprio código era a chave. E não havia uma descrição fixa, uma vez que as descrições do código do idioma variam de acordo com o idioma para alguns contextos.

Em geral, qualquer caso em que você precise de uma lista oficial de valores que não tenham atributos adicionais é um bom candidato para uma tabela de uma coluna.

Eu uso tabelas de coluna única o tempo todo - dependendo, é claro, se o design do aplicativo já usa um banco de dados. Depois de suportar a sobrecarga de design de estabelecer uma conexão de banco de dados, coloquei todos os dados mutáveis ​​em tabelas, sempre que possível.

Posso pensar em dois usos para tabelas OTMH de coluna única:

1) Existe item de dados. Freqüentemente usado em listas suspensas. Também usado para testes de legitimidade simples.

Por exemplo. abreviações de duas letras dos estados dos EUA; CEPs para os quais enviamos; palavras legais no Scrabble; etc.

2) Atributo binário esparso, ou seja, em uma grande tabela, um atributo binário que será verdadeiro para apenas alguns registros. Em vez de adicionar uma nova coluna booleana, posso criar uma tabela separada contendo as chaves dos registros para os quais o atributo é verdadeiro.

Por exemplo. funcionários com doença terminal; bancos com um ano de 360 ​​dias (a maioria usa 365); etc.

-Al.

Não tem problema, desde que contenha valores únicos.

Geralmente, já vi isso em tabelas de tipo de pesquisa, como a tabela de estado que você descreveu. No entanto, se você fizer isso, certifique-se de definir a coluna como a chave primária para forçar a exclusividade. Se você não pode definir esse valor como exclusivo, você não deve usar uma coluna.

Eu diria em geral, sim. Não sei por que você precisa de apenas uma coluna. Existem algumas exceções que eu vi serem usadas com eficácia. Depende do que você está tentando alcançar.

Eles não têm um design muito bom quando você está pensando no esquema do banco de dados, mas devem ser usados ​​apenas como tabelas de utilitários.

Já vi tabelas de números usadas com eficácia no passado.

O objetivo de um banco de dados é relacionar informações entre si. Como você pode fazer isso quando não há dados com os quais se relacionar?

Talvez seja algum tipo de tabela de compilação (ou seja, Nome + Sobrenome + Data de nascimento), embora eu ainda não saiba por que você deseja fazer isso.

EDIT: Eu poderia ver usando este tipo de tabela para uma lista simples de algum tipo. É para isso que você está usando?

Sim, desde que o campo seja a chave primária como você disse que seria. A razão é porque, se você inserir dados duplicados, essas linhas serão somente leitura. Se você tentar excluir uma das linhas que estão duplicadas. não funcionará porque o servidor não saberá qual linha excluir.

O único caso de uso que posso conceber é uma mesa de palavras, talvez para um jogo de palavras. Você acessa a tabela apenas para verificar se uma string é uma palavra: selecione a palavra das palavras em que palavra =?. Mas existem estruturas de dados muito melhores para manter uma lista de palavras do que um banco de dados relacional .

Caso contrário, os dados em um banco de dados geralmente são colocados em um banco de dados para tirar proveito dos relacionamentos entre os vários atributos dos dados. Se seus dados não possuem atributos além de seu valor, como essas relações serão desenvolvidas?

Portanto, embora não seja ilegal, em geral você provavelmente não deve ter uma tabela com apenas uma coluna.

Todas as minhas tabelas têm pelo menos quatro campos de tecnologia, chave primária serial, timestamps de criação e modificação e booleano de exclusão reversível. Em qualquer lista negra, você também desejará saber quem adicionou a entrada. Portanto, para mim, a resposta é não, uma tabela com apenas uma coluna não faria sentido, exceto ao prototipar algo.

Sim, está perfeitamente bem. mas um campo de ID não poderia machucar certo?