Ist eine einspaltige Tabelle gutes Design?

Question

Es ist in Ordnung, eine Tabelle mit nur einer Spalte zu haben? Ich weiß, dass es technisch nicht illegal ist, aber gilt es als schlechtes Design?

EDIT:

Hier sind ein paar Beispiele:

• Sie haben eine Tabelle mit den 50 gültigen Zustand Codes USA, aber Sie haben keine Notwendigkeit, die ausführlichen Zustandsnamen zu speichern.
• Eine E-Mail-Blacklist.

Jemand erwähnte das Hinzufügen eines Schlüsselfeldes. So wie ich es sehe, wäre diese einzelne Spalte der Primärschlüssel.

Answer 1

Ja, es ist sicherlich ein gutes Design, einen Tisch so zu gestalten, dass er am effizientesten ist. "Schlechtes RDBMS-Design" konzentriert sich normalerweise auf Ineffizienz.

Ich habe jedoch festgestellt, dass die meisten Fälle von Single-Column-Design von einer zusätzlichen Spalte profitieren könnte. Zum Beispiel können Statuscodes typischerweise den vollständigen Statusnamen in einer zweiten Spalte enthalten.Oder eine Blacklist kann Notizen zugeordnet haben. Aber wenn Ihr Design diese Informationen wirklich nicht benötigt, dann ist es völlig in Ordnung, die einzelne Spalte zu haben.

Answer 2

würde ich generell sagen, ja. Nicht sicher, warum Sie nur eine Spalte benötigen. Es gibt einige Ausnahmen, die ich effektiv benutzt habe. Es hängt davon ab, was Sie erreichen wollen.

Sie sind nicht wirklich gutes Design, wenn Sie an das Schema der Datenbank denken, aber sollten wirklich nur als Hilfstabellen verwendet werden.

Ich habe gesehen numbers tables effektiv in der Vergangenheit verwendet.

Answer 3

Der Zweck einer Datenbank besteht darin, Informationen miteinander in Beziehung zu setzen. Wie können Sie das tun, wenn es keine Daten gibt, auf die Sie sich beziehen können?

Vielleicht ist dies eine Art Kompilationstabelle (d. H. Vorname + Nachname + Geburtsdatum), obwohl ich immer noch nicht sicher bin, warum Sie das tun möchten.

EDIT: Ich könnte sehen, mit dieser Art von Tabelle für eine einfache Liste einer Art. Ist das, wofür Sie es verwenden?

Answer 4

Ich habe sie in der Vergangenheit verwendet. Ein Klient von mir wollte jeden blockieren, der versuchte, sich mit einer Telefonnummer in dieser großen Liste zu registrieren, die er hatte, also war es nur eine große schwarze Liste.

Answer 5

Wenn es einen gültigen Bedarf dafür gibt, sehe ich kein Problem. Vielleicht möchten Sie nur eine Liste von Möglichkeiten, die aus irgendeinem Grund angezeigt werden, und Sie möchten in der Lage sein, sie dynamisch zu ändern, müssen sie aber nicht mit einer anderen Tabelle verknüpfen.

Answer 6

Ja, das ist völlig in Ordnung. aber ein ID-Feld könnte es nicht verletzen, richtig?

Answer 7

Der einzige Anwendungsfall, den ich mir vorstellen kann, ist eine Tabelle von Wörtern vielleicht für ein Wortspiel. Sie greifen auf die Tabelle zu, um zu überprüfen, ob eine Zeichenfolge ein Wort ist: Wählen Sie ein Wort aus Wörtern aus, wobei Wort =? Aber es gibt viel bessere Datenstrukturen für das Halten einer Liste von Wörtern als eine relationale Datenbank.

Andernfalls werden Daten in einer Datenbank normalerweise in einer Datenbank gespeichert, um die Beziehungen zwischen verschiedenen Attributen der Daten zu nutzen. Wenn Ihre Daten keine Attribute haben, die über ihren Wert hinausgehen, wie werden diese Beziehungen entwickelt?

Also, obwohl nicht illegal, im Allgemeinen sollten Sie wahrscheinlich keine Tabelle mit nur einer Spalte haben.

Answer 8

In Bezug auf die relational algebra Dies wäre eine einstellige Beziehung sein „dieses Ding existiert“

Ja, die Definition einer solchen Beziehung ist es in Ordnung, einen Tisch haben bedeutet: zum Beispiel, eine Domäne zu definieren.

Die Werte einer solchen Tabelle sollten natürlich natürliche Primärschlüssel sein.

Eine Lookup-Tabelle von prime numbers kommt mir zuerst in den Sinn.

Answer 9

In seltenen Fällen ist eine einspaltige Tabelle sinnvoll. Ich habe eine Datenbank erstellt, in der die Liste der gültigen Sprachcodes eine einspaltige Tabelle war, die als Fremdschlüssel verwendet wurde. Es hatte keinen Sinn, einen anderen Schlüssel zu haben, da der Code selbst der Schlüssel war. Und es gab keine feste Beschreibung, da die Sprachcodebeschreibungen für einige Kontexte von Sprache zu Sprache variieren würden.

Im Allgemeinen ist jeder Fall, in dem Sie eine autorisierende Liste von Werten benötigen, die keine zusätzlichen Attribute aufweisen, ein guter Kandidat für eine einspaltige Tabelle.

Answer 10

Ein Fall, den ich manchmal gefunden ist so etwas wie folgt aus:

Tabelle countries_id, enthält nur eine Spalte mit numerischen ID für jedes Land.

Tabelle countries_description, enthält die Spalte mit Länder-ID, eine Spalte mit Sprach-ID und eine Spalte mit dem lokalisierten Ländernamen.

Tabelle company_factories, enthält Informationen für jede Fabrik des Unternehmens, einschließlich des Landes in Wich befindet sich.

Um Datenkonsistenz und sprachunabhängige Daten in den Tabellen zu erhalten, verwendet die Datenbank dieses Schema mit Tabellen mit nur einer Spalte, um Fremdschlüssel ohne Sprachabhängigkeit zuzulassen.

In diesem Fall denke ich, dass die Existenz von einer Spalte Tabellen gerechtfertigt sind.

als Reaktion auf den Kommentar Herausgegeben von: Quassnoi

http://lh5.ggpht.com/_7ON9I_WO6GU/SikFHBtzcxI/AAAAAAAAA-4/6MrVUCHGoWU/s800/taules.png

In diesem Schema ich einen Fremdschlüssel in der Tabelle company_factories definieren, die mich nicht erforderlich Sprache Spalte der Tabelle enthalten, Aber wenn ich die Tabelle countries_id nicht habe, muss ich die Spalte "Language" in die Tabelle aufnehmen, um den Fremdschlüssel zu definieren.

Answer 11

Ja, solange das Feld der Primärschlüssel ist, wie Sie es sagten. Der Grund dafür ist, dass beim Einfügen doppelter Daten diese Zeilen nur gelesen werden. Wenn Sie versuchen, eine der Zeilen zu löschen, die dupliziert werden. Es funktioniert nicht, da der Server nicht weiß, welche Zeile gelöscht werden soll.

Answer 12

Ich benutze immer die einspaltigen Tabellen - abhängig davon, ob das App-Design bereits eine Datenbank verwendet. Sobald ich den Entwurfsaufwand für die Einrichtung einer Datenbankverbindung ausgehalten habe, lege ich alle änderbaren Daten soweit möglich in Tabellen ein.

Ich denke an zwei Verwendungen können einspaltig Tabellen OTMH:

1) Datenposition existiert. Wird oft in Dropdown-Listen verwendet. Wird auch für einfache Legitimitätstests verwendet.

Eg. zweibuchstabige US-Bundesstaat Abkürzungen; Postleitzahlen, an die wir liefern; Wörter, die in Scrabble legal sind; usw.

2) Sparsames binäres Attribut, dh in einer großen Tabelle ein binäres Attribut, das nur für sehr wenige Datensätze gilt. Anstatt eine neue boolesche Spalte hinzuzufügen, kann ich eine separate Tabelle erstellen, die die Schlüssel der Datensätze enthält, für die das Attribut wahr ist.

Eg. Angestellte, die eine tödliche Krankheit haben; Banken mit einem 360-Tage-Jahr (die meisten nutzen 365); usw.

-Al.

Answer 13

Kein Problem, solange es eindeutige Werte enthält.

Answer 14

Meistens habe ich das in Nachschlagetabellen gesehen, wie in der Statustabelle, die Sie beschrieben haben. Wenn Sie dies tun, stellen Sie sicher, dass Sie die Spalte als Primärschlüssel festlegen, um die Eindeutigkeit zu erzwingen. Wenn Sie diesen Wert nicht als eindeutig festlegen können, sollten Sie keine Spalte verwenden.

Answer 15

Alle meine Tabellen haben mindestens vier Tech-Felder, seriellen Primärschlüssel, Erstellung und Änderung von Zeitstempeln und Soft-Boolean löschen. In jeder Blacklist möchten Sie auch wissen, wer den Eintrag hinzugefügt hat. Für mich ist die Antwort also nein, eine Tabelle mit nur einer Spalte würde keinen Sinn ergeben, außer wenn etwas prototypisiert wird.