modified eCommerce Shopsoftware Datenbank Struktur

[dully007]

Hi Leute,
gibt es eigentlich irgendwo eine grafische Übersicht über die Datenbankstruktur, also welche Tabellen mit welchen Feldern es gibt, und wie die Tabellen zusammenhängen?

LG Andreas



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

[Tomcraft]

Hi Andreas,

schau mal hier: Datenbankreferenz

Grüße

Torsten

[dully007]

... Danke, so etwas habe ich gesucht.
Werde mir das Wiki gleichmal bookmarken

LG Andreas

[mahagma]

Link Update: Kategorie: Datenbankreferenz

[TrueSlide]

Ich weiß, dass Thema ist hier ne alte Leiche, aber es passt wohl am Besten zu meiner Frage.

Der Testshop wurde nun auf die neueste Version geupdatet. Dabei ist mir wieder aufgefallen, dass einige alte Tabellen noch immer vorhanden sind. Ich gehe davon aus, dass durch ein fehlerhaftes Update entstanden ist.
(in kann mich erinnern, dass es bei einem Update der Datenbankstruktur immer zu einem Abbruch gekommen ist)

So sind z.B. bei Konfiguration >> Adminbereich Optionen - Spalten, die wie folgt heißen:
MAX_ROW_LISTS_ATTR_OPTIONS
MAX_ROW_LISTS_ATTR_VALUES
MAX_DISPLAY_STATS_RESULTS

In anderen Bereichen kommt das auch mit vor.
Wenn über den Updater die Struktur von 2.0.7.2 auf 3.0.2 angehoben wird, bleiben benannte Einträge bestehen.
Die Frage ist nun, wie bekommt man am Besten die "alten" Einträge bzw. Tabellen (aus der Datenbank?) gelöscht, ohne den Shop komplett zu zerlegen?

[Q]

Geht das nur mir so? Ich habe etwas Probleme dir zu folgen. Du sprichst von Tabellen, Spalten und Datenbank und im nächsten Absatz von Spalten im Backend? Wirkt für mich etwas wie ein Würfelbecher.

[...]
So sind z.B. bei Konfiguration >> Adminbereich Optionen - Spalten, die wie folgt heißen:
MAX_ROW_LISTS_ATTR_OPTIONS
MAX_ROW_LISTS_ATTR_VALUES
MAX_DISPLAY_STATS_RESULTS
[...]

Vermutlich steht das bei dir im Backend in der Tabelle jeweils in einer ZEILE in der ERSTEN SPALTE?
Dann sind das einzelne Datensätze in der DB unter configuration. Ob denen jetzt nur ein Eintrag in der Sprachdatei fehlt oder obsolet sind, kann ich von unterwegs nicht beurteilen.

[Tomcraft]

Da ist was schief gelaufen bei einer früheren Aktualisierung der Datenbank!

Diese Einträge werden in der "update_2.0.5.1_to_2.0.6.0.sql" gelöscht!

Code: SQL  [Auswählen]

#Tomcraft - 2020-08-03 - DELETE obsolete configuration
DELETE FROM `configuration` WHERE `configuration_key` = 'MAX_ROW_LISTS_ATTR_VALUES';
DELETE FROM `configuration` WHERE `configuration_key` = 'MAX_ROW_LISTS_ATTR_OPTIONS';

#Tomcraft - 2020-08-03 - DELETE obsolete configuration
DELETE FROM `configuration` WHERE `configuration_key` = 'MAX_DISPLAY_STATS_RESULTS';

Grüße

Torsten

[TrueSlide]

Ok, ich versuche es nochmal etwas ausführlicher.

Es wurde vor einiger Zeit ein Update auf 2.0.7.2 durchgeführt. Dabei kam es zu Problemen, wenn man mittels _installer die Datenbank etc. auf den neusten Stand gebracht hat. Es brach immer mitten drin ab, bzw. es ging einfach nicht weiter.
Somit wurde der Punkt dann überprungen. Der Shop lief soweit.
In einigen Admin Bereichen tauchten dann aber folgende Einträge auf, wie im Bild zu sehen:
[ Für Gäste sind keine Dateianhänge sichtbar ]

Wenn nun ein Update auf 3.0.2 durchgeführt wird, läuft alles normal durch und das Update ist erfolgreich.
Nur eben jene Einträge, wie sie im Bild zu sehen sind, sind dann auch weiterhin vorhanden. Das soll so sicher nicht sein.

Ich ging also davon aus, dass diese Einträge (also z.B. MAX_ROW_LISTS_ATTR_OPTIONS) in der Datenbank zu finden sein müssen, was dann auch der Fall war.
Lösche ich diese händisch raus, so tauchen diese dann auch nicht mehr auf und alles ist "sauber" und läuft. Nun stellt sich die Frage, wie viele von diesen Fehlern gibt es und wie entfernt man diese.

Mein Ansatzpunkt war nun, die "Datenbank Version: "MOD_2.0.7.2" auf eine niedrigere zu setzen und den _installer nochmal drüber laufen zu lassen, damit dieser dann von der niedrigen Version Z.B. 2.0.1 auf 3.0.2 alle Tabellen etc, updatet und so die Einträge raus löscht.
In einem ersten Versuch scheint das geklappt zu haben, ob dies aber "OK" ist, dass weiß ich nicht, deswegen die Frage. 

[Tomcraft]

[...]
Lösche ich diese händisch raus, so tauchen diese dann auch nicht mehr auf und alles ist "sauber" und läuft. Nun stellt sich die Frage, wie viele von diesen Fehlern gibt es und wie entfernt man diese.
[...]

Ich würde an deiner Stelle alle DELETE-, UPDATE- & ALTER TABLE MODIFY (nicht ADD!)-Befehle aus den SQL-Dateien nochmal händisch über die Datenbank schicken.
Ob die INSERTS gelaufen sind kannst du nur selber anhand der Datenbank prüfen, da niemand weiss, an welcher Stelle bei welchem update es zu den Problemen kam.
Wie gesagt hätten die Einträge bereits beim Update auf 2.0.6.0 entfernt werden sollen.

Grüße

Torsten

[TrueSlide]

Heißt, der Gedanke, die Datenbankstruktur händisch auf eine niedriger zu ändern/schreiben (also dem System und dem _installer dies lediglich vorzutäuschen indem man nur die Zahl ändert) ist dann nicht die beste und einfachste Idee? 

[Tomcraft]

Nein, ist keine gute Idee, würde ich jetzt erstmal aus dem Bauch heraus sagen, da dann INSERT-Befehle ggf. mehrfach ausgeführt wurden.

Grüße

Torsten

[TrueSlide]

Hm Mist ... ok ...

Nur zum Verständnis und damit das dann richtig und sauber abläuft.
Ich nehme mir aus dem Update-Ordner die SQL Dateien und führe alle Befehle aus, wie zum Beispiel (aus update_2.0.7.2_to_3.0.0.sql):

Code: SQL  [Auswählen]

ALTER TABLE `zones_to_geo_zones` MODIFY `zone_id` INT(11) NOT NULL;

oder

Code: SQL  [Auswählen]

CREATE TABLE IF NOT EXISTS `products_images_description` (
  `image_id` INT(11) NOT NULL,
  `products_id` INT(11) NOT NULL,
  `image_title` VARCHAR(255) NOT NULL,
  `image_alt` VARCHAR(255) NOT NULL,
  `language_id` INT(11) NOT NULL,
  PRIMARY KEY (`image_id`, `language_id`),
  KEY idx_products_id (`products_id`)
);

Befehle die wie folgt lauten lasse ich komplett weg (z.B. den "#GTB - 2022-07-12 - extend manufacturers" Abschnitt aus 2.0.7.2_to_3.0.0.):

Code: SQL  [Auswählen]

#GTB - 2022-07-12 - extend manufacturers
ALTER TABLE `manufacturers` ADD `manufacturers_status` INT(1) NOT NULL AFTER `manufacturers_image`;
ALTER TABLE `manufacturers` ADD `sort_order` INT(3) DEFAULT 0 NOT NULL AFTER `manufacturers_status`;
ALTER TABLE `manufacturers` ADD `products_sorting` VARCHAR(64) NULL AFTER `sort_order`;
ALTER TABLE `manufacturers` ADD `products_sorting2` VARCHAR(64) NOT NULL AFTER `products_sorting`;
ALTER TABLE `manufacturers` ADD `listing_template` VARCHAR(64) NOT NULL DEFAULT '' AFTER `products_sorting2`;
ALTER TABLE `manufacturers` ADD `categories_template` VARCHAR(64) AFTER `listing_template`;
ALTER TABLE `manufacturers` ADD INDEX `idx_manufacturers_status` (`manufacturers_status`);
ALTER TABLE `manufacturers` ADD INDEX `idx_sort_order` (`sort_order`);

Aus dem selben "Block" führe ich aber:

Code: SQL  [Auswählen]

UPDATE `manufacturers` SET `manufacturers_status` = 1;

aus!?

[Tomcraft]

Ja, korrekt, wobei du die ALTER TABLE ADD eigentlich auch ausführen kannst. Die werden ja nicht ausgeführt, wenn der Wert bereits vorhanden ist.
Wichtig ist dann nur, dass du folgende Option aktivierst in phpMyAdmin, damit der SQL-Query bei einem Fehler nicht abgebrochen wird!

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

Nachtrag: Nochmal drüber nachgedacht... Ich meine, dass du alle ALTER TABLE ADD & MODIFY komplett weg lassen kannst, da die über das Datenbankstruktur-Update eh rein kommen.

Grüße

Torsten