OneQ,
hier
https://mariadb.com/kb/en/converting-tables-from-myisam-to-innodb/ ist eine Beschreibung, auf was man achten sollte. Das ist allerdings schon viel zu weitgehend, wenn Du gerade anfängst, Dich mit DB-Grundlagen zu befassen.
Karls Skript macht das, was sie bei mariadb im ersten Absatz beschreiben, eine Änderung der Tabellenengine der betreffenden Tabelle(n). Das ist der einfache Part, und der sollte normalerweise klappen.
Du kannst das gefahrlos ausprobieren. Hoster bieten normalerweise mehr als eine DB an, also klonst Du die shop-DB und konvertierst sie zb mit Karls Skript. Du kannst auch direkt auf SQL-Ebene hantieren, das ist noch einfacher, hier beschrieben:
https://computingforgeeks.com/how-to-convert-all-mysql-tables-from-myisam-into-innodb-storage-engine/SELECT CONCAT('ALTER TABLE ', TABLE_NAME, ' ENGINE=InnoDB;')
FROM INFORMATION_SCHEMA.TABLES
WHERE ENGINE = 'MyISAM'
AND table_schema = 'mydb';
'mydb' mit Deinem DB-Namen ersetzen. Diese Abfrage erzeugt Dir das sql-skript fürs update der Tabellen. Das Skript führst Du dann in einem DB-Admintool aus und fertig.
Grundsätzlich zum Unterschied MyIsam - InnoDB. Zentrale Features relationaler Datenbanken waren schon immer Transaktionen und Fremdschlüssel. Mit dem Aufkommen von MySQL wurden da gleich mehrere massive Rückschritte gemacht. Die Leute, die MySQL ursprünglich konzipierten, hatten von Datenbanken nicht allzuviel Ahnung, ihr Schwerpunkt war Web, und das ist der völlig entgegengesetzte Ansatz. Bei Web leichte Struktur, flexibel, ständige Änderungen der Struktur. Bei relationalen DB sorgfältig geplante Struktur, die mindestens die nächsten 5 Jahre halten muss und nur selten angepasst wird. Abbildung aller Querbeziehungen in der Struktur. Konsistenz der Daten ist extrem wichtig, mache ich einen Fakturationslauf, darf nicht bei einem Fehler auf halber Strecke ein Teil der betroffenen Daten aktualisiert sein und der Rest halt nicht. Bei einer Visitenkartenwebsite egal. Aber das ist der MySQL-Ansatz, keine Transaktionen, keine Fremdschlüssel, keine Replikation, die den Namen verdient, keine Stored Procedures bzw Placebos, damit man nicht zugeben muss, man kanns nicht, keine mehrfachen Trigger, kein Backup im laufenden Betrieb usw. Einfach kompletter Ranz.
Beworben wurde das damals vom MySQL-Team mit "die schnellste Datenbank der Welt". Ja logisch, es war ja keine, sondern ein Filesystem mit SQL-Schnittstelle. Aus Sicht von Datenbankmenschen Spielzeug. Fairerweise muss man sagen, dass es Ende der 90er, als MySQL populär wurde, keine Open Source-Datenbanken gab, und die kommerziellen Anbieter Oracle, Informix, IBM sich ihre Klopper vergolden ließen. Die waren für angehende Websitebetreiber einfach keine Option, weder von den Kosten, noch vom nötigen Knowhow. Postgres gabs zu der Zeit nur für Linux, kaum ein Hoster hatte die im Angebot, also auch keine Option, obwohl es mittlerweile eine der besten OpenSource-DBs ist. Firebird ist eine weitere sehr gute OpenSource-Datenbank, die ab 2000 als Fork von Borlands Interbase verfügbar war, Oracle und MS locker das Wasser reicht, aber keiner Firma, sondern einer Stiftung gehört und daher nicht käuflich ist wie MySQL - ein Vorteil, wenn man nicht durch Übernahme auf Eis gelegt werden will.. Microsoft sprang wie beim Browser spät auf den Zug auf, die hatten genausowenig Ahnung von Datenbanken (die Desktop-DB Access gabs) wie die MySQL-Leute, , was MS aber nicht daran hinderte, ihren selbstverständlich, wie beim Browser nicht standardkonformen DB-Server SQL-Server zu nennen, als hätten sie SQL erfunden.
Historisch ist es so gelaufen, der MySQL-Dünnbrettbohreransatz funktionierte fürs Web, und deshalb haben wir auch in der Shopsoftware MySQL.. Bzw je nach Hoster den Oracle-unabhängigen besseren Fork MariaDB, weil Oracle irgendwann MySQL aufkaufte und auf Eis legte, die machen sich ja nicht unnötig selber Konkurrenz. So bekam MySQL bspw erst die für Auswertungen wichtigen Window Functions oder hot backup, als alle Welt das schon jahrelang bzw schon immer hatte. Soweit der historische Rant.
Zurück zu MyIsam - InnoDB. Die Konvertierung der Shoptabellen ist technisch einfach, s.o. Dann aber den nächsten Schritt zu gehen und die Struktur der DB der Engine entsprechend zu gestalten, ist keine Kleinigkeit, sondern erfordert sorgfältige Planung. Ein Beispiel: Im shop können Kunden ihren Account löschen. Was bedeutet das? Alles, was mit dem Kunden zu tun hat, kommt weg. Ok, aber was ist mit den Bestellungen? Die dürfen nicht weggeworfen werden, gesetzlich. Wenn der Kram noch in der Wawi/Fibu ist, ok. Wenn nicht, und der Shop auch die Wawi ist, dann nicht ok. Hier kann man also nicht einfach definieren, dass alle Tabellen, die einen Fremdschlüssel zu customers haben (wie orders) auf diesen FK ein on delete cascade machen: denn wird der Kundensatz gelöscht, fliegen sein Aufträge auch raus. Macht man an der Stelle on delete no action, kann das Kundenkonto nicht gelöscht werden, bereits von der Datenbank aus. Macht man on delete set null, signalisiert der abhängige Satz (der Auftag) anschließend immerhin, dass es den übergeordneten Satz (den Auftraggeber) nicht mehr gibt. Hier nicht so tragisch, weil viele Kundenmerkmale redundant in orders gehalten werden, aber das war jetzt nur eine Beziehung. Davon haben wir 100, die alle durchdacht werden müssen.
Es gibt gute Gründe, Beziehungen zwischen Tabellen über die Struktur festzulegen und Datenänderungen in Transaktionen durchzuführen, damit Datenkonsistenz grundsätzlich sichergestellt ist. Das ist die Aufgabe einer relationalen Datenbank, dafür sind sie optimiert. Datenqualität ist wichtig, Wenn nicht -> unnötige Mehrarbeit, Mehrkosten, unzufriedene Kunden, verfälschte Auswertungen, suboptimale Entscheidungsgrundlage, evtl sogar Abmahnungen. Aber das Definieren der Datenbeziehungen erfordert sorgfältige Planung, ist ein bisschen wie die Planung für ein Haus, das ändert man auch nicht alle 3 Wochen. Aber in der DB muss es trotzdem so organisiert sein, dass es sich ohne großen Aufwand erweitern lässt.
Viele Grüße, vr
