Une table à une colonne est-elle bien conçue? [fermé]

Est-il acceptable d'avoir une table avec une seule colonne? Je sais que ce n'est pas techniquement illégal, mais est-ce considéré comme une mauvaise conception?

ÉDITER:

Voici quelques exemples:

• Vous avez une table avec les 50 codes d'état américains valides, mais vous n'avez pas besoin de stocker les noms d'états détaillés.
• Une liste noire d'e-mails.

Quelqu'un a mentionné l'ajout d'un champ clé. La façon dont je le vois, cette seule colonne SERAIT la clé primaire.

Oui, c'est certainement une bonne conception de concevoir une table de manière à la rendre plus efficace. «Bad RDBMS Design» est généralement centré sur l'inefficacité.

Cependant, j'ai constaté que la plupart des cas de conception à colonne unique pourraient bénéficier d'une colonne supplémentaire. Par exemple, les codes d'état peuvent généralement avoir le nom complet de l'état dans une deuxième colonne. Ou une liste noire peut avoir des notes associées. Mais, si votre conception n'a vraiment pas besoin de ces informations, alors il est parfaitement normal d'avoir une seule colonne.

En termes de relational algebraceci serait une relation unaire, signifiant " cette chose existe "

Oui, c'est bien d'avoir une table définissant une telle relation: par exemple, pour définir un domaine.

Les valeurs d'une telle table doivent bien entendu être des clés primaires naturelles.

Une table de consultation de prime numbersest ce qui me vient à l'esprit en premier.

Je les ai utilisés dans le passé. Un de mes clients voulait bloquer automatiquement toute personne essayant de s'inscrire avec un numéro de téléphone dans cette grande liste qu'il avait donc c'était juste une grande liste noire.

S'il y a un besoin valable, je ne vois pas de problème. Peut-être que vous voulez juste une liste de possibilités à afficher pour une raison quelconque et que vous voulez pouvoir la changer dynamiquement, mais n'avez pas besoin de la lier à une autre table.

Un cas que j'ai trouvé parfois est quelque chose comme ceci:

La table country_id , contient une seule colonne avec un identifiant numérique pour chaque pays.

La table country_description contient la colonne avec l'ID du pays, une colonne avec l'ID de la langue et une colonne avec le nom du pays localisé.

Le tableau company_factories contient des informations pour chaque usine de l'entreprise, y compris le pays dans lequel se trouve.

Ainsi, pour maintenir la cohérence des données et les données indépendantes de la langue dans les tables, la base de données utilise ce schéma avec des tables avec une seule colonne pour autoriser les clés étrangères sans dépendances linguistiques.

Dans ce cas, je pense que l'existence de tables à une colonne est justifiée.

Édité en réponse au commentaire de: Quassnoi

_{(source: ggpht.com )}

Dans ce schéma, je peux définir une clé étrangère dans la table company_factories qui ne m'oblige pas à inclure la colonne Language sur la table, mais si je n'ai pas la table country_id, je dois inclure la colonne Language sur la table pour définir la clé étrangère .

Il y aurait de rares cas où une table à une seule colonne aurait du sens. J'ai fait une base de données où la liste des codes de langue valides était une table à une seule colonne utilisée comme clé étrangère. Il était inutile d'avoir une clé différente, puisque le code lui-même était la clé. Et il n'y avait pas de description fixe puisque les descriptions des codes de langue variaient selon la langue pour certains contextes.

En général, tous les cas où vous avez besoin d'une liste de valeurs faisant autorité qui n'ont aucun attribut supplémentaire est un bon candidat pour une table à une colonne.

J'utilise tout le temps des tables à une seule colonne - selon, bien sûr, si la conception de l'application utilise déjà une base de données. Une fois que j'ai supporté la surcharge de conception liée à l'établissement d'une connexion à une base de données, je place toutes les données mutables dans des tables lorsque cela est possible.

Je peux penser à deux utilisations des tables à une seule colonne OTMH:

1) L'élément de données existe. Souvent utilisé dans les listes déroulantes. Également utilisé pour des tests de légitimité simples.

Par exemple. abréviations des États américains à deux lettres; Codes postaux vers lesquels nous expédions; mots légaux au Scrabble; etc.

2) Attribut binaire épars, c'est-à-dire, dans une grande table, un attribut binaire qui ne sera vrai que pour un très petit nombre d'enregistrements. Au lieu d'ajouter une nouvelle colonne booléenne, je pourrais créer une table séparée contenant les clés des enregistrements pour lesquels l'attribut est vrai.

Par exemple. les employés qui ont une maladie terminale; les banques avec une année de 360 ​​jours (la plupart utilisent 365); etc.

-Al.

Aucun problème tant qu'il contient des valeurs uniques.

La plupart du temps, j'ai vu cela dans les tables de type de recherche telles que la table d'état que vous avez décrite. Cependant, si vous faites cela, assurez-vous de définir la colonne comme clé primaire pour forcer l'unicité. Si vous ne pouvez pas définir cette valeur comme unique, vous ne devriez pas utiliser une seule colonne.

Je dirais en général, oui. Je ne sais pas pourquoi vous n'avez besoin que d'une seule colonne. Il y a quelques exceptions à cela que j'ai vues utilisées efficacement. Cela dépend de ce que vous essayez d'accomplir.

Ils ne sont pas vraiment de bonne conception lorsque vous pensez au schéma de la base de données, mais ne devraient vraiment être utilisés que comme tables utilitaires.

J'ai vu des tableaux de nombres utilisés efficacement dans le passé.

Le but d'une base de données est de relier des éléments d'information les uns aux autres. Comment pouvez-vous faire cela quand il n'y a pas de données à relier?

C'est peut-être une sorte de table de compilation (c'est-à-dire Prénom + Nom + Date de naissance), même si je ne sais toujours pas pourquoi vous voudriez faire cela.

EDIT: Je pourrais voir utiliser ce type de tableau pour une simple liste d'une sorte. Est-ce pour cela que vous l'utilisez?

Oui tant que le champ est la clé primaire comme vous l'avez dit. La raison en est que si vous insérez des données en double, ces lignes seront en lecture seule. Si vous essayez de supprimer l'une des lignes dupliquées. cela ne fonctionnera pas car le serveur ne saura pas quelle ligne supprimer.

Le seul cas d'utilisation que je puisse concevoir est une table de mots peut-être pour un jeu de mots. Vous accédez au tableau juste pour vérifier qu'une chaîne est un mot: sélectionnez le mot parmi les mots où mot =?. Mais il existe de bien meilleures structures de données pour contenir une liste de mots qu'une base de données relationnelle .

Sinon, les données d'une base de données sont généralement placées dans une base de données pour tirer parti des relations entre divers attributs des données. Si vos données n'ont pas d'attributs au-delà de leur valeur, comment ces relations seront-elles développées?

Donc, bien que ce ne soit pas illégal, en général, vous ne devriez probablement pas avoir de table avec une seule colonne.

Toutes mes tables ont au moins quatre champs techniques, une clé primaire série, des horodatages de création et de modification et un booléen de suppression logicielle. Dans n'importe quelle liste noire, vous voudrez également savoir qui a ajouté l'entrée. Donc pour moi, la réponse est non, une table avec une seule colonne n'aurait pas de sens sauf lors du prototypage de quelque chose.

Oui, c'est parfaitement bien. mais un champ d'identification ne pouvait pas nuire, non?