Redesign der Datenbank

[webald]

Tag zusammen,

ich bin gerade dabei das ein oder andere Tool zum Datenaustasuch mit anderen Programmen zu schreiben. Dabei stoße ich auf immer mehr Ungereimtheiten und uneinheitliches Design in der Datenbank. Einige Beispiele:

Tabelle orders:
country_iso_code_2 existiert für die Rechnungsadresse (billing_xxx) und für die Lieferadresse (delivery_xxx), nicht für den Kunden (customers_xxx)

In der Tabelle address_book fehlt der ISO-code ganz.
Feld language enthält das Verzeichnis für die Sprachdateien, statt languages_id und/oder ISO-Code.

Tabelle Coupons:
Feld coupon_active ist ein Textfeld für die Werte "Y" und "N" statt wie in der restlichen DB tinyint mit "0" oder "1"

In vielen Fällen fehlt die Möglichkeit Externe Nummern einzutragen (z. B. Rechnungsnummern aus der Wawi)

Wie sehen das andere? Soll man das ändern (mit allen Vor- und Nachteilen, da z. B. Module geändert werden müssten)?


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

[Matt]

Sollte man in der v1 nicht mehr korrigieren. Die meisten Fehler sind nebensächlich, lassen sich beispielsweise über Joins lösen.

Außerdem steht es dir frei, für deine Wawi beliebige weitere Felder einzufügen.

[webald]

Hi Matt,

ich bin kein Freund von Änderung an bestehenden Tabellen. Das macht Update so unübersichtlch und erfordert mehr Handarbeit. Ich packe zusätzlich notwendige Felder immer lieber in separate Tabellen und verlinke über die ID. Das ändert aber nix an den uneinhitlichn Datenfeldern.

Ich habe mir auch mal Gedanken gemacht, wie man ein standardisiertes System schaffen kann und trotzdem jede Flexibiltät für praktisch jedes Szenario erhalten kann. Als Beispiel mal eine Tabelle zu den Zahlarten.

Über das Feld payment_module kann man bei Bedarf eine besonder Logik für eine Zahlart einbinden und ggf. aktivieren. Notwendig ist eine zweite Tabelle für die Übersetzungen. Auch hier könnte man einheitlich verfahren indem man eine Tabelle mdf_translations erstellt und hierin alle Übesetzungen für alle Tabellen speichert (Primärschlüssel Tabellenname/lfd.ID, z. B. mdf_payment_types/2: invoice)

Code: SQL  [Auswählen]

CREATE TABLE mdf_payment_types (
  payment_id INT(11) NOT NULL AUTO_INCREMENT,
  payment_code VARCHAR(50) COLLATE latin1_german1_ci NOT NULL,
  discount_percent DECIMAL(10,0) NOT NULL DEFAULT '0',
  discount_days INT(11) NOT NULL DEFAULT '0',
  payment_module VARCHAR(100) COLLATE latin1_german1_ci NOT NULL,
  payment_modul_active tinyint(1) NOT NULL DEFAULT '0',
  payment_active tinyint(1) NOT NULL DEFAULT '0',
  external_payment_method VARCHAR(30) COLLATE latin1_german1_ci NOT NULL,
  external_payment_terms VARCHAR(30) COLLATE latin1_german1_ci NOT NULL,
  parent_payment_id INT(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (payment_id)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci;

INSERT INTO mdf_payment_types (payment_id, payment_code, discount_percent, discount_days, payment_module, payment_modul_active, payment_active, external_payment_method, external_payment_terms, parent_payment_id) VALUES(1, 'Vorkasse', 2, 0, '', 0, 1, 'Überweisung', 'Vorkasse', 0);
INSERT INTO mdf_payment_types (payment_id, payment_code, discount_percent, discount_days, payment_module, payment_modul_active, payment_active, external_payment_method, external_payment_terms, parent_payment_id) VALUES(2, 'Rechnung', 2, 10, '', 0, 1, 'Überweisung', 'Rechnung 10Tage 2%', 0);
INSERT INTO mdf_payment_types (payment_id, payment_code, discount_percent, discount_days, payment_module, payment_modul_active, payment_active, external_payment_method, external_payment_terms, parent_payment_id) VALUES(3, 'Paypal', 0, 0, 'paypal.php', 1, 1, 'Paypal', 'Paypal', 0);
INSERT INTO mdf_payment_types (payment_id, payment_code, discount_percent, discount_days, payment_module, payment_modul_active, payment_active, external_payment_method, external_payment_terms, parent_payment_id) VALUES(4, 'Bar bei Abholung', 0, 0, '', 0, 1, 'Barzahlung', 'sofort', 0);

[web28]

Hallo webald,

in der Tat fehlen in einigen DB Tabellen wichtige Spalten. In der neuen Version haben wir bereits einige Spalten hinzugefügt, z. B. customers_country_iso_code_2 in der Tabelle orders

language_id in der Tabelle orders wäre auch nicht verkehrt.

address_book wird auch mit entry_country_iso_code_2 ergänzt werden.

Weitere Verbesserungsvorschläge sind immer willkommen.

Gruss web28

[Matt]

Zumindest im alten xt:Commerce ist language_id nicht einheitlich, mal heißt es languages_id (was korrekt wäre, da normalerweise alles im Plural ist), manchmal language_id.

Das Argument mit den Updates lass ich nicht gelten. Updates sind ab dem Zeitpunkt schwierig ab dem du irgendwas am Shop änderst. Da kommt es auf eine Tabellenspalte mehr oder weniger auch nicht an.

Außerdem bin ich ja ein Freund von dedizierten Übersetzungstabellen. Kann man ja z.B. mit i18n prefixen um sie von den Haupttabellen zu unterscheiden.

Mir ist allerdings unklar wie du eine Logik in payment_module bei 100 Zeichen, die du zur Verfügung hast, einbindest. Bei 'payment_modul_active' fehlt BTW ein e.

Allgemein: Ich würde ja nix mehr in latin1 machen und auch nix mehr ohne InnoDB.

[webald]

Hi Matt,

das ist nur eine Skizze. Welche Db-Engine Du verwendest sollte egal sein. Ich würde ja für neues auch auf PDO setzen, so dass sogar auch mal eine DB2 als Datenbank herhalten könnte.

...Mir ist allerdings unklar wie du eine Logik in payment_module bei 100 Zeichen, die du zur Verfügung hast, einbindest...

Ich pack da ja nicht den Code rein, sondern nur den Dateinamen des Zahlungsmoduls.

Ähnlich könnte man auch in anderen Tabellen spezifische Funktion hinzufügen. Beispiel Tabelle products: hir könnte man beibestimmten Artikeln ein Modul hinterlegenund aktivieren, wie z.b. eine Flächenberechnung.