nicht angemeldet
Login und Rechte - Wie aufwendig?
HenryHallo,
ich habe eine sehr allgemeine Frage und es geht mir nur um eine grobe Einschätzung.
Wie aufwendig ist es ein Login zu erstellen, wo unterschiedliche Rechte vergeben werden?
Zu Beginn sollen max. 10 Nutzer Logindaten bekommen, diese sollen dann auf einer internen Webseite ihre Daten lesen, schreiben, ändern, löschen können. Die Daten der anderen Nutzer dürfen sie nicht sehen.
Ideal wäre es auch ein Protokoll bei jedem Login zu erstellen und darin festzuhalten, wenn der Nutzer Daten eingetragen, geändert oder gelöscht hat.
Macht man so etwas am besten per Script + DB, nur mit Hilfe von MySQL oder SQL + Server.
Wie man erkennt, kenne ich mich nicht so wirklich auf dem Gebiet aus und bitte um Verständnis, falls ich Blödsinn frage oder schreibe :-)
Gruß ebody
-
Lieber ebody,
Macht man so etwas am besten per Script + DB, nur mit Hilfe von MySQL oder SQL + Server.
Du benötigst eine "Datenbank" (z.B. MySQL, SQL-Server, oder ein einfaches Flatfile) und eine "Geschäftslogik" (Programm) in Form eines (serverseitigen) Scripts.
Liebe Grüße,
Felix Riesterer.
-
Tach!
Macht man so etwas am besten per Script + DB, nur mit Hilfe von MySQL oder SQL + Server.
Du benötigst eine "Datenbank" (z.B. MySQL, SQL-Server, oder ein einfaches Flatfile) und eine "Geschäftslogik" (Programm) in Form eines (serverseitigen) Scripts.
Flatfile ist schlecht für ein Multiuser-System. Man muss sich dabei auch noch um Locking kümmern, sonst gibts sporadischen und schlecht nachvollziehbaren Datenverlust. Lieber SQLite nehmen, das ist quasi auch Flatfile, aber wird von der SQLite-API verwaltet, die für ordnungsgemäßen Parallelzugriff sorgt.
dedlfix.
-
hallo
Flatfile ist schlecht für ein Multiuser-System. Man muss sich dabei auch noch um Locking kümmern, sonst gibts sporadischen und schlecht nachvollziehbaren Datenverlust. Lieber SQLite nehmen, das ist quasi auch Flatfile, aber wird von der SQLite-API verwaltet, die für ordnungsgemäßen Parallelzugriff sorgt.
Oder noch besser: Userdaten konsequent physikalisch trennen.
-
Hallo dedlfix,
Flatfile ist schlecht für ein Multiuser-System. Man muss sich dabei auch noch um Locking kümmern, sonst gibts sporadischen und schlecht nachvollziehbaren Datenverlust. Lieber SQLite nehmen, das ist quasi auch Flatfile, aber wird von der SQLite-API verwaltet, die für ordnungsgemäßen Parallelzugriff sorgt.
Also erst laufen, bevor man gehen kann? Klappt zwar manchmal, aber ich finde den StepbyStep-Weg besser. Und was das Locking betrifft, finde ich gut das zu wissen/lernen, obwohl es mittlerweile meist unnötig geworden ist:
file_put_contents($fl, $cont, LOCK_EX);Insgesamt merke ich auch bei Leuten, denen ich so was näherbringe, dass die Erfolgs- und Erkenntniserlebnisse, wesentlich besser/schneller/verständlicher sind, wenn erst mal alles flatfilebasierend ist. Oder anders, schnelleres Verständnis = mehr Spaß beim Lernen. SQL-Syntax und Einbindungen erfordert schon mehr Lernwillen.Gruss
Henry-
Tach!
Und was das Locking betrifft, finde ich gut das zu wissen/lernen, obwohl es mittlerweile meist unnötig geworden ist:
file_put_contents($fl, $cont, **LOCK_EX**);Wenn du die Datei ändern möchtest, muss sie nicht nur zum Schreiben, sondern bereits ab dem Lesen gesperrt werden und bis der Schreibvorgang abgeschlossen ist. Der Vorgang muss atomar sein, sonst grätscht dir ein anderer Prozess dazwischen und schreibt etwas rein, das du nicht mehr berücksichtigst. file_put_contents() ist also für ein Szenario mit parallelem Zugriff nicht geeignet, weil dort das Locking nur für den Schreibvorgang gesetzt werden kann.
dedlfix.
-
Hallo dedlfix,
Wenn du die Datei ändern möchtest, muss sie nicht nur zum Schreiben, sondern bereits ab dem Lesen gesperrt werden und bis der Schreibvorgang abgeschlossen ist. Der Vorgang muss atomar sein, sonst grätscht dir ein anderer Prozess dazwischen und schreibt etwas rein, das du nicht mehr berücksichtigst. file_put_contents() ist also für ein Szenario mit parallelem Zugriff nicht geeignet, weil dort das Locking nur für den Schreibvorgang gesetzt werden kann.
hmm… man lernt ja zum Glück nie aus. Aber verstanden habe ich das noch nicht ganz. Wie würde denn ein reales Negativbeispiel aussehen?
Gruss
Henry-
Tach!
Wenn du die Datei ändern möchtest, muss sie nicht nur zum Schreiben, sondern bereits ab dem Lesen gesperrt werden und bis der Schreibvorgang abgeschlossen ist. Der Vorgang muss atomar sein, sonst grätscht dir ein anderer Prozess dazwischen und schreibt etwas rein, das du nicht mehr berücksichtigst. file_put_contents() ist also für ein Szenario mit parallelem Zugriff nicht geeignet, weil dort das Locking nur für den Schreibvorgang gesetzt werden kann.
hmm… man lernt ja zum Glück nie aus. Aber verstanden habe ich das noch nicht ganz. Wie würde denn ein reales Negativbeispiel aussehen?
Hab ich das nicht schon beschrieben? Aber gut, hier nochmal wie der Ablauf stattfindet.
- A liest die Datei (ohne zu sperren)
- B liest die Datei (selber Inhalt wie bei 1.)
- A schreibt Änderungen
- B schreibt Änderungen basierend auf Stand 2. Damit sind die Änderungen von 3. verloren.
dedlfix.
-
Hallo dedlfix,
- A liest die Datei (ohne zu sperren)
- B liest die Datei (selber Inhalt wie bei 1.)
- A schreibt Änderungen
- B schreibt Änderungen basierend auf Stand 2. Damit sind die Änderungen von 3. verloren.
Das bedeutet, korrigier mich bitte, 4./B müsste entweder eine Warnung/Verbot erhalten oder erst gar nicht sehen können, solange 3./A einen Schreibzugriff darauf hat. Also doch wieder flock? hmm…
Gruss
Henry-
Tach!
- A liest die Datei (ohne zu sperren)
- B liest die Datei (selber Inhalt wie bei 1.)
- A schreibt Änderungen
- B schreibt Änderungen basierend auf Stand 2. Damit sind die Änderungen von 3. verloren.
Das bedeutet, korrigier mich bitte, 4./B müsste entweder eine Warnung/Verbot erhalten oder erst gar nicht sehen können, solange 3./A einen Schreibzugriff darauf hat. Also doch wieder flock? hmm…
A muss bei 1. den Lock setzen und B muss warten, bis A mit 3. fertig ist, bevor es 2. darf.
dedlfix.
-
Hallo dedlfix,
- A liest die Datei (ohne zu sperren)
- B liest die Datei (selber Inhalt wie bei 1.)
- A schreibt Änderungen
- B schreibt Änderungen basierend auf Stand 2. Damit sind die Änderungen von 3. verloren.
A muss bei 1. den Lock setzen und B muss warten, bis A mit 3. fertig ist, bevor es 2. darf.
Ja aber dieses "muss warten" ist die Sache die noch nicht klar ist. "muss warten" im Sinne von "sieht solange nichts" oder im Sinne von "Speichern geht nicht"?
Gruss
Henry-
Tach!
A muss bei 1. den Lock setzen und B muss warten, bis A mit 3. fertig ist, bevor es 2. darf.
Ja aber dieses "muss warten" ist die Sache die noch nicht klar ist. "muss warten" im Sinne von "sieht solange nichts" oder im Sinne von "Speichern geht nicht"?
Das kommt darauf an, wie du flock() aufrufst, mit oder ohne Block. Bei Block wartet flock() bis es den Lock bekommen kann, ansonsten kehrt die Funktion mit Fehler zurück. Weiterhin arbeitet diese Funktion unter Linux im Advisory Modus, das heißt, wenn man die Locks nicht selbst beachtet, kann man daran vorbei auf die Datei zugreifen. Beim Locking kann man auch Fehler machen. Ich habe mich nicht weiter damit beschäftigt, kenne also die Feinheiten nicht weiter, aber was ich gehört habe klang so, dass man eher mit SQL zurechtkommt, als dass man Mechanismus vollständig verstanden hat.
dedlfix.
-
Hallo dedlfix,
… aber was ich gehört habe klang so, dass man eher mit SQL zurechtkommt, als dass man Mechanismus vollständig verstanden hat.
Das ist ja was ich meine. Ich habe die internen Mechanismen sicherlich bei beiden Varianten nicht verstanden, weil wie heisst es so schön "it just works". Tatsächlich hatte ich vor sehr, sehr vielen Jahren nur einmal das Problem mit konkurrierenden Zugriffen, Schreibzugriffe wohlgemerkt. Da hatte ich eine Sperre vergessen. Seitdem nie wieder. Das Problem mit dem Lesezugriff entsteht aber auch bei SQL, glaube ich zumindest. Da ich es aber sowieso ähnlich handhabe, wie hier im Forum, also bereits vor dem Editierwunsch die Berechtigung darüber festlege, ergab sich die Frage bisher nicht. Bei Dateien habe ich mich auf LOCK_EX bisher verlassen, weil ich, muss ich fairerweise sagen, solche Anwendungen nicht multiuserfähig nutze, bzw, schon aber nur was die eigenen Profile etc. angeht, nicht aber multiuserzugriff auf gleiche Inhalte.
Daher erst mal danke, dass du mich jetzt ins Grübeln gebracht hast.
Gruss
Henry-
Tach!
Das Problem mit dem Lesezugriff entsteht aber auch bei SQL, glaube ich zumindest.
Prinzipiell ja, aber da sorgt der Server (oder die SQLite-API) dafür, dass nicht die gesamte Datei gesperrt werden muss, sondern lediglich die betroffenen Datensätze.
Es gibt aber auch Situationen, da helfen dir weder Transaktionen noch Dateisperren weiter. Nämlich dann, wenn zwischen Lesen und Schreiben die im Web üblichen Request-Response-Spielchen stattfinden. Solange kann man die Datei nicht für alle anderen sperren. Da muss man sich was anderes einfallen lassen, beispielsweise Optimistic Locking.
dedlfix.
-
-
-
Hallo @Henry,
- A liest die Datei (ohne zu sperren)
- B liest die Datei (selber Inhalt wie bei 1.)
- A schreibt Änderungen
- B schreibt Änderungen basierend auf Stand 2. Damit sind die Änderungen von 3. verloren.
A muss bei 1. den Lock setzen und B muss warten, bis A mit 3. fertig ist, bevor es 2. darf.
Ja aber dieses "muss warten" ist die Sache die noch nicht klar ist. "muss warten" im Sinne von "sieht solange nichts" oder im Sinne von "Speichern geht nicht"?
Wenn B nur etwas an die Datei anhängen möchte, wäre vielleicht warten im Sinne von Speichern wird blockiert OK, wenn zum Speichern der komplette Dateiinhalt neu geschrieben wird, muss B mit Lesen warten, bis A mit Schreiben fertig ist, damit B den aktuellen Dateiinhalt hat. Ansonsten überschreibt B die Änderungen von A.
Viele Grüße
Robert-
hallo
Ja aber dieses "muss warten" ist die Sache die noch nicht klar ist. "muss warten" im Sinne von "sieht solange nichts" oder im Sinne von "Speichern geht nicht"?
Ostersonntag am Gotthard
- A öffnet X
- B öffnet Y
- B will X öffnen, wartet
- A will Y öffnen, wartet
und ähnliche Situationen…
-
Hallo beatovich,
Ja aber dieses "muss warten" ist die Sache die noch nicht klar ist. "muss warten" im Sinne von "sieht solange nichts" oder im Sinne von "Speichern geht nicht"?
- A öffnet X
- B öffnet Y
- B will X öffnen, wartet
- A will Y öffnen, wartet
Also im Sinne von "sieht so lange nichts"? Klar, bei reinen editierbaren/administrativen Seiten geht das. Nicht aber wenn Content und Editiermöglichkeit zusammen vorhanden sind, wie hier im Forum oder CMS. Da muss dann sowieso noch eine Zwischenabfrage rein, oder sehe ich das falsch?
Gruss
Henry-
hallo
Hallo beatovich,
Ja aber dieses "muss warten" ist die Sache die noch nicht klar ist. "muss warten" im Sinne von "sieht solange nichts" oder im Sinne von "Speichern geht nicht"?
- A öffnet X
- B öffnet Y
- B will X öffnen, wartet
- A will Y öffnen, wartet
Also im Sinne von "sieht so lange nichts"? Klar, bei reinen editierbaren/administrativen Seiten geht das. Nicht aber wenn Content und Editiermöglichkeit zusammen vorhanden sind, wie hier im Forum oder CMS. Da muss dann sowieso noch eine Zwischenabfrage rein, oder sehe ich das falsch?
Der obige Gotthardstau liesse sich ja vermeiden durch ein Semaphore, oder wie das heisst. Das ist aber für Traffikseiten nicht ratsam. Es ist in diesem Forum ja nicht so, dass Texte immer wieder editiert werden. Es kommen praktisch nur neue hinzu. Und es kommt auch nicht vor dass zwei User den gleichen Text editieren, falls das geschieht.
-
Hallo beatovich,
Und es kommt auch nicht vor dass zwei User den gleichen Text editieren, falls das geschieht.
Aber es kommt vor, dass man seinen Post editieren möchte, aber nicht darf, weil bereits eine Antwort darauf erfolgte bzw. gerade erfolgt(bin nicht sicher, wie das hier gelöst wird)
Aber um nochmal auf den Kern zu kommen. Liegt Dedlfix richtig, wenn er vermutet, dass die Steuerung solcher Zugriffe durch SQL leichter zu bewerkstelligen wäre oder ist der Lesezugriff bei beiden Varianten der Flaschenhals?
Gruss
Henry-
hallo
Aber um nochmal auf den Kern zu kommen. Liegt Dedlfix richtig, wenn er vermutet, dass die Steuerung solcher Zugriffe durch SQL leichter zu bewerkstelligen wäre oder ist der Lesezugriff bei beiden Varianten der Flaschenhals?
Nicht der Lesezugriff, sondern das Lesen mit Schreibabsicht benötigt die Sperre. Ob du einen Flaschenhals generierst, hängt davon ab, ob du ganze Datenbank-Updates machst.
Natürlich sind Schreibsperren nur innerhalb eines Prozess-Zyklus aufrecht erhalten. Hierin liegt das Problem. Denn Lesen mit Absicht zum Schreiben erfolgt ja oft über mindestens 2 Zyklen.
Ich würde dedlfix recht geben, dass es leichter mit einer Datenbank ist, da diese ja mit Standard Abfrage-Methoden daherkommt und dir das grundsätzliche Locking abnimmt.
Selber habe ich keinen Datenverlust mehr mit Dateien erlebt, nachdem ich gelernt habe mit flock umzugehen (inklusive der Vermidung von Gotthardstaus). Aber anderseits hatte ich noch nie Traffic auf meinen Perlseiten.
Es gibt einen Aspekt, der eine Datenbank empfiehlt. Wenn du auf einem Multiusersystem Usern alle Arten von Content-Type-Erstellung erlauben willst, dann willst du keine physikalische Dateien haben.
-
Hallo beatovich,
Ich würde dedlfix recht geben, dass es leichter mit einer Datenbank ist, da diese ja mit Standard Abfrage-Methoden daherkommt und dir das grundsätzliche Locking abnimmt.
Wie denn genau? Ein praktisches Beispiel würde mich erhellen?
Bsp.
User A und User B => gleiche Seite gleichzeitig (read) (Inhalt durch zb. file_get_contens oder eben durch query select * from)
Dann wollen beide editieren. (Textfeld dafür bereits vorhanden? Mögliche Lösung: dann zb. Ajax request beim Tippen, zb einer tippt der andere dadurch blockiert) Aber das hat noch nichts mit der Auswahl der DB zu tun. hmm… Bei welchem konkreten Beispiel hierzu käme der Vorteil einer zb. Mysql zum Vorschein?
Gruss
Henry-
hallo
Wie denn genau? Ein praktisches Beispiel würde mich erhellen?
Ich kann, nachdem ich https://dev.mysql.com/doc/refman/5.7/en/internal-locking.html gelesen habe, vielleicht etwas schlaues dazu sagen. Für den Moment lasse ich es lieber und wünsche uns eine nette Lektüre.
-
Tach!
Ich würde dedlfix recht geben, dass es leichter mit einer Datenbank ist, da diese ja mit Standard Abfrage-Methoden daherkommt und dir das grundsätzliche Locking abnimmt.
Wie denn genau? Ein praktisches Beispiel würde mich erhellen?
Nehmen wir Inserts. Du brauchst bei der Datenbank kein Locking, um das anfangs dargestellte 4-Punkte-Szenario abzusichern. Du musst keine Sorge haben, dass jemand an die Stelle schreibt, an die du auch gerade schreiben wolltest oder deine Änderungen an der Datei überschreibt.
Update ist etwas komplexer, weil der Vorgang sich auf mehrere Requests aufteilt. Da hilft aber kein File-Lock sondern du muss anhand des Datensatzinhaltes feststellen, ob du schreiben möchtest oder nicht, weil sich der Timestamp oder die RowVersion zwischenzeitlich geändert hat. Du machst dann File-Locking zusätzlich zum Concurrency Locking aus Datensicht. Mit der Datenbank hast du zumindest bei Optimistic Locking nur ein Update WHERE RowVersion=alter_wert. Und während in Villarriba …
Und dann haben wir noch nicht mal über Transkationen gesprochen, um komplexe Szenarien mit Beteiligung von mehrern Tabellen so anzusichern, dass bei einem eventuellen Abbruch keine Inkonsistenzen zurückbleiben.
dedlfix.
-
Hallo dedlfix,
Nehmen wir Inserts. Du brauchst bei der Datenbank kein Locking, um das anfangs dargestellte 4-Punkte-Szenario abzusichern. Du musst keine Sorge haben, dass jemand an die Stelle schreibt, an die du auch gerade schreiben wolltest oder deine Änderungen an der Datei überschreibt.
Natürlich, aber wäre bei flatdb und LOCK_EX ja auch so, oder nicht?
Update ist etwas komplexer, weil der Vorgang sich auf mehrere Requests aufteilt. Da hilft aber kein File-Lock sondern du muss anhand des Datensatzinhaltes feststellen, ob du schreiben möchtest oder nicht, weil sich der Timestamp oder die RowVersion zwischenzeitlich geändert hat. Du machst dann File-Locking zusätzlich zum Concurrency Locking aus Datensicht. Mit der Datenbank hast du zumindest bei Optimistic Locking nur ein Update WHERE RowVersion=alter_wert. Und während in Villarriba …
Da wäre jetzt wieder ein reales Beispiel hilfreich, weil ich nicht erkenne, wie sich das für den blockierten User letztendlich anders auswirken soll.
Und dann haben wir noch nicht mal über Transkationen gesprochen, um komplexe Szenarien mit Beteiligung von mehrern Tabellen so anzusichern, dass bei einem eventuellen Abbruch keine Inkonsistenzen zurückbleiben.
Auch wenn voneinander abhängige Updates auf verschiedene Tabellen erfolgen, wie zb. Reservierungen/Überweisungen/etc…, sind bei Transaktionen alle Anweisungen als eine abzuhandeln, also blockiere alle oder führe alle aus. Da bei einer Flatdb der Schreibprozess ja auch geschützt ist, passiert das gleiche, oder? *edit Ah, stop, wenn es mehrere Textdateien als DB sind, sieht das natürlich anders aus. Ok, aber bei einer einzigen?
Gruss
Henry-
Tach!
Nehmen wir Inserts. Du brauchst bei der Datenbank kein Locking, um das anfangs dargestellte 4-Punkte-Szenario abzusichern. Du musst keine Sorge haben, dass jemand an die Stelle schreibt, an die du auch gerade schreiben wolltest oder deine Änderungen an der Datei überschreibt.
Natürlich, aber wäre bei flatdb und LOCK_EX ja auch so, oder nicht?
Vermutlich. Aber nicht vergessen und bei den anderen auch nicht. Übrigens auch im Administrationsmodus darfst du die Datei nicht offen lassen, ohne dass deine Anwendung stehenbleibt.
Update ist etwas komplexer, …
Da wäre jetzt wieder ein reales Beispiel hilfreich, weil ich nicht erkenne, wie sich das für den blockierten User letztendlich anders auswirken soll.
Ich kann dir zum Locking nicht mit Erfahrung dienen, weil ich mir das nicht angetan habe. Ich konzentriere mich lieber auf das was ich aus anwendungtechnischer Sicht tun muss. Und was für den restlichen reibungslosen Betrieb notwendig ist, kann ruhig das DBMS erledigen. Deshalb möchte ich mir auch grad keine Gedanken machen, wie ich das komplexe Szenario mit Flatfiles erledigen würde.
Und dann haben wir noch nicht mal über Transkationen gesprochen, um komplexe Szenarien mit Beteiligung von mehrern Tabellen so anzusichern, dass bei einem eventuellen Abbruch keine Inkonsistenzen zurückbleiben.
Auch wenn voneinander abhängige Updates auf verschiedene Tabellen erfolgen, wie zb. Reservierungen/Überweisungen/etc…, sind bei Transaktionen alle Anweisungen als eine abzuhandeln, also blockiere alle oder führe alle aus. Da bei einer Flatdb der Schreibprozess ja auch geschützt ist, passiert das gleiche, oder?
Wenn du mit mehreren Dateien arbeiten musst und sie sperren musst, kannst du in die Dead-Lock-Problematik geraten, wenn du die zweite Datei haben möchtest, die aber gerade gesperrt ist, weil der andere Prozess für seine Transaktion auf die Sperre für die erste wartet. Mit detaillierten Erfahrungen kann ich auch hier nicht dienen, weil ich nie die Notwendigkeit für Transaktionen hatte. Ich kann mir aber nicht vorstellen, dass das Abwickeln einer solchen mit Textdateien einfacher als ein COMMIT oder REVERT sein soll.
*edit Ah, stop, wenn es mehrere Textdateien als DB sind, sieht das natürlich anders aus. Ok, aber bei einer einzigen?
Für eine einzige wären nur die beiden ersten Szenarian zu beachten. Deine Transaktion findet dann zwischen dem Lock und dem Release statt.
dedlfix.
-
-
-
-
-
-
Hallo Robert,
muss B mit Lesen warten, bis A mit Schreiben fertig ist, damit B den aktuellen Dateiinhalt hat. Ansonsten überschreibt B die Änderungen von A.
Das ist genau die Frage. Sollte ich, wie ich das bei größeren (i.d.R. Mysql) Anwendungen mache, Zwischenabfragen einbringen? Bsp. A und B lesen gleichzeitig (geht ja auch nicht anders, kann ja nicht eine Seite blockieren, weil jemand stundenlang im Editor werkelt) B klickt Editorbutton, gleichzeitig erhält A, welcher danach auf Button klickt, die Ansage "Gerade im Gebrauch, bitte später versuchen". Oder habe ich es mir die ganzen Jahre bei SQL zu kompliziert und bei Textdateien zu leicht gemacht?
Gruss
Henry-
hallo
Das ist genau die Frage. Sollte ich, wie ich das bei größeren (i.d.R. Mysql) Anwendungen mache, Zwischenabfragen einbringen? Bsp. A und B lesen gleichzeitig (geht ja auch nicht anders, kann ja nicht eine Seite blockieren, weil jemand stundenlang im Editor werkelt) B klickt Editorbutton, gleichzeitig erhält A, welcher danach auf Button klickt, die Ansage "Gerade im Gebrauch, bitte später versuchen". Oder habe ich es mir die ganzen Jahre bei SQL zu kompliziert und bei Textdateien zu leicht gemacht?
Jemand der eine ganze Datei bearbeitet sollte aber in der Tat über eine Session allein Schreibrecht auf diese Datei haben. Deshalb sollte man ja Userdaten zwischen Usern möglichst physikalisch trennen.
-
Hallo @Henry,
muss B mit Lesen warten, bis A mit Schreiben fertig ist, damit B den aktuellen Dateiinhalt hat. Ansonsten überschreibt B die Änderungen von A.
Das ist genau die Frage. Sollte ich, wie ich das bei größeren (i.d.R. Mysql) Anwendungen mache, Zwischenabfragen einbringen? Bsp. A und B lesen gleichzeitig (geht ja auch nicht anders, kann ja nicht eine Seite blockieren, weil jemand stundenlang im Editor werkelt) B klickt Editorbutton, gleichzeitig erhält A, welcher danach auf Button klickt, die Ansage "Gerade im Gebrauch, bitte später versuchen". Oder habe ich es mir die ganzen Jahre bei SQL zu kompliziert und bei Textdateien zu leicht gemacht?
die große Frage ist doch ob du einen INSERT oder ein UPDATE machst. Parallele INSERTs sind für SQL kein Problem. Aber bei einem gleichzeitigen UPDATE auf einen Datensatz können Änderungen überschrieben werden.
Bei der Verwendung von Textdateien ist dann eben die Frage, ob du parallele INSERTs hinbekommst – ich weiß nicht, ob fopen mit dem Parameter a das leistet – oder ob es faktisch UPDATEs der Textdatei sind. In letzterem Fall ist es imho sinnlos schon paralleles Lesen zu erlauben.
Viele Grüße
Robert
-
-
-
-
-
-
-
Hallo ebody,
Wie man erkennt, kenne ich mich nicht so wirklich auf dem Gebiet aus und bitte um Verständnis, falls ich Blödsinn frage oder schreibe :-)
Daher wäre es gut zu wissen, welche Erfahrungen du bereits hast. Es gibt zwar auch hier ein Tutorial, fürchte aber, dass dieses dich überfordern könnte.
Diese Erfahrungen solltest du mitbringen oder dir aneignen. Kannst du natürlich auch simultan beim Erstellen des Loginsystems erlernen, aus meiner Erfahrung heraus scheint es aber besser dich mit kleinen Scripten den nachfolgenden Bereichen zu nähern.
- Sessions
- Textdateien erstellen/ändern/auslesen um als DB zu nutzen ( mysql kann später optional erlernt/genutzt werden.)
- Verschlüsselung
- php(die wichtigsten String/Array-Operationen) und html
Einfaches Lernbeispiel, erstelle mal bitte ein Adressbuch inkl. der Funktionen: hinzufügen, sortiert anzeigen, ändern, löschen. Wenn du das bereits hinbekommst, ist der Weg nicht mehr weit zum Loginscript.
Gruss
Henry -
Guck Dir mal Tacacs an. Evntl. auch Radius. Vielleicht ist das was für Dich.
MfG