Antwort #80 am: 21. August 2020, 19:44:23
@noRiddle, ich werde dir mal antworten, aber nicht so vermessen wie Deine Antwort / Frage rüberkam.
zu 1. was hast Du immer mit InnoDB nachfolgend einige hoffentlich auch für Dich schlagende Elemente.
InnoDB hat Sperren auf Zeilenebene. MyISAM verfügt nur über vollständige Sperren auf Verzeichnisebene.
InnoDB verfügt über eine sogenannte referenzielle Integrität, welche die Unterstützung von Fremdschlüsseln (RDBMS) und Beziehungsbeschränkungen beinhaltet, MyISAM nicht (DMBS).
InnoDB unterstützt Transaktionen, das heißt du kannst einen Commit und einen Rollback ausführen. MyISAM tut das nicht.
InnoDB ist zuverlässiger, da es Transaktionsprotokolle für die automatische Wiederherstellung verwendet. MyISAM tut das nicht.
InnoDB hat eine bessere Performance und sich als zuverlässiger erwiesen, als MyIsam. Alleine das solle schon ein Grund sein InnoDB statt MyISAM zu verwenden. Ein weiterer starker Grund das MyIsam nur über eine vollständige Sperrung auf Verzeichnisebene verfügt wogegen InnoDB Sperrung auf Zeilen Ebene unterstützt. Dadurch können Abfragen schneller verarbeitet werden.
Mehr dazu nicht mehr, den Rest kann jeder selbst rausfinden.
Zu Punkt zwei ich verwechsele nichts, war nur zu faul das alles auszuschreiben, weil nicht erforderlich.
Zu 3 kann ich nur sagen, das eben Standard bei modified für Artikelbezeichnung eben varchar verwendet wird und das mit 255 Zeichen. Daher mein Hinweis. Trifft auch noch auf Newsletter u. a. zu.
Zu 4 bekommst Du auch eine Antwort von mir.
Der Grund für für viele Probleme beim speichern von UTF-8 Dateien mit BOM ist, dass beim Speichern als UTF-8 am Anfang der Datei ein “Byte Order Mark” (kurz: BOM) geschrieben wird. Der BOM für UTF-8 lautet U+FEFF und ist drei Bytes groß – 0xEF, 0xBB und 0xBF. Die drei Bytes werden nach Windows-1252 als “” dargestellt. Für UTF-16 und UTF-32 wird das BOM für die Byte-Reihenfolge verwendet, welches bei UTF-8 nicht wirklich notwendig ist.
Leider interpretieren Browser bzw. PHP den BOM nicht richtig. Insbesondere PHP denkt, dass bereits eine Ausgabe stattgefunden hat, sodass es zu spät ist, den Header zu verändern. Der Fehler tritt bei ANSI nicht auf, weil dieser keinen BOM besitzt.
Lösung und Antwort für noRiddle und andere Interessierte.
Die Lösung ist einfach: Die Datei muss mit der Kodierung “UTF-8 ohne BOM” gespeichert werden.
Und bitte in Zukunft weniger Agro. Ich habe keinen Groll auf jemanden von Haus aus.
cu snocer