[Gitarremann]

Ich überlege gerade, eine Datenbank für meine Feuerwehrseite einzurichten. Ich hab momentan Webspace mit PHP dafür, aber keine mySQL Datenbank und arbeite deswegen noch mit Textdateien. Prinzipell ist das aber so strukturiert dass es so ähnlich wie eine Datenbankanwendung ist und nur eben in den Textdateien die Datensätze stehen. Das Umbauen in eine richtige Datenbank ist technisch auch nicht das Problem. Ich überlege nur, wie ich die Datenbank strukturiere.

Beispiel, ich habe 500 Datensätze mit Einsätzen und 300 Datensätze mit aktuellen Meldungen. Die Datensätze haben die gleiche Struktur können also in eine Tabelle. Ich könnte nun die 800 Datensätze in eine Tabelle schreiben und mache eine Spalte "Kategorie", wo bei den Datensätzen für die Einsätze eben Einsatz steht und bei den anderen "Meldungen" und wenn ich die Einsätze oder Meldungen auf der Seite anzeigen will, dann filter ich mir die Datensätze anhand der Kategorie raus.
Oder wäre es effektiver für Einsätze und aktuelle Meldungen je eine Tabelle anzulegen. Effektiv hieße jetzt hauptsächlich bezogen auf die Zeit, die die Abfrage dauert? Sicherlich ist es bei dem Beispiel noch egal aber es gibt noch mehr Inhalte womit die Datensätze dann irgendwann in den fünfstelligen Bereich gehen könnten.

[lloiser]

Dadurch dass die sich die Einträge immer mehr werden und die Tabelle dadurch immer voller, würde ich persönlich eher zu 2 verschiedenen Tabellen tendieren. Eigentlich hauptsächlich um ein bisschen mehr Übersicht zu haben falls mal etwas händisch an der Datenbank gemacht werden muss.
Aber ich denke nicht das es sich sehr bemerkbar machen wird alles in eine zu schreiben, außer das dir eventuell die Übersicht verloren geht.

[[Elite-|-Killer]]

Also im Bereich von <99999 Datensätzen denke ich, dass es wirklich ziemlich egal sein wird ob es jetzt mehr Tabellen sind oder eine.

[Matze]

Wenn die Einsätze und Meldungen tatsächlich identische Attribute haben, dann brauchst du das nicht zwingend auslagern. Mit einem Kategorieindex und dem internen Caching wird das performant laufen. Notfalls kann man noch auf Views zurückgreifen, damit die entsprechend gefilterten Daten noch fixer bezogen werden können.
Ich habe hier eine Tabelle auf einem Datenbankserver mit etwa 1,5 Millionen Zeilen und das Filtern läuft trotzdem performant.

Solltest du in Zukunft jedoch eine Spalte mehr bei den Meldungen bzw. Einsätzen benötigen musst du einiges umbauen. Datenbankschema umstellen, Skripte anpassen, etc. Aber wenn du da kein Problem siehst ...

[Gitarremann]

Ja danke also dann mach ich das in eine. Das mit einer zusätzlichen Spalte ist nicht das Problem. Wenn ich für die Meldungen eine brauche, dann füge ich die einfach ein. Die stört ja bei den Einsätzen nicht, da ich die ja da dann nicht abfrage und das Anpassen der Scripte hab ich bei separaten Tabellen ja so oder so, wenn ich eine Spalte einfüge. Erinnert mich aber trotzdem daran, vorher gründlich zu überlegen, was und wieviel ich brauch.
Hab mir gerade erstmal ein Script gebastelt, dass die Textdateien der Einsätze ausliest und in die Datenbank schreibt und was sehe ich da? 491 Datensätze sind es und die 500 im Beispiel waren frei erfunden. Hut ab, vor dem Zufall.

[zwutz]

bei sowas kommt es immer an, was du repräsentieren willst mit der Tabelle. die Performance ist in dem Bereich irrelevant, vor allem, wenn du Dateien gewöhnt bist (die sind um einen deutlichen Faktor langsamer).
Wenn du oft nur das eine oder das andere brauchst, seltener beide zusammen, nimm getrennte Tabellen. Wenn es allerdings die Regel ist, dass du beide Typen brauchst und die Filterung die Ausnahme, dann leg es in einer Tabelle ab.
Deweiteren hast du bei zwei Tabellen den Vorteil dass sie jeweils eindeutige IDs haben, die auch entsprechend referenziert werden können, falls nötig (Meldung 1 führte zu Einsatz 2 usw) und dass du eine Tabelle erweitern kannst, ohne die anderen Werte zu beeinflussen (falls doch mal unterschiedliche Anforderungen kommen)

Wie handhabst du es denn bisher? Zwei getrennte Dateien oder eine gemeinsame?