BETA MODUL: Universelle Artikelmerkmale

[webald]

Ich muss die Eigenschaften bei den Artikeln erweitern (zusätzliche Artikelmerkmale) und statt die Tabelle products zu erweitern würde ich eine neue anlegen. Das Szenario ist aber nun wie folgt:

Es gibt etwa 50(!) neue Artikelmerkmale. Von diesen werden aber nicht immer alle für jeden Artikel benötigt und verwendet. Also etwa Artikel A1 hat 5 Merkmale, Artikel B2 hat 10 andere Merkmale.

Daraus resultieren eine Menge leerer bzw. ungenutzter Felder in der Tabelle. Das ganz könnte man umgehen mit einer 3 spaltigen Tabelle (product_id, product_property, product_property_value). Hier wird dann nur eine Zeile angelegt, wenn auch eine entsprechendes Artikelmerkmal benötigt wird sowie de zugehörigen Wert. Nachteil ist aber das die Tabelle sehr schnell sehr lang wird. Bei obigem Beispiel 5 Zeilen für Artikel A1 und 10 Zeilen für Artikel B2.

Flexibler ist mit Sicherheit die 2. Lösung; weitere Merkmale können ohne Änderungen am Code hinzugefügt werden. Die Frage ist nur, was ist performanter?

Hat da jemand eine Meinung zu?

[EDIT Tomcraft 20.11.2014: Hier geht es direkt zum Modul von timo_paul.]

Linkback: https://www.modified-shop.org/forum/index.php?topic=31517.0

[Marcus Kreusch]

Hallo webald,

es kommt zwar darauf an, was du mit den Attributen am Ende vorhast und auch ein wenig, wie viele Produkte es im Shop gibt, aber ich würde dir stark zur 2. Lösung raten - eben wegen der von dir angesprochenen Flexibilität.
Eine Tabelle mit 50+ Spalten ist noch dazu wirklich schlechter Stil und kann sich schnell zu einem unbeherrschbaren Monster entwickeln, wenn dem Shopbetreiber demnächst einfällt, dass er noch weitere 50 Merkmale einführen möchte... und da wäre er nicht der erste...

Viele Grüße
Marcus

[hendrik]

wenn dem Shopbetreiber demnächst einfällt, dass er noch weitere 50 Merkmale einführen möchte... und da wäre er nicht der erste...

Allerdings. Kann ich bestätigen. Wenn ein Kunde etwas programmiert haben möchte überlege ich mir vorher schon [man hat ja Erfahrungen] womit er wohl als nächstes kommt und berücksichtige das schon im vorraus. Gerade bei Datenfeldern. Kommt mir sehr bekannt vor. Heute will er 3 Morgen noch 4 und übermorgen... Und jedesmal das ganze Projekt durchgehen nach den Änderungsstellen. Das schafft gute Laune.

gruß
hen

[timopaul]

Guten Tag,

vor einer ähnlichen Aufgabe stand ich auch schon. Da die Attribut-Werte alle frei definierbar sein sollten, also Textfelder, und sich auch noch in der Sprache unterschieden, gab es am Ende 4 weitere Tabellen dafür und ein kleines Modul. Veröffentlicht wurde es bisher noch nicht da noch viel Potential zum Ausbau vorhanden ist um die Administration zu erleichtern. Vielleicht ist es jetzt schon zu "gewaltig" für deine Anforderungen, habe es dir trotz dessen mal angehängt, vielleicht bringt es dir ja was und mir endlich mal das Projekt was ich noch brauche um das Modul zum Abschluss zu bringen.

Besten Gruß,
Timo

[EDIT Tomcraft 20.11.2014: Modul in Beitrag 1 verlinkt.]

[webald]

Das sind doch gute Ansätze. Meine ursprüngliche Idee sah in etwa aus wie Timo's Entwurf. Ich habe das ganze jetzt mal ein bischen verquirlt und rausgekommenist bis jetzt das:

Code: SQL  [Auswählen]

--
-- Tabellenstruktur für Tabelle `datatypes`
--

CREATE TABLE IF NOT EXISTS `datatypes` (
  `datatype` VARCHAR(10) NOT NULL,
  `datatype_validation` VARCHAR(100) NOT NULL,
  PRIMARY KEY (`datatype`)
);

-- --------------------------------------------------------

--
-- Tabellenstruktur für Tabelle `products_properties`
--

CREATE TABLE IF NOT EXISTS `products_properties` (
  `products_property_id` INT(11) NOT NULL AUTO_INCREMENT,
  `property_group_id` INT(11) NOT NULL DEFAULT '0',
  `multi_language` tinyint(4) NOT NULL DEFAULT '0',
  `products_property_name` VARCHAR(30) NOT NULL,
  `products_property_sort` INT(11) NOT NULL DEFAULT '0',
  `products_property_status` tinyint(4) NOT NULL DEFAULT '0',
  `products_property_datatype` VARCHAR(10) NOT NULL DEFAULT 'VARCHAR',
  `products_property_validate` tinyint(4) NOT NULL DEFAULT '0',
  PRIMARY KEY (`products_property_id`)
) AUTO_INCREMENT=1 ;

-- --------------------------------------------------------

--
-- Tabellenstruktur für Tabelle `products_properties_description`
--

CREATE TABLE IF NOT EXISTS `products_properties_description` (
  `product_property_id` INT(11) NOT NULL,
  `language_id` INT(11) NOT NULL,
  `product_property_heading` VARCHAR(30) NOT NULL,
  `product_property_description` VARCHAR(100) NOT NULL,
  UNIQUE KEY `product_property_id` (`product_property_id`,`language_id`)
) ;

-- --------------------------------------------------------

--
-- Tabellenstruktur für Tabelle `products_properties_group`
--

CREATE TABLE IF NOT EXISTS `products_properties_group` (
  `property_group_id` INT(11) NOT NULL AUTO_INCREMENT,
  `property_group_name` VARCHAR(30) NOT NULL,
  `property_group_status` tinyint(4) NOT NULL DEFAULT '0',
  `property_group_sort` tinyint(4) NOT NULL DEFAULT '0',
  PRIMARY KEY (`property_group_id`)
) AUTO_INCREMENT=1 ;

-- --------------------------------------------------------

--
-- Tabellenstruktur für Tabelle `products_properties_values`
--

CREATE TABLE IF NOT EXISTS `products_properties_values` (
  `products_id` INT(11) NOT NULL,
  `products_property_id` INT(11) NOT NULL,
  `products_property_value` VARCHAR(255) NOT NULL,
  UNIQUE KEY `products_id` (`products_id`,`products_property_id`)
) ;

-- --------------------------------------------------------

--
-- Tabellenstruktur für Tabelle `products_properties_values_ml`
--

CREATE TABLE IF NOT EXISTS `products_properties_values_ml` (
  `products_id` INT(11) NOT NULL,
  `products_property_id` INT(11) NOT NULL,
  `language_id` INT(11) NOT NULL,
  `products_property_value` VARCHAR(255) NOT NULL,
  UNIQUE KEY `products_id` (`products_id`,`products_property_id`,`language_id`)
) ;
 

Ich habe mal ein Bild angehängt, um zu zeigen in welcher Beziehung die Tabellen zueinander stehen.

[ Für Gäste sind keine Dateianhänge sichtbar ]

Die Tabelle datatypes soll es ermöglichen den variablen Feldern einen bestimmten Datentyp mit zugeben, so dass ggf. damit auch gerechnet werden könnte. Das Feld datatype-validation könnte einen Regex-Ausdruck enthalten.

Ein mögliche Gruppierung der Eigenschatfen macht bei 50 und mehr bestimmt auch Sinn.

Meinungen?

[Matt]

Ich hab das letzt für einen unserer Shops auch gemacht. Ich hab nur drei Tabellen, wünsche mir aber mittlerweile, auch die Werte normalisiert zu haben, weil da doch viel gleiches vorkommt und wenn man was ändert, weil einem die Formulierung nicht passt, muss man das dann an zig stellen machen.

products_properties_values_ml in deinem Ansatz verstehe ich nicht. Bzw. was der Unterschied zu products_properties_values sein soll.

[webald]

Hi Matt,

products_properties_values_ml in deinem Ansatz verstehe ich nicht. Bzw. was der Unterschied zu products_properties_values sein soll.

Es gibt Eigenschaften, wie z. B. die Farbe eines Pullovers. In so einem Fall macht mehrsprachigkeit (ml) Sinn. In anderen Fällen, etwa der Menge Eisen in Corn-Flakes, da macht mehrsprachigkeit keine Sinn. Im Gegenteil, muss doch für jede Sprache der gleiche Wert mehrfach eingegeben werden. Findest Du das nicht richtig?

[Matt]

Ja, das ist sicher richtig, ich hab's trotzdem bei einer Tabelle und dann eben doppelten Eingaben belassen. Der weg über noch ne Tabelle ist eher ein Performancehindernis. Jeder Join kostet Zeit.

[webald]

Der weg über noch ne Tabelle ist eher ein Performancehindernis. Jeder Join kostet Zeit.

Das wäre zu prüfen. Habe ich nur eine multilanguage-Tabelle, dann habe ich auch die x-fache Anzahl an Datensätzen in der Tabelle.

Bsp.:
Tabelle ml hat 1000 Zeilen bei 2 Sprachen.
50% der Eigenschaften sind aber nur Zahlen, womit 250 Zeilen unnötig doppelt sind.

Auf 2 Tabellen aufgeteilt hatte die Tablle ml 500 Zeilen und die Tabelle no_ml 250 Zeilen.

Ist also für alles in einer Tabelle

Code: SQL  [Auswählen]

(SELECT * FROM ml WHERE products_id='x' AND language_id='1')

schneller als für 2 Tabellen

Code: SQL  [Auswählen]

(SELECT * FROM ml WHERE products_id='x' AND language_id='1')
UNION
(SELECT * FROM no_ml WHERE products_id='x')

Je mehr Sprachen ein Shop unterstützt umso größer werden die unnützen Datenzeilen. Anderseits verschiebt sich der Vorteil zu einer Tabelle je mehr sprachabhängige Werte eingetragen werden.

Es bleibt aber noch der Grundsatz "Mißtraue allen Usereingaben" (und ob die auch alle Felder bearbeiten?)

[webald]

Noch was:

Warum nutzt modified in der DB keine foreign keys?

[Matt]

Foreign Keys gehen nur mit InnoDB, alle Tabellen in modified sind nach wie vor MyISAM.