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