Felder auslagern

[cycap]

Hallo zusammen,

ich stehe momentan vor einer konzeptionellen Frage.

Ein sehr verkleinertes Beispiel:

Die Kunden A,B und C haben eigentlich nichts miteinander zu tun, arbeiten aber mit der gleichen Bestellsoftware.

Die Bestellungen beinhalten grundsätzlich die gleichen Daten (z.B. Datum der Eingabe, Author, Bestellnr. ...).

Jetzt möchte Kunde A aber noch die Möglichkeit haben einen Lieferanten mit anzugeben (NUR Kunde A).

Kunde B hingegen möchte eine Referenznr. aus dem Tool des Lieferanten angeben, außerdem einen Ansprechpartner und eine Transportart.

Kunde C möchte das alles nicht, sondern nur zusätzlich eine Adresse wo die Bestellung hingeschickt werden soll.

Jetzt könnte man das ganze natürlich alles in die Tabelle "Bestellungen" packen und bei den Kunden die es nicht brauchen einfach leer lassen.

Handelt es sich jetzt aber um 20 Kunden mit jeweils unterschiedlichen Vorstellungen, so wird die Tabelle unnötig breit und löchrig. Die Hauptdaten der Bestellungen sollen aber beieinander bleiben, sodass der Administrator z.B. alle Bestellungen (unabhängig vom Kunden) eines bestimmten Datums nach User sortiert einsehen kann.

Ich habe zwei Ansätze um das ganze anders zu lösen:

Ansatz 1:
Es gibt eine Tabelle die die Daten enthält die jede Bestellung braucht und für jeden Kunden eine weitere Tabelle die die zusätzlichen kundenspezifischen Felder enthält.

Ansatz 2:
Es gibt die o.g. Tabelle mit den Kopfdaten einer jeden Bestellung hier auch und pro genutzen Datentyps eine weitere Tabelle mit einer Spalte zur Identifizierung und einer Spalte mit dem Inhalt.

Beide Ansätze haben Vor- und Nachteile, so muss beim Ansatz 1 z.B. für jeden Kunden die DB-Struktur geändert werden, bei Ansatz 2 nicht. Bei Ansatz 2 sind dafür die Querys wesentlich umständlicher.

Nun zur eigentlichen Frage:
Habt ihr für dieses Problem noch andere Ansätze? Gibt es hierfür einen Fachbegriff damit ich mich im Netz schlau machen kann? Wie könnte man einen Ansatz problemlos mit handelsüblichen ORMappern benutzen?

Gruß
Cy

[Chriz]

CouchDB

[nikosch]

Letzteres weiß ich nicht, ansonsten könnte man noch über eine Zusatztabelle nachdenken, in der man Zusatzfelder als JSON-Objekt ablegt. Ist dann natürlich außen vor im Datenbankprozess (Sortieren nach oder dergl).

[Gast]

Ansatz 3: Alles von allen Kunden in eine Tabelle packen.

Handelt es sich jetzt aber um 20 Kunden mit jeweils unterschiedlichen Vorstellungen, so wird die Tabelle unnötig breit und löchrig.

Daten müssen immer so angelegt sein, dass sie möglichst wenig Speicherplatz benötigen und u.A. deswegen wird Normalisierung gelehrt. Als diese Regeln gemacht wurden fragte man aber noch scherzhaft "Du was kommt eigentlich nach kilo bzw. mega? *kicher kicher*"

Nullwert – Wikipedia

Die Hauptdaten der Bestellungen sollen aber beieinander bleiben, sodass der Administrator z.B. alle Bestellungen (unabhängig vom Kunden) eines bestimmten Datums nach User sortiert einsehen kann.

Das ist zum Einen eine Definitionsfrage (was sind Hauptdaten) und zum Anderen kann der Administrator sich auch eine Liste ziehen, die genau die Felder beinhaltet, die er sehen möchte. Dies ist unabhängig davon welche Felder als Hauptdaten definiert sind.

[nikosch]

Ansatz 3: Alles von allen Kunden in eine Tabelle packen.

Das halte ich auch in modernen Zeiten für ein schlechte Lösung. Das bedeutet nämlich, dass man bei jedem Featurewunsch erneut die Tabelle anpacken muss. Alleine schon, eine prall gefüllte Tabelle eines Zielsystems anpassen zu müssen, ist immer ein echt doofes Gefühl. Erst recht, wenn man vielleicht die „neuen“ Felder noch mit irgendwelchen Vorgabewerten updaten muss o.ä.

[cycap]

Ich stimme da Nikosch zu, deswegen ja überhaupt dieser Thread. Ein ALTER TABLE, was die ganze Tabelle locked und bei großem Tabelleninhalt auch länger dauern kann, wäre bei einer Tabelle die alle Kunden nutzen äußerst unschön. Dann dürfte man nur noch Nachts neue Kunden anlegen bzw. Features hinzufügen. Außerdem kommen mir dabei Begriffe wie Fragmentierung in den Sinn, da MySQL (oder ist es nur eine der Engines?) ja Speicher für den ganzen Datensatz reserviert und darin auch pro Feld den Platz der evtl. später noch genutzt werden könnte.

Und bzgl. der Liste für den Administrator: Ich hatte mit Absicht "sortiert nach User" geschrieben, denn das wäre zum Beispiel bei einem Ansatz 4 der alle Daten in jeweils eine Tabelle pro Kunde packt nicht über die B Datenbank möglich, jedenfalls nicht ohne weiteres. Bei den Ansätzen 1 - 3 wäre es natürlich problemlos machbar.

Nikosch, deinen Ansatz mit dem JSON ist zwar denkbar, aber wenn Kunde B jetzt hauptsächlich über die Referenznummer des Lieferanten suchen möchte, dann bekomme ich ein Problem.

[Chriz]

ORDER (Bestellungen)
id | fk_customer | order_number | created

CUSTOMER (Kunden)
id | name

ORDER_GROUP (Kunden-spezifische Spaltengruppierung)
id | fk_customer | name

ORDER_COL (Spaltendeklaration)
id | fk_order_group | name | value_type

ORDER_VAL (Werte)
id | fk_order_col | value

Nachteil: Die Spalte ORDER_VAL.value müsste mit einem Feld des größten gemeinsamen Nenners der Werte definiert sein, was TEXT wäre. Danach zu sortieren würde sehr "teuer" werden (VIEW + CAST).

[cycap]

@Chriz: Das ist ja vom Prinzip her mein Ansatz 2, nur das ich soweit gehen würde und die Tabellen ORDER_VAL_INT, ORDER_VAL_CHAR usw, anlegen würde

[Gast]

Das halte ich auch in modernen Zeiten für ein schlechte Lösung.

Ich auch, aber die anderen halte ich für noch schlechter. Wenn jemand eine gute Lösung hat, ich hätte auch Interesse.

Das bedeutet nämlich, dass man bei jedem Featurewunsch erneut die Tabelle anpacken muss.

Das haben Featurewünsche aber oft an sich, dass man Datenbanken bzw. deren Tabellen und Felder anpacken muss...

Alleine schon, eine prall gefüllte Tabelle eines Zielsystems anpassen zu müssen, ist immer ein echt doofes Gefühl. Erst recht, wenn man vielleicht die „neuen“ Felder noch mit irgendwelchen Vorgabewerten updaten muss o.ä.

Lassen wir doch mal die Gefühle aus dem Spiel... Wenn für Featurewünsche, die für einen speziellen Kunden neu hinzukommen, ein defaultwert, der beim Alter Table angegeben werden kann, nicht ausreicht, dann würde ich evtl. noch mal über das neue Feld nachdenken.

Ein ALTER TABLE, was die ganze Tabelle locked und bei großem Tabelleninhalt auch länger dauern kann, wäre bei einer Tabelle die alle Kunden nutzen äußerst unschön. Dann dürfte man nur noch Nachts neue Kunden anlegen bzw. Features hinzufügen.

Definiere doch mal bitte "große Tabelle" im Zusammenhang mit 20 Kunden. Und was ist gemeint mit "länger dauern" im Zusammenhang mit einem "Alter Table"?
Was stört dich eigentlich jetzt? Dein monatliches Alter Table? Kriegen die Kunden das überhaupt mit? Entwickelst du auf dem Livesystem? Schonmal über ein CVS nachgedacht?

Außerdem kommen mir dabei Begriffe wie Fragmentierung in den Sinn, da MySQL (oder ist es nur eine der Engines?) ja Speicher für den ganzen Datensatz reserviert und darin auch pro Feld den Platz der evtl. später noch genutzt werden könnte

MySQL :: MySQL 5.1 Referenzhandbuch :: 14.2.14.3 Eine Tabelle defragmentieren

Welche Begriffe außer der Fragmentierung kommen Dir denn noch so in den Sinn?

Außer der zentralen ein-Tabellen-Lösung käme mir noch folgender Overkill in den Sinn:

1. Jede Bestellsoftware (offensichtlich erhält ja nicht jeder Kunde die gleiche) erhält eine eigene Datenbank
2. Über einen Webservice pro Bestellsoftware kann der Administrator seine zentrale Statistik ziehen.

Hätte den Vorteil, dass nur dann ein Kunde an einem Update leidet, wenn dieses auch Einfluss auf seine Bestellsoftware hat. Und der Webservice muss nur dann angepasst werden, wenn ein generelles Update eingeflossen ist.

[cycap]

@phpsecretary: du beziehst dich zu sehr auf das Beispiel, ich mache keine Bestellsoftware, es geht um was völlig anderes, es geht hierbei rein ums konzeptionelle.

[nikosch]

Das haben Featurewünsche aber oft an sich, dass man Datenbanken bzw. deren Tabellen und Felder anpacken muss...

Eben nicht. Daten ja, Struktur nein.

[Gast]

Ich kann mich nur auf das beziehen, wonach du fragst.
Wenn Dein Beispiel zu weit hergeholt ist, wozu dann das Beispiel?

In jedem Fall ist ein Ansatz mit "ORDER_VAL_INT, ORDER_VAL_CHAR,..." etwas für eine Tonne.

God object – Wikipedia

[Gast]

Eben nicht. Daten ja, Struktur nein.

Ganz sicher sogar...

[cycap]

Ich kann mich nur auf das beziehen, wonach du fragst.
Wenn Dein Beispiel zu weit hergeholt ist, wozu dann das Beispiel?

Es hat schon einen Grund warum ich diesen Thread in einen Bereich des Forums gepackt habe der die Beschriftung

PHP Lösungen auf konzeptioneller Ebene

hat. Es geht ums Konzept und das Beispiel war nur dazu gedacht um verständlich zu machen worum es geht.

Ob es nun 20 oder 20.000 Kunden sind spielt doch beim Konzept keine Rolle. Und ebenso ist es für das Konzept unwichtig ob es um Bestellungen oder zum Beispiel um Foren-Beiträge geht.

Mal abgesehen davon wiedersprichtst du dir mit dem Link zum God-Object selbst, denn meinem ORM-Objekt "Bestellung" von Kunde A braucht nicht zu interessieren das es bei Kunde C noch eine Beziehung zu einer Lieferadresse gibt. Rein theoretisch natürlich.

[cycap]

Können wir das Thema noch weiter diskutieren? Gibt es vielleicht noch weitere Ansätze oder hat noch jemand anderes eine Meinung dazu?