Neuigkeiten
  • Die modified eCommerce Shopsoftware ist kostenlos, aber nicht umsonst.
    Spenden
  • Damit wir die modified eCommerce Shopsoftware auch zukünftig kostenlos anbieten können:
    Spenden
  • Thema: modified eCommerce Shopsoftware Datenbank Struktur (xtcommerce.sql) optimiert

    speedy

    • Viel Schreiber
    • Beiträge: 3.214
    Guten Morgen,

    ich hatte gerade das Vergnügen die Datenbank einer vorhandenen Trunk-Installation manuell auf Version 1.03 anpassen zu müssen.

    Dazu exportierte ich mit phpMyAdmin die Struktur mit den richtigen Parametern und habe es dann mit der Datei xtcommerce.sql aus Version 1.03 per Beyond Compare abgeglichen.

    Aufgefallen ist mir da leider so eines:
    - Nichts war alpabetisch (schon mal blöd ums vergleichen zu können, der Export ist nämlich sortiert)
    - Die SQL-Befehle waren generell total unterschiedlich
    - Leerzeichen nach belieben auch innerhalb der Klammern.
    - Groß- und Kleinschreibung auch einmal so, einmal so (schlecht u.a. fürs Syntax-Highlighting).
    - manchmal war sogar die Reihenfolge im SQL-Befehl anders, als es die Struktur vorsieht.
    - auch CHARSET=latin1 und COLLATE war nicht konsequent gleich
    - Nix wirklich normgemäß, standardisiert laut MySQL Konvention / Schreibweisen

    Scheinbar ist MySQL aber da sehr tollerant, ansonsten wunderte mich ehrlich gesagt, warum die Original xtcommerce.sql überhaupt funktionierte. Vieles davon ist sicher noch aus dem Urgestein.

    Ich habe es deshalb angepasst, sehr sorgfältig und auch getestet.
    So wie es ist jetzt ist, gehört die Syntax / Semantik wie auch immer eigentlich. Wer weiß es besser als phpMyAdmin  :-)

    Guckt es Euch bitte einmal an. Es wäre wirklich sehr gut, das zu übernehmen, dann wäre das auch mal sauber. Außerdem kann man dadurch wenigstens auch mal manuell nen Export mit phpMyAdmin machen und mit der Original-Struktur vergleichen und damit Probleme lösen.
    Bislang aus genannten Gründen unmöglich gewesen, da einem ein Dateivergleicher fast alles als unterschiedlich anschlägt.



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

    Tomcraft

    • modified Team
    • Gravatar
    • Beiträge: 46.369
    • Geschlecht:
    Hi speedy, danke, wir schauen uns das mal an!

    Grüße

    Torsten

    vr

    • modified Team
    • Beiträge: 2.664
    Hallo speedy,

    finde ich eine sehr gute Idee, :pro:

    Zitat
    Dazu exportierte ich mit phpMyAdmin die Struktur mit den richtigen Parametern

    mit welchen Parametern hast Du exportiert?

    Grüße, Volker

    speedy

    • Viel Schreiber
    • Beiträge: 3.214
    Hallo Volker,

    ich habe mal eben nen Screenshot gemacht mit den Parametern aus phpMyAdmin ;)

    Gruß

    speedy

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

    Tomcraft

    • modified Team
    • Gravatar
    • Beiträge: 46.369
    • Geschlecht:
    Dabei gehen aber unsere Kommentare zu den gemachten Änderungen verloren. :cry:

    Noch erkennt man mit WinMerge die Unterschiede im Vergleich zur originalen xtcommerce.sql von xt:Commerce 3.04 SP2.1, das ist bei der "optimierten" Version kaum noch möglich.

    An welcher Stelle kann man denn hier von einer Optimierung reden? Was gewinnen wir dazu?

    Nachtrag: Beim Export per phpMyAdmin ist auch nicht berücksichtigt, dass der xtc_installer selber auch Tabellen anlegen will, die Kundengruppen-Preis-Tabellen, wenn ich mich nicht irre? :?

    Grüße

    Torsten

    billybob

    • Fördermitglied
    • Beiträge: 563
    Hallo speedy,
    warum so'n Aufwand beim Vergleich?
    einfach eine xtc-Datenbank (nur Struktur, allen anferen Optionen ausgeschaltet) mit pdpadmin exportieren. Eine neue mit xtcommerce.sql einrichten und ebenfalls mit den gleichen Parametern wie die xtc-Datenbank exportieren. Schon sind alle Tabellen in der gleichen Reihenfolge und der Vergleich fällt wesentlich leichter.
    Und wo wir gerade bei der Syntax sind: Ein INT (wie auch andere Zahlen) wird nicht in ' ' geschrieben. Das führt nur zu unliebsamen Fehlern.
    Setz mal statt einer Zahl ein X dort ein. Ergebnis: nicht etwa ein Fehler sondern 0.

    @Tomcraft
    Wozu braucht man denn die ganzen Kommentare? Die Entwickler brauchen Sie, aber ansonsten niemand. Und die Änderungen werden ja wohl hoffentlich im SVN dokumentiert, oder?
    Diese Kommentare machen den Code nur unübersichtlich.

    Ich würde den Beitrag von Speedy eher als Anregung für diejenigen sehen, die so einen Vergleich machen müssen/wollen.
    Und so finde ich den Ansatz sehr gut. Macht doch daraus eine allgemeine Beschreibung, für Die die's interessiert.

    Gruß
    Rolf

    speedy

    • Viel Schreiber
    • Beiträge: 3.214
    @Torsten,
    die Kommentare kann man ja trotzdem einfügen, wenns denn sein muss, aber eigentlich braucht die niemand. Die Datei ist auch zu groß, dass die jemand der Kommentare wegen lesen würde.
    Ein Dateivergleich schlägt es halt dann als Unterschied an, der Rest passt dann zumindest. Momentan ist es ja ein reinstes durcheinander :)

    Aber ums Vergleichen gehts primär gar ned, dass war für mich der Anlass warum ich es machte. Eigentlich jetzt zu Eurem Vorteil, weil das dabei rauskam, da phyMyAdmin einfach das Ganze nach klaren Vorgaben erstellt und alles dann 1a nach Norm ist.
    Momentan ist das keine klare Linie.
    Die Systeme werden generell eigentlich immer penibler. Sich nicht an die Norm zu halten, kann also auch mal zum Problem werden. Also man sollte sich bei allem einfach an die Konventionen halten. Wie gesagt, Syntax Highlighting geht dann auch, wie es für SQL sein soll.
    Bei Java kann ich z.B. auch nicht Groß- und Kleinschreibung verwenden wie ich gerade lustig bin :)

    Ob der Installer oder später dann der Shop Tabellen oder Daten importiert ist aber für einen sauberen Aufbau der Datei eigentlich nicht wichtig. Wichtig ist, sich an die Konvention bei den Befehlen zu halten.

    @billybob
    Danke für den Tipp, ist natürlich auch eine Möglichkeit, wenns nur um den Vergleich geht.

    billybob

    • Fördermitglied
    • Beiträge: 563
    @Torsten,
    Aber ums Vergleichen gehts primär gar ned, dass war für mich der Anlass warum ich es machte. Eigentlich jetzt zu Eurem Vorteil, weil das dabei rauskam, da phyMyAdmin einfach das Ganze nach klaren Vorgaben erstellt und alles dann 1a nach Norm ist.
    Momentan ist das keine klare Linie.

    Naja, ich glaube Du sitzt da einem kleinen Irrtum auf. Das was phpMyAdmin macht mag vielleicht eine Norm sein, die Frage ist: Welche.
    Die von MySQL ist es nicht, denn SQL lässt eigentlich nicht zu, dass man Zahlen in Hochkommata (also als Text) schreibt. MySQL ist da ziemlich tolerant, was ich aber bei einer Datenbank überhaupt nicht begrüßen kann. Die hat auf Richtigkeit und Konsistenz der Daten zu achten.
    Versuche mal ein insert mit einem Textwert in eine int-Spalte. Funktioniert bei MySQL Problemlos ohne Meldung. Nur das hinterher ein falscher Wert in der Tabelle steht. Oracle bspw heut Dir dies mit einer prima Fehlermeldung um die Ohren.
    Gruß
    Rolf

    speedy

    • Viel Schreiber
    • Beiträge: 3.214
    Hallo billybob,

    nicht so schnell urteilen.
    phpMyAdmin schreibt absolut sauberes SQL. Es wäre ansonsten auch nicht das Referenz-Tool schlechthin.

    An ein paar Stellen wurde nachgearbeitet, weil modified eCommerce Shopsoftware "Extra-Wurst" drin war.
    Ich wollte es nicht komplett umschreiben und habe ein paar abweichende Stellen so drin gelassen wie es das Team wollte, nur die Schreibweise korrigiert. phpMyAdmin hätte diese Stellen natürlich anders geschrieben.
    Stimme dir aber zu, solche Sachen dann auch noch zu korrigieren.
    Auch um Index könnte man sich dann gleich mal kümmern, Zeit wird es.
    Es beweist ja nur, dass hier klar was zu tun ist und 98% habe ich damit ja schon gemacht. Den Rest erledigen wir zusammen und schon muss sich keiner mehr verstecken. ;)

    Ich habe mir die Befehle ja nicht ausgedacht, die sind so falsch von irgend nem Team, wahrscheinlich xt:Commerce so ausgedacht worden. Ich kann hier ja nicht alles prinzipiell ändern. Habe jetzt erstmal nur das Grobe gemacht, das war genug Arbeit. Programmierfehler müssen andere korrigieren.
    Kann ja hier auch keine Kür abliefern, wenns dann evtl. nur eingestampft wird und die Arbeit umsonst war, weil sich keiner traut das Thema anzugehen. Teilte halt meine "Lösung", bevor ichs einfach wieder lösche.

    Kannst du aber trotzdem bitte noch ein konkretes Beispiel hochladen / posten, damit sich jeder ein Bild machen kann, welche Stellen du meinst und wie die deiner Meinung nach exakt aussehen müssten.

    billybob

    • Fördermitglied
    • Beiträge: 563
    Hallo billybob,

    nicht so schnell urteilen.
    phpMyAdmin schreibt absolut sauberes SQL. Es wäre ansonsten auch nicht das Referenz-Tool schlechthin.

    Kannst du aber trotzdem bitte noch ein konkretes Beispiel hochladen / posten, damit sich jeder ein Bild machen kann, welche Stellen du meinst und wie die deiner Meinung nach exakt aussehen müssten.

    Hallo speedy.
    Tue ich nicht. Ich arbeite seit ca. 15 Jahren mit Oracle, MySQL und ich gebe Dir recht, dass phpMaAdmin ein tolle tool ist, aber eben auf MySQl zugeschnitten. Den Code, den es produziert ist nicht immer SQL92 oder SQL2003
    Vielleicht ist es inzwischen besser geworden, seit ca. 3 Jahren bin ich nicht mehr so im Thema.

    Trotzdem darf soetwas eigentlich nicht passieren, womit ich zum Beispiel komme:
    CREATE TABLE cm_file_flags (
      file_flag int(11) NOT NULL,
      file_flag_name varchar(32) NOT NULL,
    ...
    Wie wir sehen ist die Spalte file_flag ein INT. Trotzdem wird weiter unten

    INSERT INTO cm_file_flags (file_flag, file_flag_name) VALUES ('1', 'content');
    Ein Text '1' eingefügt. Das ist nicht sauber und kann auch zu Fehlern führen, wenn man beim Editieren z. B Statt '3' '§' schreibt.
    Dann steht nämlich eine 0 in der Spalte statt der 3.

    Ich hoffe ich bin verstenden worden. Meine Kritik war keine Kritik an Deiner Arbeit.
    Gruß
    Rolf

    speedy

    • Viel Schreiber
    • Beiträge: 3.214
    Hallo Rolf,

    jo, hatte es schon etwas als Kritik meiner Arbeit aufgefasst.
    Dachte du bemängelst konkrete Stellen bei meiner Optimierung, die ich jedoch nur übernommmen hatte, weil ich das nicht eigenmächtig einfach alles ändern kann.

    Es war also nicht alles 100% nach Ausgabe phpMyAdmin, nur die Schreibweisen wurden nach phpMyAdmin übernommen, damit es überhaupte eine Norm gibt. Der Rest wurde einfach so übernommen wie es das Team damals so wollte, ggf. einschließlich deren Fehler.
    Bislang hat das jeder der daran entwickelt hat, so gemacht wie es ihm gerade gefallen hat. Jetzt ist wenigstens eine klare Linie drin.

    Ich habe also alles nur schematisch überarbeitet gemäß MySQL, nichts grundsätzlich geändert, das muss das Team machen. Ein Glaubenskrieg was nun richtiger ist, ob nun MySQL oder reines SQL bringt uns hier ja nicht weiter.
    Es gibt keine sauberere und sinnvollere Möglichkeit als sich MySQL-Anweisungen per phpMyAdmin erstellen zu lassen. Es ist ja auch das Standard-Tool nach dem sich jeder richtet.

    Habe es auch per Copy & Paste in Beyond Compare (Dateivergleicher) gemacht, um Fehler auszuschließen.
    Beim manuellen ändern passieren sonst (siehe Original) zu viele Fehler und Abweichungen, diese Verantwortung wird das Team hier dann erst recht nicht übernehmen, zumal ich ein zögern ja schon jetzt spüre.
    Doch wichtig wäre hier was zu machen, man kann ja nicht nur die Oberfläche putzen und die Basis verkommen lassen :)

    Erstmal das Grobe ist damit getan und die Feinheiten kann und muss man dann nach und nach korrigieren, wie es richtig ist. Nur so bekommt man alle Fehler raus.

    Wichtig
    Ich habe nichts an den Inserts (sprich Daten) verändert, nur die Struktur. Die Daten hatte ich gar nicht mit phpMyAdmin exportiert.
    Für Selbstmord bin ich dann doch noch zu jung. Das muss schrittweise gemacht werden :)
    Die Inserts sind also auch kein Ergebnis von phpMyAdmin, sondern hat sich so irgend n Entwickler ausgedacht.

    vr

    • modified Team
    • Beiträge: 2.664
    Hallo speedy, billybob,

    ihr habt doch beide Recht.

    Speedy, wenn Du sagst, wir brauchen eine Möglichkeit, Datenbankänderungen bzw die Abweichungen zwischen zwei DBs sichtbar zu machen. Wir haben es noch nicht im Tracker, aber der Punkt steht seit einiger Zeit auf meiner internen Wunschliste, nämlich, dass man die DB-Struktur eines beliebigen Shops gegen den aktuellen modified eCommerce Shopsoftware-Referenzshop vergleichen kann. Dazu muss mindestens das passieren, was Speedy gemacht hat, nämlich die DB-Metadaten zu normalisieren. Ob man dazu phpmyadmin bemüht oder direkt auf die Systemtabellen losgeht, müssen wir noch sehen. Nebeneffekt: auch die Installationsskripte würden normalisiert ausgeliefert und dadurch besser lesbar.

    Billybob, wenn Du sagst, kann doch nicht sein, dass ich in MySQL in ein int-Feld einfach irgendwelche Zeichenketten einfügen kann, wofür brauche ich dann überhaupt Feldtypen? Ja, ist aber MySQL-spezifisch, hat mit Speedys Beitrag wenig zu tun. Ich komme auch nicht von MySQL, sondern von Firebird, Informix und Oracle, und mir wird natürlich auch schlecht, wenn ich sehe, wie beliebig das in MySQL gehandhabt wird. MySQL ist aber das, was wir derzeit einsetzen.

    Für Shopbetreiber wäre es nützlich, wenn sie sehen könnten, wo und wie ihre DB-Struktur von der aktuellen Shopversion abweicht. Speedy macht das mit seinem Ansatz zum Thema.

    Grüße, Volker

    Tomcraft

    • modified Team
    • Gravatar
    • Beiträge: 46.369
    • Geschlecht:
    [...]
    @Tomcraft
    Wozu braucht man denn die ganzen Kommentare? Die Entwickler brauchen Sie, aber ansonsten niemand. Und die Änderungen werden ja wohl hoffentlich im SVN dokumentiert, oder?
    Diese Kommentare machen den Code nur unübersichtlich.
    [...]

    Das sehe ich anders und ich denke jeder, der mal ein Modul eingebaut wird glücklich sein, dass wir die Änderungen so gut im Quelltext dokumentiert haben.

    Grüße

    Torsten

    12 Antworten
    3129 Aufrufe
    25. Januar 2024, 21:48:01 von Tomcraft
    1 Antworten
    2022 Aufrufe
    14. November 2013, 20:40:40 von web28
    2 Antworten
    3228 Aufrufe
    11. November 2014, 12:37:14 von owarken