Daten in DB oder doch lieber in eine Datei?

[Jeena Paradies]

Hallo,

Ich möchte meiner Software Kategorien verpassen. Jeder (Weblog)Eintrag soll in einer oder mehreren Kategorien auftauchen können, oder in gar keiner. Jetzt überlege ich wohin ich die Kategorienamen abspeichern soll. Mir sind drei Möglichkeiten eingefallen:

1. Volle Kategorienamen in die gleiche Tabelle wie der Eintrag ist. Damit müsste ich aber wenn ich alle Kategorienamen brauche (was eigentlich bei jedem Seitenaufruf der Fall ist) aus der ganzen Tabelle zusammensuchen. Irgendwie glaube ich nicht dass das wirklich sinnvoll ist, andererseits habe ich dann alles schön zusammen eng verschnürt.

2. In die Eintragstabelle kommen nur die IDs der Kategorienamen. Die eigentlichen Kategorienamen werden in einer extra Tabelle abgespeichert. Wenn ich dann alle Kategorienamen haben will muss ich nur diese Tabelle auslesen. Außerdem machen das genau so so ziemlich alle Weblogsysteme und CMS, die ich bisher getestet habe. Dadurch wird aber die Datenbank aber irgendwie dreckig (vom Gefühl her) und absolut kleine Tabellchen mit ein oder zwei Kategorienamen nehmen dann dort platz. Andererseits ist man für die Zukunft gerüstet und kann dort noch einiges mehr an Metainfo über die Kategorien speichern, wie Beschreibungen, Zugangsvoraussetzungen etc.

3. Das gleiche wie 2., nur dass ich anstatt einer Tabelle in einer Datenbank eine XML oder Textdatei nehme und diese Daten dort abspeichere. Ich finde nicht wirklich Nachteile dieser Technik, könnte mir da vielleicht jemand auf die Sprünge helfen und mir sagen warum sonst alle anderen Systeme, die ähnlich meinem funktionieren, alles in die Datenbank schreiben? Die Datei würde ja nicht wirklich groß werden und wenn es eine XML Datei ist wäre sie auch für die Zukunft mindestens genau so flexibel wie eine Tabelle in der Datenbank.

Grüße
Jeena Paradies

[wahsaga]

hi,

1. Volle Kategorienamen in die gleiche Tabelle wie der Eintrag ist.

volle namen redundant dort aufnehmen scheidet eigentlich schon mal aus - ist ein "don't" des datendesigns.

Damit müsste ich aber wenn ich alle Kategorienamen brauche (was eigentlich bei jedem Seitenaufruf der Fall ist) aus der ganzen Tabelle zusammensuchen.

eben, dicker nachteil dieser methode.

2. In die Eintragstabelle kommen nur die IDs der Kategorienamen. Die eigentlichen Kategorienamen werden in einer extra Tabelle abgespeichert. Wenn ich dann alle Kategorienamen haben will muss ich nur diese Tabelle auslesen.

jepp, die gängigste variante.
richtig normalisiert liefe das vermutlich sogar noch auf eine zusätzliche tabelle hinaus, die nur die zwei spalten eintrags-id und kategorie-id enthält:

e-id | k-id
15   | 3
15   | 4
15   | 7

der eintrag 15 ist also den kategorien 3, 4 und 7 zugeordnet.

erleichtert dann das zusammensuchen aller einträge zu einer bestimmten kategorie.

allerdings kann man es mit der normalisierung bekanntlich auch übertreiben ... es wäre also auch denkbar, die kategorien direkt am eintrag abzulegen, und zwar alle in einer spalte.
bei mysql als DB würde sich dafür SET als spaltentyp empfehlen. und das suchen von beiträgen in einer bestimmten kategorie ist damit auch noch einfach und recht performant zu machen.

3. Das gleiche wie 2., nur dass ich anstatt einer Tabelle in einer Datenbank eine XML oder Textdatei nehme und diese Daten dort abspeichere.

datenhaltung in DB und XML-dateien vermischen?
klingt für mich auf anhieb zu inhomogen ...

gruß,
wahsaga

[Jeena Paradies]

Hallo,

datenhaltung in DB und XML-dateien vermischen?
klingt für mich auf anhieb zu inhomogen ...

Ok, genau das interessiert mich jetzt. Was bedeutet in der Praxis hier inhomogen? Welche konkreten Nachteile habe ich davon?

Grüße
Jeena Paradies

[Christoph Schnauß]

hallo Jeena,

klingt für mich auf anhieb zu inhomogen ...
Ok, genau das interessiert mich jetzt. Was bedeutet in der Praxis hier inhomogen? Welche konkreten Nachteile habe ich davon?

Es wird unübersichtlich.

Grüße aus Berlin

Christoph S.

[Jeena Paradies]

Hallo,

Es wird unübersichtlich.

Hm, naja es kommt wohl drauf an wie man das sieht. Für mich wäre es viel unübersichtlicher da noch zwei kryptische Tabellen für den Kategorieaufsatz in der Datenbank zu haben, als eine XML Datei, die mir aus den Zahlen in der DB, falls ich es benötige, schöne ausgeschriebene Wörter als Kategorienamen macht. Sind ja wirklich nur von einem bis höchstens 15 Einträge und nicht mehr.

Grüße
Jeena Paradies

[Sven Rautenberg]

Moin!

Ok, genau das interessiert mich jetzt. Was bedeutet in der Praxis hier inhomogen? Welche konkreten Nachteile habe ich davon?

Wenn die Kategorienamen in der DB stehen, kann man (grundsätzlich) auf jede Abfrage noch einen JOIN draufsatteln und so zusätzlich zu den IDs, die bei den Blogeinträgen stehen, noch direkt den Kategorienamen zuordnen.

Wenn du die Kategorienamen separat (egal ob als Flatfile, XML oder PHP-Include mit Arraydefinition - letzteres wäre wohl am performantesten für deine Anwendung) speicherst, hast du diese Möglichkeit generell nicht mehr, sondern mußt die Zuordnung der IDs extern realisieren.

Die Lösung mit der Datenbank verhindert diesen Lösungsweg allerdings ebensowenig, denn statt des JOINs wäre es ja auch denkbar, zum Skriptstart die Kategorietabelle komplett auszulesen und zu speichern.

Letztendlich ist alles auch eine Frage der Performance. Eine DB-Tabelle mit 15 Kategorien dürfte so winzig sein, dass sie mit Sicherheit komplett in den HD-Cache und/oder den DB-Cache paßt. Der Aufwand für einen JOIN dürfte deshalb, egal wie groß die Abfrage der Blogeinträge wird, kaum nennenswert irgendetwas bremsen.

Die Methode, am Start jedes Skripts die DB-Tabelle auszulesen, um sie dann manuell zuzuordnen ist im Vergleich dazu sicherlich nicht so optimal, dürfte aber trotzdem nicht zu bemerken sein.

Die XML-Datei dürfte von allen Methoden die langsamste sein, das Text-Flatfile ließe sich ggf. schnell mit file() einlesen (aber das Datenformat wäre dann heftig anfällig gegen Datenveränderung, da die Kategorie-ID in der Zeilennummer steckt), ein Parsing so einer Datei wäre logischerweise aufwendiger, und mit einem PHP-Codeinclude, in dem direkt das Array definiert wird, kommt man wahrscheinlich am Schnellsten davon, wenn man auf den DB-Join verzichten will.

Dennoch würde ich tatsächlich die DB-Tabelle anlegen. Dann ist der Datenbestand immer vollständig in der DB abgelegt und könnte auch von jeder anderen Software ausgelesen werden - die Kategorienamen gehen nicht einfach verloren. Über die DB-Performance muss man sich angesichts der absehbaren Querys jedenfalls keine riesigen Sorgen machen. Üblicherweise werden nur kleine Mengen des Datenbestandes in einem Query abgefragt, mit vernünftigen Indices sollte das kein großes Thema werden.

• Sven Rautenberg

[XaraX]

Hallo Jeena,

..., das Text-Flatfile ließe sich ggf. schnell mit file() einlesen (aber das Datenformat wäre dann heftig anfällig gegen Datenveränderung, da die Kategorie-ID in der Zeilennummer steckt), ein Parsing so einer Datei wäre logischerweise aufwendiger, und mit einem PHP-Codeinclude, in dem direkt das Array definiert wird, kommt man wahrscheinlich am Schnellsten davon, ...

Da hatte Tom einen wunderbaren Trick parat gehabt http://forum.de.selfhtml.org/archiv/2004/8/t86777/#m514091. Diese Methode wäre sogar etwas simpler über Scripte zu warten, als mittels PHP-Script ein Includefile zu generieren.

Gruß aus Berlin!
eddi

[Christoph Schnauß]

hi,

3. Das gleiche wie 2., nur dass ich anstatt einer Tabelle in einer Datenbank eine XML oder Textdatei nehme und diese Daten dort abspeichere.
   datenhaltung in DB und XML-dateien vermischen?

Das habe ich anders gelesen. Es geht nicht ums Vermischen, sondern um die Alternative: entweder Datenbank oder XML.

klingt für mich auf anhieb zu inhomogen ...

Das wärs in der Tat. Aber wenn ich mir Jeenas Software richtig angekuckt habe, ist XML eher die Methode der Wahl.

Grüße aus Berlin

Christoph S.

[XaraX]

Hallo Jeena,

Das habe ich anders gelesen. Es geht nicht ums Vermischen, sondern um die Alternative: entweder Datenbank oder XML.

So dachte ich anfangs auch. Bitte denke auch an die Datenbankmuffel (lieb guck :)

Gruß aus Berlin!
eddi

[wahsaga]

hi,

Das habe ich anders gelesen. Es geht nicht ums Vermischen, sondern um die Alternative: entweder Datenbank oder XML.

so wie ich es verstanden habe, wollte Jeena _nur_ die kategorienamen in einem XML-file ablegen, und seine übrigen daten eines eintrages weiterhin in der DB belassen.

gruß,
wahsaga

[Jeena Paradies]

Hallo,

so wie ich es verstanden habe, wollte Jeena _nur_ die kategorienamen in einem XML-file ablegen, und seine übrigen daten eines eintrages weiterhin in der DB belassen.

Ja so war es gedacht.

Grüße
Jeena Paradies

[Christoph Schnauß]

hallo Jeena,

3. Das gleiche wie 2., nur dass ich anstatt einer Tabelle in einer Datenbank eine XML oder Textdatei nehme und diese Daten dort abspeichere. Ich finde nicht wirklich Nachteile dieser Technik

Ich auch nicht. XML ist meines Erachtens für dich die Methode der Wahl.

könnte mir da vielleicht jemand auf die Sprünge helfen und mir sagen warum sonst alle anderen Systeme, die ähnlich meinem funktionieren, alles in die Datenbank schreiben?

Es ist üblich geworden, sehr schnell zu einer Datenbank zu greifen. MySQL steht ja auch jedem zur Verfügung und ist nicht so sehr fürchterlich schwer zu erlernen. Daß es in vielen Fällen gar nicht zwingend erforderlich ist, ein paar Dutzend Einträge dort aufzunehmen, ist wohl nicht allen klar. Datenbanken halte ich für sinnvoll, wenn es wirklich um große Datenmengen geht, die sich nicht anders verwalten lassen, aber das ist bei dir (noch) nicht der Fall.

Grüße aus Berlin

Christoph S.

[Jeena Paradies]

Hallo,

Es ist üblich geworden, sehr schnell zu einer Datenbank zu greifen. MySQL steht ja auch jedem zur Verfügung und ist nicht so sehr fürchterlich schwer zu erlernen. Daß es in vielen Fällen gar nicht zwingend erforderlich ist, ein paar Dutzend Einträge dort aufzunehmen, ist wohl nicht allen klar.

Jo genau dieses Gefühl habe ich auch. Götz Bürkle sagte einmal scherzhaft in #selfhtml (sinngemäß): »Tabellen kann man so viele errichten wie man will, das muss man ausnutzen.«

Grüße
Jeena Paradies

[Ilja]

yo,

du kannst lösungsweg 1 und 2 miteinander kombinieren. das heißt, du legst als schlüssel den Kategorienamen an und nicht eine künstliche ID. das hat den vorteil, dass der kategoriename schon in der einen tabellen steht, die du abfragen willst, musst also keinen join bilden. und zum anderen kannst du die kategorietabelle abfragen, wenn du die namer aller katetogieren brauchst und sparst sogar eine ID spalte in der seperaten kategorie-tabelle.

um noch mal ein wort für oder gegen datenbanken zu sagen. datenbanken sind primär aus einem grund enstanden und das ist die datenunabhängigkeit. das sollte man immer im kopf behalten, bevor man sich aufmacht, abhängigkeiten zu schaffen.

Ilja

[Sven Rautenberg]

Moin!

du kannst lösungsweg 1 und 2 miteinander kombinieren. das heißt, du legst als schlüssel den Kategorienamen an und nicht eine künstliche ID.

Das ist natürlich eine Lösung, aber wirklich die schlechteste von allen.

Angenommen, ich habe nur zwei Kategorien, "Donaudampfschiffahrtsgeschichten" und "Sonderangebotsvandalenstorys" - warum sollte ich diese langen Namen bei jedem neuen Eintrag in ihrer kompletten Länge abspeichern, wenn der Informationsgehalt doch nur bei einem Bit liegt: "Diese Kategorie oder die andere"?

Ähm, Moment, sagtest du "Kombination von 1 und 2" - wie soll das denn schlau gehen? Was steht denn in der Tabelle von 2 drin? Nochmal nur der Kategoriename?

das hat den vorteil, dass der kategoriename schon in der einen tabellen steht, die du abfragen willst, musst also keinen join bilden. und zum anderen kannst du die kategorietabelle abfragen, wenn du die namer aller katetogieren brauchst und sparst sogar eine ID spalte in der seperaten kategorie-tabelle.

Klingt nach ultimativem Schwachsinn. Damit gibt man alle Vorteile aus der Hand. Beispielsweise kann man nicht einfach in der Kategorietabelle einen Tippfehler korrigieren, der dann automatisch überall berichtigt wird. Ein schlechter Vorschlag!

• Sven Rautenberg

[Ilja]

yo,

Angenommen, ich habe nur zwei Kategorien, "Donaudampfschiffahrtsgeschichten" und "Sonderangebotsvandalenstorys" - warum sollte ich diese langen Namen bei jedem neuen Eintrag in ihrer kompletten Länge abspeichern, wenn der Informationsgehalt doch nur bei einem Bit liegt: "Diese Kategorie oder die andere"?

das problem ist heutezutage nicht so sehr der speicherplatz, sondern in aller regel mehr die performance. wenn ich mir mal bestimmte spaltentypen anschaue, dann sind die paar mehr bits lächerlich im gegensatz, was man in datenbanken alles rein packen kann und getan wird. der vorteil ist, ich habe einen sprechenden schlüssel und keinen codierten, das macht es übersichtlicher. und noch viel mehr ersparre ich mir einen Join. und die zweite tabelle dient eben dazu nicht, nicht einen dinstinct über die grosse tabelle ausführen zu müssen.

Klingt nach ultimativem Schwachsinn. Damit gibt man alle Vorteile aus der Hand. Beispielsweise kann man nicht einfach in der Kategorietabelle einen Tippfehler korrigieren, der dann automatisch überall berichtigt wird. Ein schlechter Vorschlag!

also du redest ja nicht von allen vorteilen der wegfällt, sondern nur von einem. und alles was man mehr tun muss, falls man sich bei den zwei wörter verschrieben hat, ist es in der einen kleinen tabelle ganz normal zu ändern und zusätzlich einen kleinen update befehl auf der grosen tabelle auszuführen. ich denke mal, du schaffst das schon, bist ja schon gross.

Ilja

[Sven Rautenberg]

Moin!

das problem ist heutezutage nicht so sehr der speicherplatz, sondern in aller regel mehr die performance. wenn ich mir mal bestimmte spaltentypen anschaue, dann sind die paar mehr bits lächerlich im gegensatz, was man in datenbanken alles rein packen kann und getan wird. der vorteil ist, ich habe einen sprechenden schlüssel und keinen codierten, das macht es übersichtlicher. und noch viel mehr ersparre ich mir einen Join. und die zweite tabelle dient eben dazu nicht, nicht einen dinstinct über die grosse tabelle ausführen zu müssen.

Da anzunehmen ist, dass man auch mal nach Kategorien selektiert, wird das Kategoriefeld ohnehin indiziert werden. Ein SELECT DISTINCT auf die Kategorien könnte die DB also extrem abkürzen, indem sie den Index ausliest und verwertet.

Abgesehen davon: Dein Vorschlag klingt einfach viel zu sehr nach MySQL. In richtigen Datenbanken legt man die Tabelle mit den Kategorien an und definiert bei den Blogeinträgen die Kategorie als Fremdschlüssel aus der Kategorietabelle. Mit irgendwelchen kryptischen IDs muß man sich dann garnicht mehr selbst herumschlagen, das verwaltet alles die Datenbank. Und mit den passenden Views bzw. Stored Procedures läuft auch das Lesen und Schreiben extrem simpel, indem man einfach nur einen INSERT mit allen Informationen sendet, und die DB dann die Aufteilung auf die verschiedenen Tabellen vornimmt.

Da du Speicherplatz vs. Performance ansprichst: Was ist wohl auf Dauer langsamer: Eine sich immer mehr aufblähende Datenbank, weil die Kategorienamen redundant immer wieder unnötig mitgespeichert werden, oder eine flinke Zuordnungsoperation im Speicher, um die Kategorie-ID mit dem zugehörigen Text zu versehen? Denk dran, Festplattenoperationen sind um den Faktor 1000 langsamer, als RAM-Zugriffe. Wenn du also von "Performance" sprichst und damit argumentierst, dann sollten alle deine Maßnahmen die Festplattenzugriffe minimieren. Und das zwingt dich dann logischerweise, die Datenbank so klein wie möglich zu halten. Abgesehen davon kräuseln sich jedem Fachmann bei deinem Tabellendesign die Fußnägel.

• Sven Rautenberg

[Ilja]

yo,

Da anzunehmen ist, dass man auch mal nach Kategorien selektiert, wird das Kategoriefeld ohnehin indiziert werden. Ein SELECT DISTINCT auf die Kategorien könnte die DB also extrem abkürzen, indem sie den Index ausliest und verwertet.

dass kann sicherlich so sein, dass das dbms den index benutzt. bin mir aber nicht sicher, ob jedes dbms das tun wird. es wäre mal ein versuch wert, sich den ausführungsplan anzuschauen. im normalen fall ist ein DISTINCT eine sortierung. aber wenn ja, könnte man eben wie gesagt die eine kleine tabelle auch weglassen. das widerspricht ja nicht dem, was ich vorgeschlagen haben, sondern egäntzt es und macht es noch einfacher.

Abgesehen davon: Dein Vorschlag klingt einfach viel zu sehr nach MySQL. In richtigen Datenbanken legt man die Tabelle mit den Kategorien an und definiert bei den Blogeinträgen die Kategorie als Fremdschlüssel aus der Kategorietabelle. Mit irgendwelchen kryptischen IDs muß man sich dann garnicht mehr selbst herumschlagen, das verwaltet alles die Datenbank. Und mit den passenden Views bzw. Stored Procedures läuft auch das Lesen und Schreiben extrem simpel, indem man einfach nur einen INSERT mit allen Informationen sendet, und die DB dann die Aufteilung auf die verschiedenen Tabellen vornimmt.

vielleicht benutzt er ja mysql, ich bin mir nicht sicher, ob er das dbms erwähnte. und auch hier sprechen die argumente nicht gegen meinen vorschlag, sondern unterstützen ihn ja geradezu, indem bei "richtigen" dbms alles noch einfacher wird, zumal du nun wieder eine zusätzliche kategorie tabelle mit rein nimmst, die du oben über den index sparen wolltest.

Da du Speicherplatz vs. Performance ansprichst: Was ist wohl auf Dauer langsamer: Eine sich immer mehr aufblähende Datenbank, weil die Kategorienamen redundant immer wieder unnötig mitgespeichert werden, oder eine flinke Zuordnungsoperation im Speicher, um die Kategorie-ID mit dem zugehörigen Text zu versehen?

zum einen kann hier von redundanz gar keine reden sein. auch ein künstlicher fremdschlüssel würde mehrfach vorkommen. das ist also schon mal quatsch, dass durch einen sprechenden schlüssel mehr redundanz erzeugt wird.

und was die performance betrifft, bei kleinen datenmengen wird man in keinen der beiden fällen einen unterschied merken. bei grossen datenmengen wird der join meiner erfahrung nach den kürzeren ziehen. ein fremdschlüssel über den kategorienamen ist nicht wirklich ein performance-killer.

Abgesehen davon kräuseln sich jedem Fachmann bei deinem Tabellendesign die Fußnägel.

na dann bin ich eben kein fachmann, meine fußnägel sind noch gerade.

Ilja

[Ilja]

yo,

hatte noch vergessen etwas zu dem speicher zu sagen. sicherlich sind RAM zugriffe schneller als festplattenzugriffe. wäre ja schön, wenn festplattenzugriffe genausoschnell sind oder umgekehrt grauenvoll, wenn der RAM zugriff so langsam wäre wie bei festplatten.

ABER, diese erscheinung alleine, macht meinen vorschlag nicht zwangsläufig speicherhungriger. die begründung liegt darin, dass meiner meinung nach ganze blöcke in den speicher gelesen werden, egal ob nun wirklich alle informationen davon benötigt werden oder nicht. es müsste schon genau geschaut werden, wieviele blöcke bei den unterschiedlichen vorgehensweise gelesen werden. wenn ich nun einen küstlichen schlüssel besitze, dann muss ich mindestenz zwei tabellen auslesen, falls auch der kategoriename mit angezeigt werden soll. habe ich einen sprechenden schlüssel in der tabelle schon mit drinn sprich in einigen fällen brauche ich nur eine tabelle anzusprechen, dann kann es durchaus sein, dass weniger blöcke in den speicher geladen werden.

oder mit anderen worten, falls ich mehr speichrplatz in einer datenbank auf der festplatte habe, bedeutet das nicht zwangsläufig auch, dass ich mehr speicher in den RAM laden muss.

Ilja

[Jeena Paradies]

Hallo,

Vielen Dank euch allen, ich habe zwar immer noch das Gefühl dass mir die dritte Möglichkeit besser gefällt, aber die Vernunft sagt eigentlich dass ich wohl zur zweiten greifen sollte.

Eine Nachfrage habe ich aber dennoch. Ein Beitrag kann ja jetzt nun mehreren Kategorien zugehören. Wenn ich das Datenbanktechnisch sinnvoll umsetzen wollen würde, müsste ich eigentlich für jede weitere Kategorie, der ich den Beitrag zuordnen will, eine extra Spalte in der Beitragstabelle vorausplanen. Ich bin dann aber wieder davon abhängig ob ich genügend vorausgeplant habe.

Oder gibt es noch eine sinnvollere möglichkeit die IDs der Kategorien in einer einzigen Spalte zu speichern (vielleicht mit einem Leerzeichen trennen) sie aber dennoch beim Abfragen sinnvoll unterscheiden zu können?

Grüße
Jeena Paradies

[wahsaga]

hi,

Eine Nachfrage habe ich aber dennoch. Ein Beitrag kann ja jetzt nun mehreren Kategorien zugehören. Wenn ich das Datenbanktechnisch sinnvoll umsetzen wollen würde, müsste ich eigentlich für jede weitere Kategorie, der ich den Beitrag zuordnen will, eine extra Spalte in der Beitragstabelle vorausplanen.

nein, gerade das ist absolut keine sinnvolle umsetzung.

Oder gibt es noch eine sinnvollere möglichkeit die IDs der Kategorien in einer einzigen Spalte zu speichern (vielleicht mit einem Leerzeichen trennen) sie aber dennoch beim Abfragen sinnvoll unterscheiden zu können?

sowohl zum thema "richtige normalisierung" als auch "vielleicht aber auch doch alle kategorien in eine spalte" sagte ich doch bereits etwas - leider bist du darauf in der antwort überhaupt nicht eingegangen.

da mich diesbezüglich bisher aber noch keiner der mitlesenden korrigiert hat, darfst du nach wie vor davon ausgehen, dass das ein ganz vernünftiger vorschlag ist ;-)

gruß,
wahsaga

[Sven Rautenberg]

Moin!

sowohl zum thema "richtige normalisierung" als auch "vielleicht aber auch doch alle kategorien in eine spalte" sagte ich doch bereits etwas - leider bist du darauf in der antwort überhaupt nicht eingegangen.

da mich diesbezüglich bisher aber noch keiner der mitlesenden korrigiert hat, darfst du nach wie vor davon ausgehen, dass das ein ganz vernünftiger vorschlag ist ;-)

Korrekt. Nur mit der dort dargestellten Methode kann man eine freie n:m-Zuordnung realisieren. Würde direkt in der Eintragstabelle ein oder mehrere Felder für eine Kategorie-ID enthalten sein, wäre das jeweils (ggf. mehrfach) nur eine 1:m-Zuordnung.

Was sich für gewitzte Menschen eventuell auch anbietet, ist der Feldtypen SET (ich halte ihn aber für viel zu eingeschränkt für das Vorhaben). Ein SET erhält bei der Tabellendefinition die Namen der Kategorien und gibt in einer Spalte jeweils eine kommaseparierte Liste der gesetzten Kategorien aus. Ist also im Vergleich zu einem JOIN, welcher den gleichen Datensatz mehrfach ausgibt für jede Kategorie, irgendwie handlicher.

Zwei Dinge stören aber:
1. Die Kategorienamen müssen beim Anlegen der Tabelle benannt werden, nachträgliche Änderungen sind zwar möglich, greifen aber über den Befehl ALTER in die Tabellenstruktur ein - sowas ist mit Hinblick auf eventuelle Rechteeinschränkungen, die man dem DB-Account auferlegen will, extrem hinderlich ist.
2. Die maximale Zahl der Kategorien ist begrenzt. Zwar sind je nach DB üblicherweise 64 Kategorien möglich, aber mehr geht definitiv nicht. Kategorien sind aber vom Wesen her nicht geeignet, zahlenmäßig begrenzt zu werden.

• Sven Rautenberg

[wahsaga]

hi,

Was sich für gewitzte Menschen eventuell auch anbietet, ist der Feldtypen SET

deshalb erwähnte ich gewitzter mensch ihn ja auch im verlinkten posting :-)

deine einwände, die dagegen sprechen, sind allerdings auch berechtigt.

diesen könnte man begegnen, in dem man SET mit einem zeichenkettenfeld emuliert, und da wiederum die einzelnen kategorie-IDs kommagetrennt o.ä. reinpackt.
läuft dann beispielsweise beim auslesen der beiträge zu einer bestimmten kategorie aber auch wieder auf ein gefummel mit stringfunktionen hinaus, um zu schauen ob ein datensatz zur kategorie xy gehört.

wirklich konsequentes normalisieren, also verwendung der angesprochenden zusätzlichen tabelle für die zuordnung beitrag -> kategorie, ist und bleibt also die sauberste lösung.

gruß,
wahsaga

[Jeena Paradies]

Hallo,

sowohl zum thema "richtige normalisierung" als auch "vielleicht aber auch doch alle kategorien in eine spalte" sagte ich doch bereits etwas - leider bist du darauf in der antwort überhaupt nicht eingegangen.

Das lag wohl daran dass ich überhaupt nicht kappiert habe dass da ein Zusammenhang besteht. Jetzt wo du mich mit der Nase noch einmal drauf gestoßen hast erkenne ich erst wie sinnvoll deine Lösung ist und warum sie so ist wie sie ist. So werde ich es versuchen umzusetzen, vielen Dank für deine Mühe.

Grüße
Jeena Paradies