Eigentlich kommt es auf die Art der Anwendung an. Wenn man so das übliche one-to-many und many-to-many richtig in seinen Tabellen verankert (via references-clause, siehe http://dev.mysql.com/doc/refman/5.1/de/create-table.html) dann kann kein Absturz der Datenbankkonsistenz etwas anhaben. Wenn man allerdings eine Anwendung für eine Bank schreibt, in der der Kunde A etwas überweist, und Abbuchung und Gutschrift auf Konto von B unbedingt zusammen ausgeführt werden müssen, dann muss das tatsächlich in eine Transaktion gepackt werden.
Diese Idee mit "jedem Nutzer seine Tabelle" ist, wie Stefan schon richtig sagte, keine gute. Einfach die Nutzer_Id mit in der Tabelle speichern. Ganz gut auch: http://www.sql-und-xml.de/sql-tutorial/ Mike, an Deiner Stelle würde ich mich auch in eine MySQL-spezifische Liste eintragen. Maximilian Tyrtania Software-Entwicklung Dessauer Str. 6-7 10969 Berlin http://www.contactking.de Am 06.01.2011 um 11:00 schrieb Thomas Tempelmann: >> Kannst du mir sagen, was das bedeutet. Wie verwendet man Transactions >> konkret? Gibt es noch etwas, was man beachten muss? > > Das soltest du dir mal in einem SQL-"Buch" durchlesen, sowas gibts > auch massenhaft kostenlos im Internet. > Ich bin da auch kein Fachmann. Solange die Apps auf verschiedene > Tables zugreifen, ist das eh egal. > Transactions sollte man trotzdem verstehen, damit man sich die > Datenkonsistenz nicht versaut, wenn die App mal mittendrin absemmelt. > > -- > Thomas Tempelmann, http://www.tempel.org/ >
