Anfängerfrage zu Datenbanken

[Friedel]

Hallo,

ich bastle gerade eine Site, in der Mitfahrgelegenheiten zu Events organisiert werden sollen. Das ganze basiert auf Php und einer Datenbank.

Die Besucher können sich registrieren und registrierte User können sich einloggen. Dazu gibt es in der Datenbank die Tabelle "user". Bestimmte User haben das Sonderrecht, Events eintragen zu dürfen. Von den Events werden Anfangsdatum, Dauer (in Tagen), Ort, Titel, Längengrad, Breitengrad, Beschreibungstext und einige weitere Details in der Tabelle "events" gespeichert. Diese Events werden dann in einem Kalender oder auf einer Landkarte angezeigt. (Danke an Matthias Scharwies an dieser Stelle für seinen Einstieg in Leaflet.) Wenn ein User so ein Event anklickt, soll er eine Seite zu diesem Event angezeigt bekommen und ein Formular, in dem er Mitfahrgelegenheiten von einem Ort seiner Wahl zu diesem Event und/oder zurück anbieten oder suchen kann. Er kann dabei festlegen, ob seine Eintragung für alle sichtbar sein soll, nur für eingeloggte User, nur für User die auch zu diesem Event Mfg anbieten oder suchen. Seine Eintragung soll mit den Koordinaten seine Start-/Zielortes auch auf der Karte angezeigt werden.

Als SQL-Neuling habe ich zwar einige Ideen, wie ich das umsetzen kann, mir fällt aber schwer zu beurteilen, welche Möglichkeiten besser als andere sind.

• Ich könnte für jedes Event eine Tabelle in der Datenbank erzeugen, in der die Mfg gespeichert werden. Das werden mit der Zeit dann viele, viele Tabellen und für die Darstellung der Seiten muss Php für jede Seite auf 3 Tabellen zugreifen. Diese 3 Tabellen wären einigermaßen übersichtlich, die Gesamtzahl der Tabellen würde aber immer größer werden.
• Ich könnte auch in der Tabelle "users" für jedes Event je eine Spalte für die Schlüsselnummer der Events, Hinfahrtermin, Rückfahrtermin, Breitengrad, Längengrad, Anzahl der gesuchten Plätze, Anzahl der angebotenen Plätze usw anlegen. Die Zahl der Tabellen wäre also konstant bei 2, aber die Tabelle "users" würde sehr schnell wachsen und immer größer werden.
• Natürlich könnte man das entsprechend auch in der Tabelle "events" organisieren. Dort müsste dann natürlich für jeden User, der zu diesem Event will, die Schlüsselnummer des Users, Hinfahrtermin, Rückfahrtermin, Breitengrad, Längengrad, Anzahl der gesuchten Plätze, Anzahl der angebotenen Plätze usw gespeichert werden.

Ich tendiere sehr stark zur ersten Lösung, hauptsächlich weil die Tabellen dann relativ überschaubar bleiben. Aber ob das wirklich die Lösung ist, die die Datenbank und den Server am wenigsten belastet, kann ich nicht beurteilen. Dazu fehlt mir die Erfahrung und das Hintergrundwissen.

Vielleicht gibt es auch noch ganz andere Möglichkeiten, die viel besser sind. Ich bitte um Ratschläge.

[Matthias Apsel]

Hallo Friedel,

Für mich klingt das so: User und Event sind Entities, die Mitfahrgelegenheiten wären ein Relationship (m:n) zwischen User und Event. Also 3 Tabellen.

Erstelle dir auf einem Blatt Papier (oder mit einem Tool) ein Entity-Relationship-Modell.

Bis demnächst
Matthias

[klawischnigg]

Hi there,

Für mich klingt das so: User und Event sind Entities, die Mitfahrgelegenheiten wären ein Relationship (m:n) zwischen User und Event. Also 3 Tabellen.

Erstelle dir auf einem Blatt Papier (oder mit einem Tool) ein Entity-Relationship-Modell.

Das klingt in der Tat nach einem Super-Ratschlag für jemand, der sich selbst als "SQL-Neuling" bezeichnet...

[Friedel]

Für mich klingt das so: User und Event sind Entities, die Mitfahrgelegenheiten wären ein Relationship (m:n) zwischen User und Event. Also 3 Tabellen.

Erstelle dir auf einem Blatt Papier (oder mit einem Tool) ein Entity-Relationship-Modell.

Das ich keine Ahnung habe, was das Wort „Entities“ bedeuten könnte und mir auch Google und Wikipedia das nicht erklären konnten, kann ich auch nicht beurteilen, ob User und Event Entities sind. Dass man „Relationship (m:n)“ so gebrauchen kann, dass man damit diesen Sachverhalt beschreiben kann, kann ich mir vorstellen. Allerdings erkenne ich keinen Sinn darin. Entsprechend habe ich natürlich keine Idee, was ein „Entity-Relationship-Modell“ sein könnte und wozu es gut sein soll. Vielleicht habe das unbewusst schon erstellt, was du meinst. Aber nicht auf Papier. Wenn ich mehrdimensionale Datenbeziehungen in zweidimensionalen Tabellen darstellen will, muss ich die Projektion doch schon fertig haben, bevor ich das auf Papier bringen kann. Das Papier brauche ich dann nicht mehr.

Mit 3 Tabellen geht es natürlich auch. Aber die dritte, die dann die Mitfahrgelegenheiten speichern soll, wächst dann proportional zum Produkt von der Anzahl der User und der Events. Sie bekommt für jedes Event eine neue Zeile und für jeden User einen ganzen Satz von neuen Spalten. Die wird sehr schnell sehr groß

[klawischnigg]

Hi there,

Mit 3 Tabellen geht es natürlich auch. Aber die dritte, die dann die Mitfahrgelegenheiten speichern soll, wächst dann proportional zum Produkt von der Anzahl der User und der Events. Sie bekommt für jedes Event eine neue Zeile und für jeden User einen ganzen Satz von neuen Spalten.

Nein, eine Datenbank-Tabelle ist kein Excel-Spreadsheet. Mehrere Datensätze bedeuten nicht mehrere "Spalten" sondern werden alle, wenn sie zusammengehören, über einen gemeinsamen Schlüssel ebenfalls in "Zeilen" abgespeichert. Ich hab schon versucht, das in meinem anderen Posting anzudeuten: wenn es keinen sehr trifftigen Grund dafür gibt (irgendwelche Spezialfälle mag es immer geben) dann bedeutet in einer DB mehr Daten ist gleich mehr Zeilen, niemals mehr Spalten...

[Friedel]

Der Nachteil bei solchen Foren mit Baumstruktur ist, dass sich Threads aufteilen können, aber es fehlt die Möglichkeit sie wieder zu vereinen. In diesem kommen offensichtlich beide Zweige zum selben Ergebnis. 😉

[Matthias Apsel]

Hallo Friedel,

Entsprechend habe ich natürlich keine Idee, was ein „Entity-Relationship-Modell“ sein könnte und wozu es gut sein soll.

Aber das kann man tatsächlich mit der Suchmaschine seiner Wahl suchen.

Wenn ich mehrdimensionale Datenbeziehungen in zweidimensionalen Tabellen darstellen will, muss ich die Projektion doch schon fertig haben, bevor ich das auf Papier bringen kann. Das Papier brauche ich dann nicht mehr.

Eine vernünftige Modellierung der Datenbank ist unabdingbare Voraussetzung für den Start eines solchen Projektes. Es werden andere Anforderungen hinzukommen (sich wiederholende Events, Benutzergruppen und deren Berechtigungen ...)

@Felix Riesterer hatte mal einen Entwurf, wie man Datenbanken mit PHP bearbeiten im Wiki, aber den Artikel finde ich grade nicht. Kannst du dich besser erinnern, @Matthias Scharwies?

Bis demnächst
Matthias

[Matthias Scharwies]

Servus!

Hallo Friedel,

Entsprechend habe ich natürlich keine Idee, was ein „Entity-Relationship-Modell“ sein könnte und wozu es gut sein soll.

Aber das kann man tatsächlich mit der Suchmaschine seiner Wahl suchen.

Wenn ich mehrdimensionale Datenbeziehungen in zweidimensionalen Tabellen darstellen will, muss ich die Projektion doch schon fertig haben, bevor ich das auf Papier bringen kann. Das Papier brauche ich dann nicht mehr.

Eine vernünftige Modellierung der Datenbank ist unabdingbare Voraussetzung für den Start eines solchen Projektes. Es werden andere Anforderungen hinzukommen (sich wiederholende Events, Benutzergruppen und deren Berechtigungen ...)

@Felix Riesterer hatte mal einen Entwurf, wie man Datenbanken mit PHP bearbeiten im Wiki, aber den Artikel finde ich grade nicht. Kannst du dich besser erinnern, @Matthias Scharwies?

• PHP/Tutorials/Datenbanken_mit_PHP

vorher vielleicht: PHP/Tutorials/Datenspeicherung?

Bis demnächst
Matthias

Herzliche Grüße

Matthias Scharwies

[klawischnigg]

Hi there,

Ich tendiere sehr stark zur ersten Lösung, hauptsächlich weil die Tabellen dann relativ überschaubar bleiben.

Prinzipiell nein. Auch zur zweiten Lösung. Es ist eine ganz schlechte Idee, die Struktur einer Datenbank in Abhängigkeit der anlaufenden Daten zu verändern. Die Struktur einer DB soll der Organisation der Daten dienen, nicht von den Daten oder deren Umfang/Menge abhängen.

Aber ob das wirklich die Lösung ist, die die Datenbank und den Server am wenigsten belastet, kann ich nicht beurteilen.

Das kannst Du vergessen, solche Gedanken hätten vielleicht vor 35 Jahren einen Sinn gemacht. Nicht falsch verstehen, aber bei so einer Pipsi-Anwendung wie der von Dir Beschriebenen darf der Ressourcen-Monitor eines Rechners, auf dem die DB läuft, nicht einmal kurz aufzucken…

Vielleicht gibt es auch noch ganz andere Möglichkeiten, die viel besser sind. Ich bitte um Ratschläge.

Naja, Du hast User, du hast Events und die werden am besten über eine dritte Tabelle, in der die Mitfahrwünsche deponiert und verwaltet werden verbunden. Das wäre imho besser, als in eine Events-Tabelle Userwünsche/Userdaten einzutragen, wie Du als Lösung drei vorgeschlagen hast, wenn ich Dich richtig verstanden habe...

[Friedel]

Naja, Du hast User, du hast Events und die werden am besten über eine dritte Tabelle, in der die Mitfahrwünsche deponiert und verwaltet werden verbunden. Das wäre imho besser, als in eine Events-Tabelle Userwünsche/Userdaten einzutragen, wie Du als Lösung drei vorgeschlagen hast, wenn ich Dich richtig verstanden habe...

Ahh… Auf die Idee bin ich beim Beitrag von Mathias noch nicht gekommen. Das erscheint mir sinnvoll. Die dritte Tabelle enthält für jedes Mfg-Angebot bzw. -Gesuch eine Zeile mit der Event-ID, der User-ID und dem Datensatz zu dieser Mfg.

Jetzt ist mir nur noch nicht klar, warum ich auf diese naheliegende Lösung nicht selbst gekommen bin. Danke.

[klawischnigg]

Hi there,

Naja, Du hast User, du hast Events und die werden am besten über eine dritte Tabelle, in der die Mitfahrwünsche deponiert und verwaltet werden verbunden. Das wäre imho besser, als in eine Events-Tabelle Userwünsche/Userdaten einzutragen, wie Du als Lösung drei vorgeschlagen hast, wenn ich Dich richtig verstanden habe...

Ahh… Auf die Idee bin ich beim Beitrag von Mathias noch nicht gekommen. Das erscheint mir sinnvoll. Die dritte Tabelle enthält für jedes Mfg-Angebot bzw. -Gesuch eine Zeile mit der Event-ID, der User-ID und dem Datensatz zu dieser Mfg.

Jetzt ist mir nur noch nicht klar, warum ich auf diese naheliegende Lösung nicht selbst gekommen bin. Danke.

Mein Gott, er hat es, es grünt so grün...;)

[Matthias Apsel]

Hallo klawischnigg,

Das kannst Du vergessen, solche Gedanken hätten vielleicht vor 35 Jahren einen Sinn gemacht. Nicht falsch verstehen, aber bei so einer Pipsi-Anwendung wie der von Dir Beschriebenen darf der Ressourcen-Monitor eines Rechners, auf dem die DB läuft, nicht einmal kurz aufzucken…

Naja, wenn ich an Veranstaltungen wie W:O:A denke und Umkreisberechnungen für die Mitfahrgelegenheiten in der Nähe, …

Bis demnächst
Matthias

[Rolf B]

Hallo Friedel,

eine Warnung vom alten Mann.

So eine Anwendung ist vielleicht "Pipsi", aber man muss sie erstmal bauen, sie muss halbwegs hackerfest sein, damit sie kein Hackerfest wird, sie muss betrieben werden (d.h. da muss ein Server sein), das macht Arbeit und kostet Geld. Und das schlimmste, was Dir damit passieren kann, ist Erfolg. Du designst und baust die Seite - ohne Ahnung von Datenbanken, wie Du selbst sagst. In diesem Fall wird es ein großer Zufall sein (oder Du bist ein Genie), wenn deine Anwendung auch lastfest ist.

Das schlimmste, was Erstlingsanwendungen passieren kann, ist Erfolg. Stell Dir vor, Du hast auf einmal 1000 oder mehr User, weil das Ding kostenlos ist, gut funktioniet und sich herumspricht. In dem Moment wird aus dem Pipsi ein Ächzi, weil jetzt jeder Designfehler die Anwendung in die Knie bringen kann. Eventuell produzierst Du auch Datenfehler, weil Du auf einmal Parallelzugriffe hast, die Du vorher nie getestet hast. Jetzt musst Du in der ohnehin schon dampfende Datenbank kaputte Daten reparieren, vielleicht ist sie total hinüber und Du musst die Seite stoppen, um ein Backup einzuspielen, und parallel dazu musst Du im Shitstorm der Nutzer die lastoptimierte Version 2.0 erzeugen. Oder aufgeben. Das ist kein Spaß mehr.

Deshalb habe ich mal in der allwissenden Müllhalde gestöbert, und mein erster Suchtreffer war yeswego, die den von dir geplanten Service entgeltlich anzubieten scheinen. Nicht billig, sieben grüne Scheinchen im Jahr, und damit für Dich vielleicht zu teuer und zu umfangreich.

Hast Du Dich selbst schon nach Onlineverwaltungen für Mitfahrgelegenheiten umgeschaut? Selber bauen kann interessant und lehrreich sein. Wenn man das Projekt als Weg zur eigenen Weiterentwicklung sieht, ist es auch eine sinnvolle Sache.

Aber wenn es Dir vorrangig um die Nutzung einer solchen Anwendung geht, und nicht um den Spaß am Realisierungsprojekt, solltest Du auf jeden Fall erstmal schauen, was es da draußen bereits gibt.

Rolf

[Friedel]

eine Warnung vom alten Mann.

Vergiss es. Wenn ich damals, als ich den ersten Z1 für Zuse handgeschmiedet habe, auf die alten Männer gehört hätte, gäbe es gar keine Computer.

So eine Anwendung ist vielleicht "Pipsi", aber man muss sie erstmal bauen, sie muss halbwegs hackerfest sein, damit sie kein Hackerfest wird, sie muss betrieben werden (d.h. da muss ein Server sein), das macht Arbeit und kostet Geld. Und das schlimmste, was Dir damit passieren kann, ist Erfolg. Du designst und baust die Seite - ohne Ahnung von Datenbanken, wie Du selbst sagst. In diesem Fall wird es ein großer Zufall sein (oder Du bist ein Genie), wenn deine Anwendung auch lastfest ist.

Die Anwendung ist zunächst für den Verein Mehr Demokratie e.V. und seine Veranstaltungen gedacht. Erfahrungsgemäß kommen zu den Bundesmitgliederversammlungen meist etwa 50 Personen, zu den Landesversammlungen weniger. Ein großer Erfolg wären also 30 User für eine Event, ingesamt vielleicht maximal 100. Aber mit so viel rechne ich nicht. Das wäre also der maximal mögliche Erfolg. Und wenn die Anwendung diese Least nicht verkraftet, habe ich Mist gebaut. Beim Z1 hat's ja auch nicht beim ersten Mal geklappt.

Das schlimmste, was Erstlingsanwendungen passieren kann, ist Erfolg. Stell Dir vor, Du hast auf einmal 1000 oder mehr User, weil das Ding kostenlos ist, gut funktioniet und sich herumspricht. In dem Moment wird aus dem Pipsi ein Ächzi, weil jetzt jeder Designfehler die Anwendung in die Knie bringen kann. Eventuell produzierst Du auch Datenfehler, weil Du auf einmal Parallelzugriffe hast, die Du vorher nie getestet hast. Jetzt musst Du in der ohnehin schon dampfende Datenbank kaputte Daten reparieren, vielleicht ist sie total hinüber und Du musst die Seite stoppen, um ein Backup einzuspielen, und parallel dazu musst Du im Shitstorm der Nutzer die lastoptimierte Version 2.0 erzeugen. Oder aufgeben. Das ist kein Spaß mehr.

Das wäre natürlich toll. Dazu müsste sich die Zahl der Mitglieder vervielfachen, und das ist durchaus gewollt.

Deshalb habe ich mal in der allwissenden Müllhalde gestöbert, und mein erster Suchtreffer war yeswego, die den von dir geplanten Service entgeltlich anzubieten scheinen. Nicht billig, sieben grüne Scheinchen im Jahr, und damit für Dich vielleicht zu teuer und zu umfangreich.

Hast Du Dich selbst schon nach Onlineverwaltungen für Mitfahrgelegenheiten umgeschaut?

Habe ich. Ausgiebig. Das war der Anlass für dieses Projekt. Angebote, die Daten unsrer Mitglieder an Fremde weiter zu geben und dafür dann auch noch Geld zu bezahlen, möchte und darf ich nicht benutzen.

Selber bauen kann interessant und lehrreich sein. Wenn man das Projekt als Weg zur eigenen Weiterentwicklung sieht, ist es auch eine sinnvolle Sache.

Aber wenn es Dir vorrangig um die Nutzung einer solchen Anwendung geht, und nicht um den Spaß am Realisierungsprojekt, solltest Du auf jeden Fall erstmal schauen, was es da draußen bereits gibt.

Das ist Sinn der Sache. So ist vor inzwischen mehr als 20 Jahren meine erste Homepage entstanden, weil ich mich erst aus dem mich-Seiten-Generator von Ebay und dann aus Frontpage befreit habe. Ich muss zwar in Vollzeit arbeiten, habe eine Frau und 4 Kinder, renoviere nebenbei ein Haus und bin in einer Partei und einem Verein aktiv und habe bei beiden auch noch das Amt des Schatzmeisters, aber etwas Zeit für ein Hobby bleibt doch noch. Nur diese Bedingungen ermöglichen es mir übrigens, die Seiten gut zu machen. Ich muss nicht morgen oder nächste Woche fertig sein. Wenn ich in 4 Wochen sage, das Projekt ist einsatzbereit, dann setze ich es 4 Wochen zu,m ersten mal ein. Wenn ich das selbe erst 2034 im Januar sage, setze ich es dann zum ersten Mal ein.

[Rolf B]

Hallo Friedel,

eine Warnung vom alten Mann. Vergiss es. Wenn ich damals ... auf die alten Männer gehört hätte,

So war's ja auch gemeint 😉. Alte Männer neigen zu Aussagen wie "Aus meiner langen Erfahrung heraus…". Ich wollte Dich dennoch davor warnen, das Projekt zu unterschätzen.

als ich den ersten Z1 handgeschmiedet

Da warst Du mutmaßlich nicht jünger als 15. 1937-15=2022. Grats zum 98. Geburtstag 😄

Wenn ich in 4 Wochen sage

*hust* - in 4 Wochen sagst Du nur was, wenn Du sowas schon jahrelang machst. Bei dem von Dir genannten Zeitbudget wirst Du Frustresistenz brauchen, und ein gutes Vorbild^[1]. Unser Wiki scheint keine Artikel über Datenmodellierung zu haben, aber wenn ich so rumgoogle, scheint es einiges an Tutorials dazu zu geben.

Und dieser Satz:

Wenn ich mehrdimensionale Datenbeziehungen in zweidimensionalen Tabellen darstellen will, muss ich die Projektion doch schon fertig haben, bevor ich das auf Papier bringen kann.

ist einfach irrig. Man kann auch mit Tools modellieren. Die muss man dann beschaffen, kennenlernen, etc, geht alles, aber um die ersten Gedanken zu sammeln, ist Stift und Papier immer noch erste Wahl. Wenn Du anfängst, CREATE TABLE Befehle zu schreiben, sollte das Konzept das erste Mal durchdacht sein. Und wenn das Konzept zu überarbeiten ist, ist eine gute Visualisierung ebenfalls hilfreich. Der Schmied nimmt ja auch nicht einfach einen Eisenklotz und hämmert einen Zaun daraus. Da wird sicher auch erstmal gezeichnet. Und Webschmiede machen das bestimmt nicht anders.

Wenn Du mit dem Gedanken gespielt hast, für neue Events jeweils neue Tabellen anzulegen, hast Du definitiv Grundlagenbedarf. Und sicher weißt Du auch von der Z1 her noch, dass man vorher nie weiß, welchen Komplexitäten man auf dem Weg begegnet und dass er meistens länger ist, als man vorher gedacht hat.

Rolf

---

1. https://www.youtube.com/watch?v=o9Gf3qFwHh8 ↩︎