Beste Möglichkeit, einen Singleton in einer relationalen Datenbank zu modellieren

Beim Entwerfen eines relationalen Datenbankschemas für Webanwendungen stelle ich häufig fest, dass ich eine Tabelle erstelle, die nur eine Zeile und nur eine Zeile enthält. Es scheint, dass dies der falsche Weg ist, um es zu entwerfen, aber ich kann mir nichts Besseres einfallen lassen, oder das ist offensichtlich "der richtige Weg, es zu tun".

Ein aktuelles Beispiel ist eine Website, mit der die Benutzer den Inhalt der Homepage manuell steuern können. Nun, es gibt nur eine Homepage. Ich habe eine Tabelle erstellt, die alle erforderlichen Felder zum Erstellen der Homepage enthält, z. B. ein Textfeld für einen Bereich, der beschreibenden Text enthält. Ein Feld zum Speichern des Namens einer großen Bilddatei. Einige Fremdschlüssel, die auf Artikel verweisen, die auf der Homepage angezeigt werden usw. Es funktioniert, aber es fühlt sich falsch an, eine Tabelle mit nur einer Zeile zu haben.

In der Vergangenheit habe ich viele andere Designs ausprobiert, z. B. das Zulassen mehrerer Zeilen in der Homepage-Tabelle und das zufällige Auswählen einer Zeile. Ich habe versucht, ein boolesches Feld mit dem Namen "active" hinzuzufügen und eine der aktiven Homepages nach dem Zufallsprinzip auszuwählen. Ich habe versucht, nur eine Zeile zu erzwingen, die zu einem bestimmten Zeitpunkt in der Anwendungslogik aktiv ist. Ich habe versucht, nicht einmal eine Homepage-Tabelle zu erstellen und alle anderen Elemente, z. B. Artikel, mit booleschen Feldern mit Namen wie featured_on_homepage zu versehen.

In den meisten Fällen konnte ich die Homepage mit einer Reihe von Konstanten in einer Einstellungsdatei erstellen. Das Hauptproblem mit der Einstellungsdatei besteht darin, dass sie unter der Kontrolle des Entwicklers steht. Da so etwas wie der Inhalt der Homepage vom Benutzer bearbeitet werden muss, muss er in der Datenbank gespeichert werden.

Auf vielen Websites habe ich dieses Problem nicht, weil ich Dinge wie die Homepage mit einer Abfrage wie der Auswahl der fünf neuesten Artikel erstellen kann. Wenn ich jedoch Seiten habe, die manuell mit strengen Anforderungen erstellt wurden, wird es schwierig, sie in der Datenbank zu modellieren. Aber stellen Sie sich vor, Sie haben eine Fototabelle und eine Artikeltabelle. Voraussetzung ist, dass auf der Homepage genau fünf Fotos, genau drei Artikel und zwei vom Benutzer manuell gesteuerte beliebige Textblöcke angezeigt werden. Wie modellieren Sie das in der Datenbank richtig?

Ich habe dieses Modellierungsproblem auch in vielen anderen Fällen außer auf Homepages. Es ist nur das einfachste und allgemeinste Beispiel, das mir einfallen könnte.

Ein einfacher Ansatz wäre, die Eigenschaften der Homepage in einer Eigenschaftentabelle zu speichern (oder anders zu nennen), die aus den Spalten Name und Wert besteht.

HomePageProperty1 - UserValue1

HomePageProperty2 - UserValue2

Es ist vielleicht keine ideale Lösung, aber es ist einfach und flexibel. Es beseitigt auch die Tabelle mit einem Zeilenszenario.

Mir ist nicht klar, dass Sie ein Problem haben, das Sie lösen müssen.

Eine einzeilige Tabelle ist in keiner Weise ein Problem für die Datenbank selbst und ermöglicht es Ihnen, Datentypen und Einschränkungen auf die Daten anzuwenden.

Ich bin mir nicht sicher, ob Sie versuchen, ein echtes Problem zu lösen, um ehrlich zu sein.

Mir scheint, dass Sie eine Datenbank für etwas verwenden, das eigentlich als Datei gespeichert werden sollte.

Ihre Beschreibung erinnert mich an viele Wiki-Seiten, auf denen Benutzer den Inhalt bearbeiten können. In Wikis oder zumindest in den Implementierungen, die ich gesehen habe, werden die Seiten als Dateien beibehalten.

Dies hilft Ihnen bei anderen Webdetails, z. B. dem Ermöglichen, dass Ihre Benutzer Ihre Homepage zwischenspeichern. Dies ist praktisch kostenlos, wenn Sie die Seiten als Dateien speichern, aber Sie müssten die Logik für die Cache-Ungültigkeit manuell implementieren, wenn Sie die erstellen Seite bei jeder Anfrage basierend auf Inhalten in der Datenbank gespeichert.

Auf jeden Fall möchte ich nur klarstellen, dass die meisten persistenten Daten einer Anwendung in einer Datenbank gespeichert sind. Dies bedeutet jedoch nicht, dass wir alles dort speichern müssen. Datenbanken sind nur eines der Werkzeuge unseres Handels. Wir müssen lernen, so viele verschiedene Werkzeuge wie möglich zu nutzen.

An einer Tabelle mit einer Zeile ist absolut nichts auszusetzen.

Wenn dies Teil Ihres Designs ist, sollten Sie es durchsetzen. Geben Sie der Tabelle eine Identitätsspalte, geben Sie ihr eine Eindeutigkeitsbedingung und fügen Sie dann eine Spaltenbedingung hinzu, um nur einen einzelnen Wert zuzulassen. Dies stellt sicher, dass niemand eine zweite Zeile hinzufügen kann, was katastrophal sein kann, wenn die SQL-Anweisungen, die die Tabelle lesen, (verständlicherweise) keine where-Klausel enthalten.

Wenn Sie eine große Anzahl von Spalten abrufen, könnten Sie versucht sein, die Tabelle einzugrenzen und stattdessen eine Zeile pro Konfigurationselement zu haben. Dies ist nicht die beste Idee, da Sie die Typensicherheit und Validierung verlieren. Außerdem würden Sie die Vorwärtskompatibilität mit der Mandantenfähigkeit verlieren , was für Sie wichtig sein könnte. Eine bessere Lösung wäre, die tatsächlichen Eigenschaften Ihrer Entitäten zu überdenken und separate einzeilige Tabellen für verschiedene Entitäten zu erstellen.

Ja, ich sage nicht nur, dass eine einzeilige Tabelle in Ordnung ist, sondern ich schlage auch vor, dass Sie mehr als eine davon wünschen.

Sie könnten eine Tabelle mit dem Namen STATIC_CONTENT erstellen und Spalten für einen Schlüssel sowie den Inhalt, aktive / inaktive Tracker usw. haben. Erstellen Sie dann eine Zeile mit dem Schlüssel "HomePage" und laden Sie auf Ihrer Homepage den statischen Inhalt für diesen Schlüssel und zeigen Sie es an. Auf diese Weise können Sie bei anderen statischen Inhalten (Informationen zu Seiten, Kontaktseiten usw.) dieser Tabelle Zeilen hinzufügen.

Es ist an sich nichts Falsches, eine Tabelle mit nur einer Zeile zu haben. Wenn Sie immer nur eine Instanz einer bestimmten Entität haben, ist dies möglicherweise die natürlichste Art, dies darzustellen.

Die zufällige Auswahl einer Zeile ist jedoch falsch und schlecht. Wenn Ihre Domänenlogik nur eine einzelne Zeile erwartet, liegt offensichtlich ein Fehler in den Daten vor, wenn tatsächlich mehr vorhanden sind. Sie sollten also herausfinden, wer oder was ungültige Daten in die Datenbank schreibt, und dies verhindern! Abhängig von der Datenbank können Sie der Tabelle möglicherweise eine Einschränkung hinzufügen, um dies zu verhindern, z. B. indem Sie nur einen bestimmten Wert als Primärschlüssel zulassen.

Nur um Walter hinzuzufügen ..

Die Eigenschaftstabellenstruktur sollte mehrere Datentypen zulassen.

Fileds:
PropertyName
PropertyTextValue
PropertyDateValue
PropertyNumericValue
PropertyBoolValue

Mir scheint, Sie hätten eine Ebene mehr abstrahieren können. Am Ende ist eine "Homepage" eine "Seite". Sie können verschiedene Arten von Seiten mit den von Ihnen benötigten Eigenschaften erstellen. Wenn Sie Abschnitte auf Ihrer Site haben, benötigen Sie wahrscheinlich eine "SectionHomePage", die genauso gut funktionieren kann wie eine "Homepage".

Voraussetzung ist, dass auf der Homepage genau fünf Fotos, genau drei Artikel und zwei vom Benutzer manuell gesteuerte beliebige Textblöcke angezeigt werden. Wie modellieren Sie das in der Datenbank richtig?

Lass es uns so versuchen. Ich füge eine ArticlePage-Tabelle hinzu, damit Sie sehen, wie Sie Eigenschaften entsprechend trennen können.

PAGES
Id
Title
Description

HOMEPAGES
PageId (FK)
PhotoListLimit
ArticleListLimit
TextBlockListLimit

ARTICLEPAGE
PageId (FK)
ArticleMainQuote
ArticleMainBody
ArticlePhoto1
ArticlePhoto2

Das würde gut für mich funktionieren, würde sogar gut für eine große Site funktionieren.