Zuerst eine Datenbank (MySQL) oder Features implementieren?
Hallo,
ich arbeite gerade an einer Website, auf der man Schulfach, Note und Gewichtung eingeben kann. Die Website erstellt dann automatisch ein Diagramm aus den Noten und berechnet, welche Note erforderlich wäre, um positiv abzuschließen.
Jetzt frage ich mich, ob ich zuerst eine Datenbank einrichten sollte, um die Noten langfristig zu speichern. Ich habe noch keine Erfahrung mit MySQL, könnte aber theoretisch auch eine verschlüsselte JSON-Datei verwenden. Ich bin offen für Verbesserungsvorschläge. Alternativ überlege ich, zunächst alle gewünschten Features zu implementieren. Allerdings mache ich mir Sorgen, dass Funktionen wie „Noten löschen“ Probleme mit der Datenbank oder der JSON-Datei haben könnten.
Vielen Dank.
Liebe Grüße,
2 Antworten
Jetzt frage ich mich, ob ich zuerst eine Datenbank einrichten sollte (...)
Eine Datenbank klingt für dein Szenario erst einmal nicht verkehrt. Du kannst diese Wahl aber natürlich noch einmal überdenken, indem du verschiedene Speicheroptionen unter Berücksichtigung der Anforderungen, die du an deine Zielanwendung stellst, vergleichst.
Theoretisch könntest du die Noten eines Nutzers ebenso in einem Cookie oder dem Web Storage (im JSON-Format) speichern. Technisch wäre es wohl die einfachste und schnellste Lösung. Ausreichend Speicherplatz (~3-5 MB) dürfte gegeben sein.
Da lägen die Daten dann persistent so lange vor, bis der Nutzer sich einmal dazu entschließt, die Daten aus dem Browser zu löschen, was natürlich auch versehentlich passieren kann (bei Nutzern im Incognito-Modus wird der Local Storage beispielsweise automatisch mit Beenden der privaten Session geleert). Die Nutzung des Local Storage bedeutet auch, dass die Daten nicht einmal an den Server übermittelt werden. Das heißt, jegliche Funktionalität deiner Webseite, die sich auf die Noten bezieht, müsste mit JavaScript erfolgen.
Eine Singlefile-basierte Speicherung (CSV/JSON/XML/...) auf dem Server wiederum ist ausreichend, wenn du von vorhinein schon weißt, dass du ein geringes Nutzeraufkommen hast. Bei Schreibvorgängen solltest du die Datei erst für andere Schreibvorgänge explizit sperren (filelock), um einen konsistenten Datenstand gewährleisten zu können.
Datenbanken gewährleisten insgesamt mehr Flexibilität und Datensicherheit. Sie können eine Vielzahl an Daten sowie parallele Schreibvorgänge viel besser und eigenständig handhaben. Über ihr integriertes Rollensystem liefern sie des Weiteren schon eigene Sicherheitsmechanismen zur Absicherung der Daten. Der Ressourcenverbrauch beim Hosting ist dafür natürlich größer.
Alternativ überlege ich, zunächst alle gewünschten Features zu implementieren.
Das kannst du ruhig machen. Du musst nicht zwingend mit der Datenpersistierung beginnen, du kannst sie auch später noch hinzufügen. Nur die Entscheidung, wo du die Daten verarbeitest und speicherst (ob beim Nutzer im Browser oder auf dem Server), solltest du besser vor der Implementation der Features treffen.
Bau dir für den Anfang neben ein paar Modelklassen (die dein reines Datenmodell abbilden) einfach noch ein Interface in dem einfach nur die Methoden stehen, die du später zur Datenverwaltung benötigst (saveData, deleteData, o.ä.). So lange du die Persistierung noch nicht implementiert hast, setzt du stattdessen ein Dummyobjekt vom Typ dieses Interfaces ein, welches an den jeweiligen Stellen die entsprechenden Methoden aufruft, auch wenn die eben noch nichts wirklich tun.
Eine Singlefile-basierte Speicherung (CSV/JSON/XML/...) auf dem Server wiederum ist ausreichend, wenn du von vorhinein schon weißt, dass du ein geringes Nutzeraufkommen hast. Bei Schreibvorgängen solltest du die Datei erst für andere Schreibvorgänge explizit sperren (filelock), um einen konsistenten Datenstand gewährleisten zu können.
Gerade JSON und XML haben durch ihren strukturellen Aufbau das Problem, daß man sie weder fortschreiben noch gescheit inplace bearbeiten kann.
D.h. man muß neben Locking auch Maßnahmen für die Persistenz etc. ergreifen.
Tatsächlich wird momentan jede Funktionalität auf meiner Website in JavaScript umgesetzt, da ich nicht wusste (...)
Für die Berechnung und Visualisierung der Daten ist das kein Problem. Nur für einen Loginbereich sollte die gesamte Logik (Nutzer anlegen, Anmeldedaten oder Loginzustand prüfen, usw.) serverseitig ablaufen. Wenn das im Browser passiert, ist es einfach manipulierbar und somit ohne Nutzen.
Du kannst für die Implementation zwar weiterhin JavaScript einsetzen, doch dieser Anwendungsteil sollte dann auf Basis von Node.js (oder alternativ Bun/Deno - wie gesagt, hauptsache serverseitig) laufen. Du könntest dir mit ExpressJS recht schnell eine einfache Webanwendung zusammenbauen oder, falls du dich bereits mit React beschäftigt haben solltest, dich in NextJS einarbeiten und in Kombination mit NextAuth eine entsprechende Anwendung erstellen. Wenn du das anschließend auf einem öffentlichen Webserver hosten möchtest, müsstest du dich nach Hostinganbietern umschauen, die es dir erlauben, Node.js-Anwendungen (oder die genannten Alternativen) einzurichten.
Eine wohl noch einfachere Option gegenüber JavaScript bietet PHP. Die Sprache ist leicht erlernbar, hat passende Module/Funktionen für Hashing (password_hash, password_verify), CSV-Handling, DB-Handling (mysqli), etc. schon in seiner Standardbibliothek und einen passenden Webhostinganbieter (oft bereits das Paket Apache Server + MySQL-Server) findet man problemlos.
Mit Java (da es getaggt ist) kannst du ebenfalls arbeiten. Allerdings dürfte es meiner Einschätzung nach mehr Aufwand erfordern (Einarbeitung in ein Webframework, Hosting), als die bereits genannten Möglichkeiten. Für deine einfache Anwendung lohnt es sich sicherlich nicht.
Sollte es jedoch zu gleichzeitigen Schreibvorgängen kommen, müsste ich die Noten der Nutzer temporär cachen (...)?
Nein, nur wie gesagt die CSV-Datei sperren, sodass kein anderer Schreibprozess parallel ausgeführt werden kann. Wenn die Datei bereits von einem anderen Prozess blockiert wird, muss gewartet werden. Wie das Sperren von Dateien konkret umgesetzt werden kann (bzw. bestehenden Funktionen man dafür nutzen kann), hängt davon ab, mit welchen Tools (Programmiersprache, Bibliothek/Framework) du letzten Endes arbeitest.
Kann ich die Login-Daten ebenfalls in einer CSV-Datei speichern, (...)
Ja, allerdings solltest du hierbei ein paar Punkte berücksichtigen.
- Speichere nie Passwörter direkt (das gilt unabhängig davon, ob du mit einer Datenbank oder einer CSV-Datei arbeitest). Generiere zum Passwort stattdessen einen gesalzenen Hash (bspw. mit dem bcrypt-Algorithmus) und speichere den ab. Wenn ein Nutzer sich anmeldet, hashst du seine Passworteingabe und vergleichst sie mit dem gespeicherten Hash.
- Lege die Datei bestenfalls außerhalb des Rootverzeichnis deiner Webseite ab.
- Du kannst kaum ausschließen, dass Nutzer in ihrem Nutzernamen oder ihrem Passwort ein ungünstiges Sonderzeichen verwenden. Zum einen solltest du die Daten durchgängig unter einer stabilen Zeichenkodierung wie UTF-8 transportieren/speichern (das gilt ebenso bei Gebrauch einer Datenbank). Zum anderen könnte es natürlich den Fall geben, dass jemand zum Beispiel in seinem Nutzernamen das Trennzeichen verwendet, welches du für deine CSV-Datei nutzt. Entweder du verbietest die Nutzung dieses Trennzeichens oder du setzt die betroffenen Spaltenwerte in doppelte Anführungszeichen (wobei doppelte Anführungszeichen im Spaltenwert wiederum maskiert werden müssten; Bsp.: "Mein ""Spaltenwert"" mit Anführungszeichen").
Wenn du das anschließend auf einem öffentlichen Webserver hosten möchtest... --> Ich hoste alles selber, also besteht dieses Problem nicht.
Habe bereits meine Nextcloud mit Apache2 und MySQL bzw. MariaDB eingerichtet, kann ich also zwei Apache Dienste auf einem Server laufen lassen, oder gibt es da komplikationen?
Generiere zum Passwort stattdessen einen gesalzenen Hash --> Dies wäre ebenfalls meine Idee gewesen und damit habe ich bereits Erfahrungen in der Theorie dahinter.
Vielen Dank für deine ganzen Tipps. :)
Du kannst mehrere Webserver auf einer Plattform laufen lassen, aber nur einer kann auf Port 80 bzw. 443 lauschen. Derjenige muss dann auch die Anfragen von außen entsprechend auf die anderen Anwendungen verteilen.
Eventuell kannst du stattdessen Nextcloud um eine eigene, öffentliche Seite erweitern. Zumindest gibt es eine Schnittstelle, um (mit PHP) einen eigenen Controller für eigene Seiten anzulegen. An der Stelle könnte man auch gleich noch schauen, ob man für die Login-Logik nicht einfach das Nutzersystem von Nextcloud mit nutzen kann.
"Don't think in layers, think in slices"
Du kannst jedes kleine Feature als Fullstack-Entwicklung liefern.
Vielen Dank für deine ausführliche Antwort.
Du hast natürlich recht, dass die Speicherung von Daten in einer JSON-Datei lokal beim Nutzer, wie es in Cookies gemacht wird, keine optimale Lösung ist.
Das bedeutet, dass jede Funktionalität auf meiner Website, die sich mit Noten beschäftigt, mit JavaScript realisiert werden muss. --> Tatsächlich wird momentan jede Funktionalität auf meiner Website in JavaScript umgesetzt, da ich nicht wusste, wie ich diese Funktionen anders implementieren sollte. Meine Kenntnisse reichen von C bis hin zu eher rudimentärem Python. :)
Die Idee, CSV-Dateien zu verwenden, finde ich sehr gut. Da nur wenige Personen meine Website nutzen werden, scheint dies eine einfache Lösung zu sein. Sollte es jedoch zu gleichzeitigen Schreibvorgängen kommen, müsste ich die Noten der Nutzer temporär cachen, um komplikationen zu vermeiden, oder?
Kann ich die Login-Daten ebenfalls in einer CSV-Datei speichern, oder ist es notwendig, eine Datenbank zu verwenden, um diese sicher zu speichern?
Es wäre sinnvoll, die Entscheidung darüber, wo die Daten verarbeitet und gespeichert werden (ob im Browser des Nutzers oder auf dem Server), vor der Implementierung der Features zu treffen. --> Sollte sich herausstellen, dass das Speichern der Logindaten in einer separaten CSV-Datei machbar ist, werde ich diese Methode in Betracht ziehen.
Vielen lieben Dank nochmals für deine wertvollen Ratschläge. Ich werde definitiv einige davon nutzen!