Hallo Milo

Danke für deine Unterstützung.

Wenn du schon mal "da" bist. Kannst du bitte meine Fragen zu deinem PR #76 beantworten.

Ich sehe keinen Grund für die UNIQUE-Bedingung. Ein Datensatz ist konsistent, wenn er eine POSTING-ID und eine USER-ID besitzt - ergo ist das der PRIMARY KEY.

Gut, der UNIQUE INDEX entspricht, bezogen auf die Benutzung von INSERT ON DUPLICATE KEY UPDATE dem Verhalten von PRIMARY KEY, womit ich, nach Tests mit der nach deinem Vorbild geänderten Struktur, keine Probleme sehe.

Das hatte ich in der BOOKMARK-Tabelle auch so vorgesehen, bis ich die Signatur der move_item-Funktion gesehen habe, die einen ID erfordert.

Der Satz bezieht sich in Sachen move_item ausschließlich auf die Bookmark-Funktion? Sortieren brauchen wir beim Gelesen-Status ja nichts.

ENGINE/COLLATE

Diese Angaben übernehme ich von den Tabellendefinitionen der bereits vorhanden Tabellen.

Diese Tabelle wird in einem von angemeldeten Benutzern stark frequentierten Forum eine der am häufigsten geänderten Tabellen sein. Jeder Aufruf eines Beitrags durch einen angemeldeten Benutzer erzeugt oder ändert einen Datensatz in dieser Tabelle.

An dieser Stelle ist es sinnvoll, von den Fähigkeiten der InnoDB-Engine zu profitieren. Dazu gehören: Row Lock statt Table Lock bei MyISAM und Speicherung der Daten in der Reihenfolge der Primärschlüssel. Die gebotene Transaktionssicherheit werden wir bei diesem Feature hingegen nicht brauchen. Die InnoDB-Engine ist zwar, nachdem, was ich gelesen habe, über alles statistisch etwas langsamer, in diesem Einsatzszenario sollten aber der Vorteil, für einen Schreibvorgang nicht die ganze Tabelle, sondern nur die betroffene Zeile zu sperren, überwiegen.

Zusammengefasst: Die Schreibvorgange erfolgen, jeder für sich, zwar etwas langsamer, insgesamt (wenn im Forum viel los ist) aber schneller, weil mehrere Schreibvorgänge in verschiedenen Zeilen der Tabelle gleichzeitig stattfinden können.

In Sachen Collation bin ich mir nicht sicher, ob die Angabe beim erstellen der Tabelle von der Datenbankengine nicht einfach wegoptimiert wird. An der Stelle wäre das eine unnötige Angabe, die wir dann weglassen könnten. Ich teste das nochmal auf meinem Webspace.

Tschö, Auge