Antworten: 18
Seite [1] |
|
 SeronRock the board Beiträge: 76 |
# Thema - 18.04.2012 um 23:48 Uhr
Hi, ich arbeite gerade an einem Skript, wo Benutzer gemeinsam an einem Dokument arbeiten können. Dokumente haben Kapitel und Unterkapitel, welche auch verschoben werden können. In der Datenbank ist das durch eine Position (int) geregelt. Die Reihenfolge soll immer aufeinanderfolgend bleiben, also 1,2,3,...,n. Jetzt könnte es ja sein, dass 2 oder 3 Benutzer gleichzeitig Kapitel verschieben. Muss ich mir großartig Gedanken über Transaktionskontrolle (ACID) machen, oder ist die Wahrscheinlichkeit bei 2-3 Nutzern (die gerade an einem Dokument arbeiten) viel zu Gering, das tatsächlich ein Prozess gleichzeitig stattfindet? Wie groß sollte man überhaupt auf Einhaltung von ACID achten, bei kleinen bis mittelgroßen PHP/Datenbank-Projekten? Zuletzt editiert von Seron am 18.04.2012 um 23:49 Uhr (1x Editiert)
|
Inaktiv |
 |
hajo  VIP - Poster  Herkunft: Barsbüttel Beiträge: 9411 |
# Antwort: 1 - 19.04.2012 um 00:15 Uhr
um die acid eigenschaften kümmert sich die datenbank ja selbst. die frage ist wohl eher, wann bzw. wie oft du eine neue version anlegen und diese per datenbank persistieren möchtest. ------------------ ClanSphere - professional clan care starts here |
Inaktiv |
|  |
| Fr33z3m4n Medal of Honor  Herkunft: Hamm Beiträge: 11094 |
# Antwort: 2 - 19.04.2012 um 08:05 Uhr
Bei gleichzeitigem Speichern eines Dokuments solltest du Transact nutzen, um inkonsistenz der Datenbank vorzubeugen. Sollte die Transact dann fehlgeschlagen, den Benutzer darauf hinweisen, und ggf. die geänderten Daten anzeigen (wie auch immer das bei dir möglich sein könnte). ------------------ mfg Patrick "Fr33z3m4n" Jaskulski  Antoine de Saint-Exupéry: Wenn Du ein Schiff bauen willst, so trommle nicht Männer zusammen, um Holz zu beschaffen, Aufgaben zu verteilen, sondern lehre die Männer die Sehnsucht nach dem endlosen weiten Meer. |
Inaktiv |
  | |
 MindcrimeGeekboy  Beiträge: 1155 |
# Antwort: 3 - 19.04.2012 um 08:31 Uhr
Die moeglichkeit das 2 leute gleichzeitig schreiben in die datenbank ist nichtmal dein groesstest problem (obwohl transactions dan zu empfelen sind), aber das groessere problem ist, das die daten inzwisschen geaendert sein koennten. Beispiel: Editor A startet editieren kapittel 1 am zeitpunkt X Editor B startet editieren kapittel 1 am zeitpunkt X+1 Editor B speichert kapittel 1 am zeitpunkt X + 2 Editor A speichert kapittel 1 am zeitpunkt X + 3 Wenn du beim speichern nicht checkst ob das kapittel schon geaendert wurde, sind alle aenderungen im obigen beispiel von Editor B weg ... Zuletzt editiert von Mindcrime am 20.04.2012 um 11:38 Uhr (1x Editiert) |
Inaktiv |
| |
| hajo VIP - Poster Herkunft: Barsbüttel Beiträge: 9411 |
# Antwort: 4 - 19.04.2012 um 11:28 Uhr
wenn man wie ich es meinte alles versioniert kommt ja nichts wirklich weg bzw ist dann per diff tool / suche auffindbar. ------------------ ClanSphere - professional clan care starts here |
Inaktiv |
| |
| Fr33z3m4n Medal of Honor Herkunft: Hamm Beiträge: 11094 |
# Antwort: 5 - 19.04.2012 um 13:33 Uhr
Willst du aber für jede Änderung eine neue Version speichern ? ------------------ mfg Patrick "Fr33z3m4n" Jaskulski Antoine de Saint-Exupéry: Wenn Du ein Schiff bauen willst, so trommle nicht Männer zusammen, um Holz zu beschaffen, Aufgaben zu verteilen, sondern lehre die Männer die Sehnsucht nach dem endlosen weiten Meer. |
Inaktiv |
| |
| hajo VIP - Poster Herkunft: Barsbüttel Beiträge: 9411 |
# Antwort: 6 - 19.04.2012 um 13:45 Uhr
was spricht dagegen? ------------------ ClanSphere - professional clan care starts here |
Inaktiv |
| |
| Fr33z3m4n Medal of Honor Herkunft: Hamm Beiträge: 11094 |
# Antwort: 7 - 19.04.2012 um 14:13 Uhr
die Menge der Datensätze, welche am Ende eines Dokuments vorhanden sind. Denn du willst ja nicht nur in die DB schreiben, dass eine Änderung war, sondern auch das Dokument, wie es ggf. vorher war, oder was verändert wurde. Somit ist ein Blobfeld unabdingbar. Seh das hier auf Arbeit bei einem Produkt. Allein, für 19.041 Zeilen (was bei sehr vielen Dokumenten, mit DocVersion nicht viel ist), brauchte die Abfrage inkl. blob schon über 4 Minuten. Das wohl gemerkt bei einem SQLServer im Netzwerk. Aber das ist meine persönlich Einschätzung, jede kann das natürlich anders beurteilen, und es kommt auf die Nutzung des Systems an. ------------------ mfg Patrick "Fr33z3m4n" Jaskulski Antoine de Saint-Exupéry: Wenn Du ein Schiff bauen willst, so trommle nicht Männer zusammen, um Holz zu beschaffen, Aufgaben zu verteilen, sondern lehre die Männer die Sehnsucht nach dem endlosen weiten Meer. |
Inaktiv |
| |
| hajo VIP - Poster Herkunft: Barsbüttel Beiträge: 9411 |
# Antwort: 8 - 19.04.2012 um 14:53 Uhr
jede änderung in der db zu sichern wäre wohl auch übertrieben. man könnte aber z.b. html 5 local storage verwenden und bei drücken von save eine neue echte version in der db anlegen. ------------------ ClanSphere - professional clan care starts here |
Inaktiv |
| |
| Seron Thread-Ersteller Rock the board Beiträge: 76 |
# Antwort: 9 - 19.04.2012 um 20:21 Uhr
Ein Dokument besteht ja schon aus mehreren Tabellen (Dokument -> Kapitel -> Inhalt). Somit dürfte das kein Problem sein. Man kann dann auch soweit kollaborativ arbeiten, so lange nicht parallel an einem Inhalt gearbeitet wird. Sorgen macht mir nur das verschieben der Position eines Kapitels, da ja dann alle drüber liegende Kapitel per Update eine Position nach oben verschoben werden. Somit können schon mal 20 Updates hintereinander folgen. wenn nun mehrere Personen gleichzeitig Kapitel nach oben/unten verschieben, könnte es ohne Transaktionskontrolle wohl zu inkositenzen führen. Ich habe mich nun einfach dazu entschieden, meine Datenbank-Klasse in PHP so zu erweitern, das Befehle erstmal in einer Liste gespeichert werden und erst am ende des Scripts wird dann die Liste mit einem Begin/Commit abgearbeitet. Sollte es zu einem Fehler kommen, gibt es ein Rollback und fertig. Zuletzt editiert von Seron am 19.04.2012 um 20:21 Uhr (1x Editiert) |
Inaktiv |
| |
| Fr33z3m4n Medal of Honor Herkunft: Hamm Beiträge: 11094 |
# Antwort: 10 - 19.04.2012 um 20:30 Uhr
Zusätzlich könntest noch mit Locks auf die Table, andere Updates, während deiner Transaction blockieren. Wichtig ist halt, dass du das Backend dementsprechend umsetzt. Wenn Table Lock ist, erstmal weitere Änderungen stoppen, ggf. den Benutzer erstmal sperren, und warten bis lock raus ist. Erst dann schauen ob Änderungen vorhanden sind, und wenn ja, mit DiffTool die Unterschiede anzeigen. Das Projekt was du vorhast, ist nicht ganz ohne Fallstricke, gehe aber mal davon aus, wenn es zu Komplikationen kommen sollte, dass du dich hier meldest 
------------------ mfg Patrick "Fr33z3m4n" Jaskulski Antoine de Saint-Exupéry: Wenn Du ein Schiff bauen willst, so trommle nicht Männer zusammen, um Holz zu beschaffen, Aufgaben zu verteilen, sondern lehre die Männer die Sehnsucht nach dem endlosen weiten Meer. |
Inaktiv |
| |
| Seron Thread-Ersteller Rock the board Beiträge: 76 |
# Antwort: 11 - 19.04.2012 um 21:01 Uhr
19.04.2012 um 20:30 Uhr - Fr33z3m4n: Zusätzlich könntest noch mit Locks auf die Table, andere Updates, während deiner Transaction blockieren. Wichtig ist halt, dass du das Backend dementsprechend umsetzt. Wenn Table Lock ist, erstmal weitere Änderungen stoppen, ggf. den Benutzer erstmal sperren, und warten bis lock raus ist. Erst dann schauen ob Änderungen vorhanden sind, und wenn ja, mit DiffTool die Unterschiede anzeigen. Das Projekt was du vorhast, ist nicht ganz ohne Fallstricke, gehe aber mal davon aus, wenn es zu Komplikationen kommen sollte, dass du dich hier meldest Das mit dem DiffTool ist eine sehr gute Idee. Falls es jemanden interessiert: Es geht übrigens um ein Projekt wo sich Autoren registrieren können um Guides/Tutorials zu schreiben. Ein Guide soll dann vom Ersteller auch für andere Autoren freigegeben werden. Außerdem sollen Nutzer auch Guides "favouriten" können und auf der eigenen Userseite in Ordner ablegen. Natürlich gibt es auch einen umfangreichen Guide-Browser mit Suchfunktion wo Guides nach Kategorien oder Beliebtheit angezeigt werden können. Wenn eine Gruppe von Autoren dann an diversen Tutorials für ein Thema arbeitet, soll das dann in einem Guide mit Inhaltsverzeichnis und Kapiteln zusammen gefasst werden. Inhaltsverzeichnis und Nummerierungen sollen automatisch generiert werden, so dass Autoren nur Kapitel/Unterkapitel und natürlich Inhalte erstellen und positionieren können. Den Rest erledigt dann das System. Jedes Kapitel kann zusätzlich Bilder und Videos enthalten. Hochgeladene Bilder können mit Drag&Drop in den Editor geschoben werden. Kapitel-Videos werden vorerst unter dem Inhalt eingebettet. Zusätzlich können Nutzer auch Kommentare zu jedem Kapitel verfassen. Zusätzlich soll die Möglichkeit bestehen, ein komplettes Guide mit Inhaltsverzeichnis als PDF zu exportieren. Es handelt sich also um eine Plattform für Guides mit Aspekten eines Sozialen Netzwerkes. Autoren haben auch auf der eigenen Userseite die Möglichkeit, ihre Guides in eigene Unterordner zu sortieren und abzulegen. Autoren werden für Favourites von anderen Usern und für das schreiben von Guides mit Punkten belohnt, welche Auswirkungen auf ein Levelsystem und Userranking hat. Das soll dann etwas für Motivation sorgen. Zuletzt editiert von Seron am 19.04.2012 um 21:09 Uhr (1x Editiert) |
Inaktiv |
| |
| Fr33z3m4n Medal of Honor Herkunft: Hamm Beiträge: 11094 |
# Antwort: 12 - 20.04.2012 um 08:07 Uhr
Soll das ganze unter PHP laufen ? ------------------ mfg Patrick "Fr33z3m4n" Jaskulski Antoine de Saint-Exupéry: Wenn Du ein Schiff bauen willst, so trommle nicht Männer zusammen, um Holz zu beschaffen, Aufgaben zu verteilen, sondern lehre die Männer die Sehnsucht nach dem endlosen weiten Meer. |
Inaktiv |
| |
| Seron Thread-Ersteller Rock the board Beiträge: 76 |
# Antwort: 13 - 20.04.2012 um 11:00 Uhr
20.04.2012 um 08:07 Uhr - Fr33z3m4n: Soll das ganze unter PHP laufen ? ja |
Inaktiv |
| |
| Fr33z3m4n Medal of Honor Herkunft: Hamm Beiträge: 11094 |
# Antwort: 14 - 20.04.2012 um 13:49 Uhr
hmm. Wieviele Autoren erwartest du denn ? ------------------ mfg Patrick "Fr33z3m4n" Jaskulski Antoine de Saint-Exupéry: Wenn Du ein Schiff bauen willst, so trommle nicht Männer zusammen, um Holz zu beschaffen, Aufgaben zu verteilen, sondern lehre die Männer die Sehnsucht nach dem endlosen weiten Meer. |
Inaktiv |
| |
| Seron Thread-Ersteller Rock the board Beiträge: 76 |
# Antwort: 15 - 20.04.2012 um 14:02 Uhr
Erst mal nicht viele - da sich aber jeder registrieren kann um mit zu machen, sollte es natürlich nach oben hin offen sein. |
Inaktiv |
| |
| Fr33z3m4n Medal of Honor Herkunft: Hamm Beiträge: 11094 |
# Antwort: 16 - 20.04.2012 um 16:37 Uhr
habe eher die Befürchtung, wenn es zu viele Autoren werden, dass PHP dann irgendwann nciht mehr ausreichen sollte. Würde dir daher vorschlagen, schon vorher auf JSP (Tomcat) zu gehen. ------------------ mfg Patrick "Fr33z3m4n" Jaskulski Antoine de Saint-Exupéry: Wenn Du ein Schiff bauen willst, so trommle nicht Männer zusammen, um Holz zu beschaffen, Aufgaben zu verteilen, sondern lehre die Männer die Sehnsucht nach dem endlosen weiten Meer. |
Inaktiv |
| |
| Seron Thread-Ersteller Rock the board Beiträge: 76 |
# Antwort: 17 - 21.04.2012 um 23:25 Uhr
DIe Eingaben sollen ja nicht in Echtzeit (so wie bei Google Docs) übertragen werden, sondern ganz normal beim Absenden der Änderung. Von der Performance der Programmlogik wird also nicht mehr abverlangt, wie bei einem gut besuchten Forum. Dazu sollte PHP schon in der Lage sein :-) |
Inaktiv |
| |
| Fr33z3m4n Medal of Honor Herkunft: Hamm Beiträge: 11094 |
# Antwort: 18 - 23.04.2012 um 15:34 Uhr
Ok, wenn du es doch so simpel halten möchtest, klar dann reicht PHP völlig aus
------------------ mfg Patrick "Fr33z3m4n" Jaskulski Antoine de Saint-Exupéry: Wenn Du ein Schiff bauen willst, so trommle nicht Männer zusammen, um Holz zu beschaffen, Aufgaben zu verteilen, sondern lehre die Männer die Sehnsucht nach dem endlosen weiten Meer. |
Inaktiv |
| |
Antworten: 18
Seite [1] |
|
| Sie müssen sich registrieren, um zu antworten. |
