Datenbankdesign - Fragen & Hilfe!

[THE_fan]

Hallo zusammen!

Bin (noch immer) dabei eine neue Homepage für unsre Feuerwehr zu programmieren.
Jetzt habe ich mir mal Gedanken über das komplette Datenbankdesign gemacht. Irgendwie sieht das doch alles sehr nach Anfänger aus. Ehrlich gesagt fühle ich mich auch nicht weiter, es soll jedoch alles soweit den Standards entsprechen, performant sein und mir die Wartung vereinfachen.

Ich wäre echt dankbar, wenn mir der ein oder andere von euch etwas helfen könnte..

Mir geht es vorerst um die Seite mit den Einsatzberichten.

Die Datenbank sieht im Moment so aus:

id [int(40)]
stichwort [varchar(30)]
alarm [varchar(5)]
ende [varchar(5)]
tlf [int(1)]
tsfw [int(1)]
mtf [int(1)]
reserve [int(2)]
datum [int(11)]
icon [int(2)]
intro [text]
text [text]
gesamt [int(2)]

id = id des Eintrages
stichwort = Stichwort des Einsatzes
alarm = Zeit der ALarmierung (z.b. 12:30)
ende = Ende des Einsatzes (z.b. 13:30)
tlf, tsfw, mtf = Besatzung der Fahrzeuge (Anzahl Personen)
reserve = Reserve auf der Wache
datum = Datum des Einsatzes (time() z.b. 1270645655 (eigentlich blöd, da ich auch rückwirkend Einsätze eintragen muss))
icon = ein Icon, das bei der Ausgabe auf der Homepage dem Einsatz zugeordnet wird - 1, 2 oder 3
intro = Einleitung zum Einsatz
text = der eigentliche Bericht OHNE Fotos (bisher nicht geplant)
gesamt = Gesamtanzahl der Personen im Einsatz (kann eigtl. weg, kann man ja berechnen!)



Jetzt die Frage: Wie kann man das verbessern?
*gesamt kann man ja schon löschen

Wie mache ich das am besten mit den Daten? Ich habe mir vorgestellt, dass ich Dropdowns mache, die Datum und Uhrzeit beinhalten (natürlich nach Tag / Monat / Jahr / Stunde / Minute geteilt).. Allerdings weiß ich nicht, wie ich die dann am besten speichere.

Wäre nett, wenn mir jemand helfen könnte.

Danke vorab.
Stefan

 

[NetAktiv]

Ehrlich gesagt must dir bei einer Datenbank mit einer Tabelle, die keine 30 Felder hat, normal gar keine Gedanken machen, höchstens später mal über das Erstellen von Indizes, falls Abfragen langsam werden. Wichtig ist doch nur, dass die Felder deine geforderten Inhalte speichern und keine Daten doppelt gespeichert werden.

Speichern solltest in der Form, dass deine Abfragen dann wieder einfach werden und du nicht eventuell mit SELECT substring(...) where arbeiten musst. Für solche Zwecke wäre auch eine Duplizierung der Daten denkbar, wenn du also beispielsweise den Starttermin (Datum+Uhrzeit) als auch die Dauer (von x by y uhr) brauchen würdest.

 

[sysop]

So auf den ersten Blick, würde ich für alarm und ende einen timestamp wählen,
id unsigned, dann kann die id kleiner werden (40 stellen, wieviele Einsätze erwartest du:mrgreen: ) eventuel ein autowert.
Datum kann ein Datum werden oder auch ein timestamp (ja, ich liebe timestamps, weil man daraus nahezu alles generieren kann).

Für timestamps wähle ich persönlich immer eine int mit 15 Stellen, dann kann man noch was reinrechnen (10 Stellen würden aber reichen).

 

[vitus37]

Hallo Stefan,

ich sage einfach mal etwas zu den einzelnen Tabellenfeldern, wie du sie momentan hast.

id:
Jeder Zeile eine Identifikationsnummer zu geben, ist natürlich eine gute Sache, da man so deutlich einfacher und performater auf einzelne Datensätze zugreifen kann. Vergiss nicht dieser Spalte den Primärschlüssel zuzuordnen. Was ich etwas krass finde, ist die Länge des Feldes von 40 Stellen. Ich denke eure Feuerwehr wird im Verlauf seiner gesamten Existenz niemals eine Anzahl von 10^40 Einsatzberichten geschrieben haben. Eine Länge von 5 oder 6 sollte leicht reichen.

stichwort:
Passt. Ich nehme an, es soll sich immer nur um ein Stichwort handeln?

alarm & ende:
Für diese beiden Felder hast du den Datentyp VARCHAR mit einer Länge von 5 ausgewählt. Für Zeiten und Daten gibt es in MySQL (ich nehme an du verwendest MySQL für dein Vorhaben) gesonderte Datentypen: DATE, TIMESTAMP und DATETIME. Siehe MySQL :: MySQL 5.5 Reference Manual :: 10.3.1 The DATETIME, DATE, and TIMESTAMP Types. Ich halte es in deinem Fall für sinnvoll, für alarm als auch ende den Typ DATETIME zu wählen, da hier recht simpel Datum und Uhrzeit in nur einem Feld gesichert werden können.
Bei deiner momentanen Lösung mit den Feldern alarm, ende und datum hättest du zudem ein Problem, wenn ein Einsatz durch die Nacht von spät abends bis zum nächsten morgen dauert. Dem entgehst du mit einem Startdatum & Startuhrzeit und Enddatum & Enduhrzeit.

[Einsatzfahrzeuge]:
Hier ist deine aktuelle Lösung etwas unflexibel. Was wenn ein Fahrzeug hinzu kommt? Was wenn eines verkauft wird? Was wenn ein Fahrzeug im Einsatz garnicht benötigt wird - es würde dennoch Speicher in der Datenbank belegt werden?
Hier solltest du eine zweite Tabelle anlegen, etwa „fahrzeuge“, in welcher die Einsatzfahrzeuge stehen. Die Idee ist es nun beide Tabellen, also „einsaetze“ und „fahrzeuge“ miteinander zu verknüpfen. In diesem Fall besteht eine sog. m:n-Beziehung, sprich ein Fahrzeug kann bei mehreren (variabel vielen) Einsätzen dabei sein, andererseits kann ein Einsatz auch mit mehreren (variabel vielen) Fahrzeugen statt gefunden haben. Um diese nun zu verknüpfen, wird noch eine dritte Tabelle benötigt, die eigentliche Relation. Ich nenne sie mal „fahrzeug_bei_einsatz„. Sie hat die Spalten einsatz_id, fahrzeug_id und besatzungszahl. Durch sog. JOINS kannst du eine SQL-Abfrage so gestalten, dass die Ergebnistabelle aus den drei Quelltabellen zusammengebaut wird. Siehe MySQL :: MySQL 5.0 Reference Manual :: 12.2.8.1 JOIN Syntax.

reserve:
Ich denke hiermit ist die Reservezahl an Feuerwehrleuten auf der Wache gemeint? Wenn ja, dann sürfte das so passen.

datum:
Würde durch DATETIME-Felder bei alarm und ende entfallen.

icon:
Ist in Ordnung. Die Länge von 1 würde auch reichen, da du nur drei einstellige Zahlen hast.

intro:
Hier würde ich vermutlich ein längeres VARCHAR-Feld einsetzen, ist allerdings letztlich egal. Ich weiß auch nicht wie lange eure Einleitungen sind.

text:
Passt.

gesamt:
Hier würde eine Redundanz entstehen, da - wie du schon richtig erkanntest - die Gesamtpersonenzahl auch errechenbar ist. In diesem Zusammenhang wäre SUM() vermutlich recht interessant, weil es die Zahlen einer Spalte zusammenrechnen kann (hier die Spalte besatzungszahl von „fahrzeug_bei_einsatz“). Siehe MySQL :: MySQL 5.5 Reference Manual :: 11.16.1 GROUP BY (Aggregate) Functions.

Ich würde folglich ein Datenbankschema in diesem Stil aufbauen:

fahrzeuge
----------------
id int(2) PRIMARY
bezeichner varchar(10)
besatzungskapazitaet int(2)
...
...

fahrzeug_bei_einsatz
----------------
fahrzeug_id int(2)
einsatz_id int(5)
besatzungszahl int(2)

einsaetze
----------------
id in(5)
stichwort varchar(30)
alarm datetime
ende datetime
reserve int(2)
icon int(1)
intro varchar(255)
text text

Zu deiner Frage, wie man die Daten und Zeiten am besten entgegen nimmt:
Der Datentyp DATETIME akzeptiert Daten im Format 'jjjj-mm-tt hh:mm:ss'. Du kannst also die Formulardaten validieren und daraus eine Zeichenkette in gezeigtem Format zusammenbauen. Vergiss nicht die führenden Nullen. So lassen sich Daten und Zeit in Datenbanken einfügen.
Beim Auslesen kannst du die Daten übrigens auch anders formatieren, etwa zu '1. Dez 2011 um 16:30Uhr'.

Grüße
Vitus

P.S. Alle von mir verlinkten Seiten lassen sich natürlich auch auf Deutsch finden. Google.

 

[mermshaus]

INT(n) ← Die Zahl in Klammern hat nichts mit dem speicherbaren Wertebereich zu tun.

Numeric Type Attributes

MySQL supports an extension for optionally specifying the display width of integer data types in parentheses following the base keyword for the type. For example, INT(4) specifies an INT with a display width of four digits. This optional display width may be used by applications to display integer values having a width less than the width specified for the column by left-padding them with spaces. (That is, this width is present in the metadata returned with result sets. Whether it is used or not is up to the application.)

The display width does not constrain the range of values that can be stored in the column. Nor does it prevent values wider than the column display width from being displayed correctly. For example, a column specified as SMALLINT(3) has the usual SMALLINT range of -32768 to 32767, and values outside the range permitted by three digits are displayed in full using more than three digits.

- MySQL :: MySQL 5.6 Reference Manual :: 10.2 Numeric Types

Zusammengefasst: Ein INT(1) speichert denselben Wertebereich wie ein INT(20). Die längste Zahl, die in einer INT-Spalte gespeichert werden kann, hat übrigens eine Länge von 10 Ziffern.

Ich habe keine Ahnung, was das soll.


TIMESTAMP:

The TIMESTAMP data type has a range of '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC.

Das ist ein vorzeichenbehafteter Integer.

- MySQL :: MySQL 5.6 Reference Manual :: 10.3.1 The DATETIME, DATE, and TIMESTAMP Types

Es kann aber realistisch wohl davon ausgegangen werden, dass die Beschränkung bis 2038 aufgehoben werden wird, der Datentyp also erweitert wird.


Die DATE-Datentypen beginnen am 1. Januar 1000 und enden am 31. Dezember 9999.


Wichtig ist bei Zeit-Datentypen, dass die DATE*-/TIME-Varianten ohne Zeitzone abgelegt werden. Das bedeutet: Einem entsprechenden Feld kann nicht angesehen werden, ob es deutsche Winterzeit oder mexikanische Sommerzeit (falls es die gibt) enthält. Ich empfehle daher dringend, alle Daten in UTC umzurechnen und erst dann in die DB zu schreiben.

TIMESTAMPs sind als UTC definiert.

- Koordinierte Weltzeit

 

[struppi]

Gibt es in den Einsatzberichten keine Information darüber welche Fahrzeuge eingesetzt wurden?

 

[THE_fan]

Hallo zusammen,

wow, das hilft mir schon mal echt weiter! Vielen Dank euch!

Bei der id habe ich mich verschrieben, da steht nur eine 4, nicht 40, drin.
Ebenso hat id natürlich primary key und auto increment.

Dann scheint es mir, als wäre ich im Großen und Ganzen also schon auf einem guten Weg gewesen. Das beruhigt mich :)

Ich habe allerdings noch eine Frage zu den Datumsformaten alarm & ende.

Mal angenommen, wir haben heute einen Einsatz und ich trage den aber erst übermorgen in die Homepage ein.. Ich verstehe jetzt nicht, wie das funktionieren soll.
Mit einer PHP-Funktion (timestamp()) hole ich mir doch immer die aktuelle Zeit. Deshalb war es meine Überlegung, dass ich durch Dropdown-Felder Datum und Uhrzeit in die Datenbank schreibe und es dann genau so wieder auslese.. Ich hoffe ihr versteht was ich meine.. Ich wüsste nicht, wie ich ohne große Rechnerei übermorgen das Datum von vorgestern (resp. heute) eintragen sollte.. Bestimmt habt ihr da noch eine Idee (wober das dann eher ins PHP-Forum gehören würde, denke ich).
Man muss dazu sagen, dass ich bisher nur Uhrzeiten im Format (hh:mm) in die Datenbank schreibe.


@struppi
Die Fahrzeuge und Besatzung extra aufzuführen hat den Sinn, dass man daraus am Ende des Jahres eine Statistik ableiten kann.

@vitus
Ich muss dann also jeden Einsatzbericht mit der Fahrzeuge-Tabelle verknüpfen, verstehe ich das richtig?
Der Gedanke mit dem Hinzukommen von neuen Fahrzeugen ist natürlich äußerst relevant.. Da sollte ich mir noch mal ein paar Gedanken zu machen!


Danke vorab an alle.

Gruß
Stefan

 

[struppi]

Mit einer PHP-Funktion (timestamp()) hole ich mir doch immer die aktuelle Zeit. Deshalb war es meine Überlegung, dass ich durch Dropdown-Felder Datum und Uhrzeit in die Datenbank schreibe und es dann genau so wieder auslese.. Ich hoffe ihr versteht was ich meine.. Ich wüsste nicht, wie ich ohne große Rechnerei übermorgen das Datum von vorgestern (resp. heute) eintragen sollte.. Bestimmt habt ihr da noch eine Idee (wober das dann eher ins PHP-Forum gehören würde, denke ich).
Man muss dazu sagen, dass ich bisher nur Uhrzeiten im Format (hh:mm) in die Datenbank schreibe.

Schau dir mal den Link zu den Datumsfunktionen von mySQL an. Du kannst mit Date, DateTime und Timestamp jede Berechnung machen, die mit einem Datum möglich ist. Also sowas in der Art: "hole alle Einträge älter als ein Jahr" oder "alle Enträge der letzten zwei Tage". Du musst keinerlei Datumsberechnung auf dem Server machen, das macht die Datenbank.

@struppi
Die Fahrzeuge und Besatzung extra aufzuführen hat den Sinn, dass man daraus am Ende des Jahres eine Statistik ableiten kann.

@vitus
Ich muss dann also jeden Einsatzbericht mit der Fahrzeuge-Tabelle verknüpfen, verstehe ich das richtig?
Der Gedanke mit dem Hinzukommen von neuen Fahrzeugen ist natürlich äußerst relevant.. Da sollte ich mir noch mal ein paar Gedanken zu machen!

Ja, üblicherweise kommt dann eine Tabelle hinzu, in deinem Beispiel mit den Einsatzfahrzeugen, diese werden dann verknüpft mit der Einsatztabelle, da würde dann auch die Informationen der Personenanzahl hineinkommen, wenn man mal davon ausgeht, dass keiner zu Fuß zum Einsatz geht ;)

Wobei das aber ein relativ komplexes Thema wird. Das Stichwort lautet: join

 

[mermshaus]

Mit einer PHP-Funktion (timestamp()) hole ich mir doch immer die aktuelle Zeit.

Du meinst vermutlich time().

Ich wüsste nicht, wie ich ohne große Rechnerei übermorgen das Datum von vorgestern (resp. heute) eintragen sollte..

Wenn du es unbedingt als Timestamp willst:

<?php

$timestamp = strtotime('2011-10-16 12:00:00');

var_dump(
    $timestamp,
    date('Y-m-d H:i:s', $timestamp)
);

Ansonsten auch schlicht und ergreifend: $einsatzStart = '2011-10-16 12:00:00';

Die DATE/TIME-Datentypen in MySQL können mit einfachen Strings befüllt werden.

So am Rande, weil mir die Überlegung mal wieder absolut nicht einleuchten will: Die Software, die du nutzt, stellt spezielle Datentypen zur Ablage von Daten und Zeiten bereit… Was spricht gegen deren Einsatz?

 

[THE_fan]

Du meinst vermutlich time().



Wenn du es unbedingt als Timestamp willst:

<?php

$timestamp = strtotime('2011-10-16 12:00:00');

var_dump(
    $timestamp,
    date('Y-m-d H:i:s', $timestamp)
);

Ansonsten auch schlicht und ergreifend: $einsatzStart = '2011-10-16 12:00:00';

Die DATE/TIME-Datentypen in MySQL können mit einfachen Strings befüllt werden.

Danke!

So am Rande, weil mir die Überlegung mal wieder absolut nicht einleuchten will: Die Software, die du nutzt, stellt spezielle Datentypen zur Ablage von Daten und Zeiten bereit… Was spricht gegen deren Einsatz?

Unwissenheit ;) Deshalb fragte ich ja hier, was man wie verbessern kann.


Gruß
Stefan

 

[struppi]

Unwissenheit ;)

Das solltest du schnellstens ändern. Als ich mit mySQL anfangen wollte, habe ich mir erst mal ein Buch gekauft. SQL ist so komplex und darüber hinaus noch Sicherheitsrelevant, dass ich mit einem einfachen Trial and error da gar nicht ranwagen würde. Obwohl das meine übliche Lernmethode ist.

Du kannst bei SQL soviel falsch machen, dass dir u.U. erst nach jahrelanger Entwicklung auffällt, dass eine intensive Vorbereitung eigentlich Pflicht sein sollte.

 

[sysop]

Dem schliesse ich mich an.
Copy und Paste machen bei Datenbanken keinen Sinn. Wenn man wie ich schnell mal ins Forum sieht und dann beim posten versehentlich VARCHAR mit INT verwechselt, kommt nur Blödsinn dabei raus. Gott sei Dank lesen ander Forenmitglieder die Posts etwas aufmerksamer und greifen korrigierend ein. Darauf würde ich mich aber nicht verlassen.

Back to Topic.
Ich persönlich setze bei Zeitbezogenen Tabellen gerne eine Spalte Jahr, was das Aufräumen wesentlich erleichtert, da man z.B. schnell mal das Jahr 2010 löschen kann. Viele machen das dann über den Timestamp, ich bin da etwas faul und bereite das gerne in der Tabelle vor. Auswertungen und Statistiken werden um einiges einfacher, wenn man mit den Zeitstempeln nicht herumrechnen muss, es bieten sich also auch Monat und Tag als eigene Spalte an (je nach Bedarf).

Platz in Datenbanken ist heute bei weitem nicht mehr so teuer wie es einmal war, etwas Platzverschwendung kann man also durchaus tollerieren.:roll:

 

[struppi]

Back to Topic.
Ich persönlich setze bei Zeitbezogenen Tabellen gerne eine Spalte Jahr, was das Aufräumen wesentlich erleichtert, da man z.B. schnell mal das Jahr 2010 löschen kann. Viele machen das dann über den Timestamp, ich bin da etwas faul und bereite das gerne in der Tabelle vor. Auswertungen und Statistiken werden um einiges einfacher, wenn man mit den Zeitstempeln nicht herumrechnen muss, es bieten sich also auch Monat und Tag als eigene Spalte an (je nach Bedarf).

Es ist vielleicht ein bisschen einfacher, aber du musst dann immer diese zusätzlichen Spalten für jedes Datum in der Datenbank mitschleppen, dabei ist die Funktion um das Jahr oder den Monat aus einem DateTime Feld zu extrahieren sehr einfach: YEAR(`feld`) oder um dein Beispiel zu verwenden DELETE FROM tabelle WHERE YEAR(feld) = 2010

 

[sysop]

Ich sage ja, einige machen das über die Date/Time Funktionen.
Bei einem Timestamp (time(); )muss ich schon wieder rumrechnen, was beim setzen des Datensatzes eher nebensächlich ist, bei 100.000 Daten aber ins Gewicht fallen kann (man kann natürlich auch mit <4711 AND >0815 rechnen ).
Ein delete auf alle Daten WHERE 'jahr' = 2010 ist da schon einfacher (ABER zugegeben, getrickst).

PS
Konkret habe ich hier z.B. eine Termintabelle, es soll ein Dropdown generiert werden, in dem die Jahre aufgelistet werden, über die sich die Termine erstecken. Natürlich kann ich alle Termine durchackern und die Jahre herausrechnen, einfacher geht es, wenn ich die Spalte Jahr herausnehme und dann gruppiert die Daten an ein Select-Generator übergebe.

 

[THE_fan]

struppi, da hast du sicher Recht. Eigentlich ist es schon fahrlässig, dass man ohne großes Wissen an eine solche Sache herangeht. Schlimmer wäre es natürlich, sollten Kundendaten o.ä. im Spiel sein. Hier ist es "nur" eine Seite der Feuerwehr, die lediglich der Information von Bürgern & Interessierten dient. Wenn es hier mal crashen sollte ist nichts wichtiges verloren. Nicht dass ihr mich falsch versteht, ich nehme das natürlich trotzdem ernst.

Ich bin ja auch gewillt zu lernen und zu verstehen.. Copy und paste wende ich hier sicher nicht an ;)

Es ist eben ein kleines (großes) Projekt für mich.. Leider habe ich nicht die Zeit mich so intensiv damit zu beschäftigen. Sein lassen möchte ich es trotzdem nicht.

Ich bin euch wirklich dankbar, dass ihr versucht mir zu helfen und hoffe, dass das auch weiterhin der Fall sein wird!

Danke!

Gruß
Stefan

 

[struppi]

struppi, da hast du sicher Recht. Eigentlich ist es schon fahrlässig,

Sprach ich von fahrlässig? Es ist einfach müsig, du bastelt dir etwas zusammen, was höchstwahrschienlich Schrott ist, weil du die Grundlagen nicht kennst. Du kannst sql nicht "by doin" lernen!

 

[THE_fan]

Du kannst sql nicht "by doin" lernen!

Habe ich auch nicht behauptet.
Wenn ich mir die Abfragen anschaue, sind es größtenteils einfache "SELECT .. FROM .. WHERE .. = .." - Abfragen. Das sind für mich (vereinfachte) Grundlagen.
Ich kenne zum größten Teil die Syntax, mache das schon seit fast 5 Jahren. Allerdings eben noch nicht oft über diese "Grundlagen" hinaus.. Das war's.

Ich bin und war noch nie einer der Sorte, der hier die Hausaufgaben gemacht haben möchte ;) Ich lese mir alles durch und frage nach, wenn ich etwas nicht verstehe.. Den Rest erarbeite ich mir, insofern es mir gelingt, selbst. Nur manchmal, wie in diesem Fall, bin ich eben mit meinem Latein am Ende - und da kommt ihr ins Spiel.

Danke für die Ratschläge!

Gruß
Stefan

 

[struppi]

Habe ich auch nicht behauptet.
Wenn ich mir die Abfragen anschaue, sind es größtenteils einfache "SELECT .. FROM .. WHERE .. = .." - Abfragen. Das sind für mich (vereinfachte) Grundlagen.

Sind es aber nicht. Grundlagen sind Normalisierung, Kenntnise über joins und ganz wichtig der Umgang mit Indizes. Und in der Regel erkennst du nicht anhand einer select abfrage welche Entwicklung dahinter steckt.

Deine ursprüngliche Frage enthält all diese Problematiken, du musst dir Gedanken über die Normalisierung machen, du musst joins anwenden und du musst dir in Folge dessen genau überlegen auf welche Felder du einen Index legst. Das kann selbst bei kleineren Datenmengen schnell einen Unterschied von Minuten pro Abfrage ausmachen.

EDIT: und sowas kommt dann dabei raus, wenn man sich gar nicht mit sql auseinandersetzen will http://www.html.de/datenbanken-z-b-mysql/41374-mysql-max.html#post298612
Das ist gruselig!

 

[achtelpetit]

Off topic @ sysop:

...wenn man mit den Zeitstempeln nicht herumrechnen muss, es bieten sich also auch Monat und Tag als eigene Spalte an (je nach Bedarf).

Und wie verhinderst Du den 31. Februar oder den 45. März?
Entweder gar nicht, dann isses nicht gut oder mit aufwendigen Mechanismen in der DB, dann wäre der Umgang mit der Unixzeit einfacher.

 

[mermshaus]

Auch dazu: MySQL hat ehrlich ganz brauchbare Datentypen, Funktionen und Operatoren dafür. DELETE FROM `post` WHERE YEAR(`added_on`) = 2011 usw.

Es mag Grenzfälle geben, in denen es sinnvoll ist, die Angaben aufzudröseln, aber… Ach, Leute, das ist wieder so ein Fall von: „Technisch gesehen sicher richtig, aber wenn wir das so schreiben, denken alle, es wäre auch für ‚normale‘ Anwendungsfälle ein legitimes Mittel.“ Deshalb: Es ist keins.

Zum Thread: Ungeachtet der Frage, ob man solche DB-Basteleien mit ausbaufähigem Wissen an „Privatprojekten“ nun lieber gar nicht betreiben sollte, kann ich die Aussagen zur Wichtigkeit von Normalisierung, Joins und Indizes absolut unterstreichen.