Ist eine einspaltige Tabelle ein gutes Design? [geschlossen]

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

BEARBEITEN:

Hier einige Beispiele:

• Sie haben eine Tabelle mit den 50 gültigen US-Bundesstaatencodes, müssen jedoch die ausführlichen Statusnamen nicht 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.

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

Ich habe jedoch festgestellt, dass die meisten Fälle des Entwurfs einer einzelnen Spalte von einer zusätzlichen Spalte profitieren könnten. Beispielsweise können Statuscodes normalerweise den vollständigen Statusnamen in einer zweiten Spalte enthalten. Oder einer schwarzen Liste können Notizen zugeordnet sein. Wenn Ihr Design diese Informationen jedoch wirklich nicht benötigt, ist es vollkommen in Ordnung, eine einzelne Spalte zu haben.

In diesem Sinne relational algebrawäre dies eine unäre Beziehung, was bedeutet, dass " dieses Ding existiert ".

Ja, es ist in Ordnung, eine Tabelle zu haben, die eine solche Beziehung definiert: zum Beispiel, um eine Domäne zu definieren.

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

Eine Nachschlagetabelle von prime numbersist das, was mir zuerst einfällt.

Ich habe sie in der Vergangenheit benutzt. Ein Kunde von mir wollte jeden automatisch blockieren, der versucht, sich mit einer Telefonnummer in dieser großen Liste anzumelden, also war es nur eine große schwarze Liste.

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 sollen, und Sie möchten sie dynamisch ändern können, müssen sie jedoch nicht mit einer anderen Tabelle verknüpfen.

Ein Fall, den ich manchmal gefunden habe, ist ungefähr so:

Die Tabelle country_id enthält nur eine Spalte mit der numerischen ID für jedes Land.

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

Die Tabelle company_factories enthält Informationen zu jeder Fabrik des Unternehmens, einschließlich des Landes, in dem sich das Unternehmen befindet.

Um die Datenkohärenz und sprachunabhängige Daten in den Tabellen aufrechtzuerhalten, verwendet die Datenbank dieses Schema mit Tabellen mit nur einer Spalte, um Fremdschlüssel ohne Sprachabhängigkeiten zuzulassen.

In diesem Fall halte ich die Existenz einer Spaltentabelle für gerechtfertigt.

Herausgegeben in Reaktion auf den Kommentar von: Quassnoi

_{(Quelle: ggpht.com )}

In diesem Schema kann ich einen Fremdschlüssel in der Tabelle company_factories definieren, für den ich keine Spalte Sprache in die Tabelle aufnehmen muss. Wenn ich jedoch nicht die Tabelle country_id habe, muss ich die Spalte Sprache in die Tabelle aufnehmen, um den Fremdschlüssel zu definieren .

Es gibt seltene Fälle, in denen eine einspaltige Tabelle sinnvoll ist. 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 je nach Sprache variieren würden.

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

Ich verwende ständig einspaltige Tabellen - natürlich abhängig davon, ob das App-Design bereits eine Datenbank verwendet. Nachdem ich den Entwurfsaufwand für das Herstellen einer Datenbankverbindung überstanden habe, füge ich nach Möglichkeit alle veränderlichen Daten in Tabellen ein.

Ich kann mir zwei Verwendungen von einspaltigen Tabellen OTMH vorstellen:

1) Datenelement vorhanden. Wird häufig in Dropdown-Listen verwendet. Wird auch für einfache Legitimitätstests verwendet.

Z.B. Abkürzungen für US-Bundesstaaten mit zwei Buchstaben; Postleitzahlen, an die wir versenden; Wörter legal in Scrabble; etc.

2) Sparse-Binärattribut, dh in einer großen Tabelle ein Binärattribut, das nur für sehr wenige Datensätze gilt. Anstatt eine neue boolesche Spalte hinzuzufügen, könnte ich eine separate Tabelle erstellen, die die Schlüssel der Datensätze enthält, für die das Attribut wahr ist.

Z.B. Mitarbeiter mit einer unheilbaren Krankheit; Banken mit einem 360-Tage-Jahr (die meisten nutzen 365); etc.

-Al.

Kein Problem, solange es eindeutige Werte enthält.

Meistens habe ich dies in Nachschlagetabellen wie der von Ihnen beschriebenen Statustabelle gesehen. Wenn Sie dies jedoch tun, müssen 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 einzige Spalte verwenden.

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

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

Ich habe in der Vergangenheit Zahlentabellen gesehen , die effektiv verwendet wurden.

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 Zusammenstellungstabelle (dh Vorname + Nachname + Geburtsdatum), obwohl ich mir immer noch nicht sicher bin, warum Sie das tun möchten.

EDIT: Ich konnte sehen, wie diese Art von Tabelle für eine einfache Liste verwendet wurde. Verwenden Sie es dafür?

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

Der einzige Anwendungsfall, den ich mir vorstellen kann, ist eine Worttabelle, 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, bei denen word = ?. Es gibt jedoch weitaus bessere Datenstrukturen für das Halten einer Liste von Wörtern als a relationale Datenbank.

Andernfalls werden Daten in einer Datenbank normalerweise in einer Datenbank abgelegt, 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?

Obwohl dies nicht illegal ist, sollten Sie im Allgemeinen wahrscheinlich keine Tabelle mit nur einer Spalte haben.

Alle meine Tabellen haben mindestens vier Technologiefelder, einen seriellen Primärschlüssel, Zeitstempel für die Erstellung und Änderung sowie einen Booleschen Wert für das weiche Löschen. In jeder schwarzen Liste möchten Sie auch wissen, wer den Eintrag hinzugefügt hat. Für mich lautet die Antwort "Nein". Eine Tabelle mit nur einer Spalte wäre nur dann sinnvoll, wenn ein Prototyp erstellt wird.

Ja das ist vollkommen in Ordnung. aber ein ID-Feld konnte es nicht verletzen, oder?