Felder auslagern

cycap · 07.07.2010, 09:00

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 · 07.07.2010, 10:24

CouchDB

nikosch · 07.07.2010, 12:01

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).

phpsecretary · 07.07.2010, 12:18

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

Zitat:

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

Zitat:

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 · 07.07.2010, 12:24

Zitat:

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 · 07.07.2010, 13:32

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 · 07.07.2010, 14:10

Code:

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 · 07.07.2010, 14:13

@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

phpsecretary · 07.07.2010, 14:38

Zitat:

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.

Zitat:

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...

Zitat:

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.

Zitat:

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?

Zitat:

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 · 07.07.2010, 14:51

@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.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Felder eines Datensatzes separieren	aniga_de	Datenbanken	10	26.01.2010 21:29
MySQL - Felder mit verschiedenen Bedingungen summieren	Patrick Hilker	Datenbanken	2	27.10.2009 16:23
[Erledigt] Tabellenlayout: Große Felder auslagern?	boernard	Datenbanken	7	27.07.2009 14:03
Excel Spreadsheet Writer -> Import Outlook -> Felder definieren...	taurus	PHP Tipps 2008	0	16.12.2008 12:10
Gästebuch-Tabelle - Felder auf Inhalt prüfen	ProgStarter	PHP Tipps 2008	13	09.10.2008 20:07
Schwierige (?) Sortierung über 2 Felder	Anotherone	Datenbanken	8	31.12.2006 02:48
mysql mehrere felder aus 2 tabellen bei vorhandensein eines	cytrobic	Datenbanken	9	30.06.2006 13:27
suche tutorial: FORMULAR FELDER AUF INHALT PRÜFEN		PHP Tipps 2006	7	25.01.2006 19:14
[Erledigt] Große Felder wie TEXT auslagern?		Datenbanken	9	26.10.2005 20:22
Formularauswertung: Leere Felder anzeigen	maeck	PHP Tipps 2005-2	1	18.09.2005 21:42
Suche MySQL Funktion zum Verbinden 2er Felder	R4v3r	Datenbanken	2	12.07.2005 23:49
Felder löschen!?		PHP Tipps 2005	2	05.01.2005 14:36
Nach Formularcheck sind die Felder leer		PHP Tipps 2007	6	04.01.2005 21:42
leere felder entfernen		PHP Tipps 2007	14	04.01.2005 10:59
felder gegebenen falls überprüfen und sonst mail schicken.	lindner	PHP Tipps 2004-2	1	14.11.2004 15:47

07.07.2010, 09:00
cycap Moderator Registriert seit: 13.02.2008 Beiträge: 6.816 PHP-Kenntnisse: Fortgeschritten	Felder auslagern 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


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

07.07.2010, 10:24
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.069	CouchDB __________________ "Nuschel ich?" - "Was?"

07.07.2010, 12:01
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 34.241 PHP-Kenntnisse: Fortgeschritten	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). __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

07.07.2010, 13:32
cycap Moderator Registriert seit: 13.02.2008 Beiträge: 6.816 PHP-Kenntnisse: Fortgeschritten	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.

07.07.2010, 14:10
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.069	Code: 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). __________________ "Nuschel ich?" - "Was?"

07.07.2010, 14:13
cycap Moderator Registriert seit: 13.02.2008 Beiträge: 6.816 PHP-Kenntnisse: Fortgeschritten	@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

07.07.2010, 14:51
cycap Moderator Registriert seit: 13.02.2008 Beiträge: 6.816 PHP-Kenntnisse: Fortgeschritten	@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.