ab Wann aus einer Spalte eine Tabelle machen ?

[phyrexianer]

es geht um eine Literaturdatenbank welche Bibtex-konform arbeiten soll.

jetzt gibt es laut bibtex ca 14 verschieden Typen von Einträgen, je nach Eintrag werden verschiedene felder (Spalten) als Pfilchtfelder deklariert.

Ist es Sinnvoll für jeden Typ eine eigene Tabelle an zu legen oder einfach eine Tabelle "publikationen" und dort dann eine "type_id"-Spalte mit der Entsprechender Tabelle ?

Bei der Lösung mit einer Tabelle hätte ich das "problem?" dass ich leere Felder hätte je nachdem was für ein "typ" in die Tabelle eingetragen wird. Zudem möchte ich später auf der Hauptseite die 5 neuesten Einträge aus allen Typen ausgeben, also nicht jeweils aus jeden Typ sondern aus den gesamten Einträgen.

Mir geht es hier also mehr um das Datenbankdesign. Wann lege ich für einen Inhalt eine Tabelle an und wann nicht !? Bzw. Ist es denn immer Sinvoll eine neue Tabelle an zu legen wenn eine "belongsTo, HABTM, hasMany...." beziehung herstellt werden kann.

[bacarni]

...
Mir geht es hier also mehr um das Datenbankdesign. Wann lege ich für einen Inhalt eine Tabelle an und wann nicht !? Bzw. Ist es denn immer Sinvoll eine neue Tabelle an zu legen wenn eine "belongsTo, HABTM, hasMany...." beziehung herstellt werden kann.

Hallo. Ich weiß nicht genau, ob du es schon kennst. Aber ich beschäftige mich dann immer mit der Normalisierung [1]. Bei mir hat es auch immer gut gepasst.


---
[1] - http://de.wikipedia.org/wiki/Normalisie ... tenbank%29

[phyrexianer]

OK habe es mir mal durchgelesen.... und es teilweise verstanden.... aber meine Frage konnte ich nicht wirklich damit beantworten.

Ich würde gerne das hier http://de.wikipedia.org/wiki/Bibtex#Literaturtypen_.28Entry_Types.29 in einer Datenbank erfassen.

Frage ist lege ich eine Tabelle an in der der "entry_type"(Referenzart) ein Atribut ist !? und alle anderen "möglichen" Attribute als Spalten !? oder lege ich für jeden "entry_type" eine eigene Tabelle an ?

(Adresse , PLZ, Author,Stadt,Zeitschrift usw. würde ich natürlich in eine eigene Tabelle packen also die "Redundanten-Daten" Ich hoffe das ich hiermit das Problem etwas konkretisieren konnte.

gruß.........

EDIT:
habe mal eine Grafik von meiner Datenbank dran gehängt vielleicht kann man da eher einsehen was ich will. Ist halt die Frage ob ich die "publicationstabelle" in 14 eigene nach dem entrytype benannte Tabellen aufspalte.

[phyrexianer]

ok ich wollte eben die "publications" -Tabelle zerlegen stelle aber dabei fest, dass ich sozusagen aus der einen Tabelle 28 Tabellen machen muss. 14 Tabellen für die Entrytypes + 14 Tabellen für die Verbindung zwischen Authors usw. das heißt für "locations" bräuchte ich wieder ca 8 Tabellen usw. Ist es denn wirklich praktisch so vor zu gehen ? Knabbert es nicht an der Performance ?

Wegen der Erweiterbarkeit habe ich dann auch noch das Problem das ich für jeden neuen Typ eine zusätzliche Tabelle anlegen müsste plus die eventuellen HABTM Tabellen.

Ich denke ich werde bei der 1 Tabellen Lösung bleiben. da kann ich wohl auch einfacher neue Typen definieren.

[euromark]

ich versteh nich, warum du so krass normalisierst...

z.b. warum year, month etc nich einfach als datum-field drin stehen können

und bzgl deiner 14 types:
wie schauen denn die werte aus?
und gibts definitiv nur 14, oder werden das dauernd mehr oder weniger?

[phyrexianer]

also die EntryTypes kannst du hier sehen http://de.wikipedia.org/wiki/BibTeX#Literaturtypen_.28Entry_Types.29 und da können eventuell noch ein paar dazukommen ist aber nicht so dass es dynamisch erstellt werden soll oder ähnlich. Jedoch bleiben die Attribute bei allen Types die gleichen bzw. selben.

Abhängig von EntryType sind jeweils unterschiedliche Attribute(Spalten) Pflicht bzw. Optional

ja die Normalisierung habe ich wegen der Redundanz der Daten gemacht. Da ja das Jahr 1989 doch recht oft vorkommen würde usw. Wobei das Datum sich ja nie ändern würde. Da weiß ich aber zu wenig über die Technik der Datenbanken bzw. wie sich das alles auf die Performance auswirkt. Es fehlt mir noch das Feingefühl dafür wann ich eine Tabelle anlegen soll und wann nicht. Deswegen bin ich ja auch hier unterwegs. Aber das mit dem Jahr und dem Monat empfand ich auch als etwas zuviel des guten *fg*.

dann würde ich andersherum fragen ...... wann hätte ich Perfomanceeinbußen ? bei eine großen Tabelle oder wenn ich viele kleine mache und diese im Endeffekt "joine"(bin der Meinung dass, das im Hintergrund passiert bzw. Cake macht das).

Welche Nachteile bringt meine Bisherige "große" Tabelle mit ?

[euromark]

a) semi-hardcoded würd ich die dann machen
so mach ich das auch immer bei solchen daten
ne zusätzliche modelrelation ist schwachsinnig, wenn es z.b. um prios etc geht (low, medium, high, ...)
bei dir sinds halt n paar mehr

im model ne fuction die alle möglichen werte zurückgibt mit integer-keys
und diese werden als tinyint(2) in die DB abgelegt
extrem performant und einfach zugleich


b) die abhängigkeit einfach im beforeValidate dazuschalten
n array, das die required keys pro "typ" hat, wird dann dynamisch geadded, bevors zum validieren geht

[phyrexianer]

im model ne fuction die alle möglichen werte zurückgibt mit integer-keys
und diese werden als tinyint(2) in die DB abgelegt
extrem performant und einfach zugleich

sorry das verstehe ich nicht so ganz was du damit meinst.....bzw. wüsste ich nicht was ich mit den "tinyint's" ausdrücken soll !?

b) die abhängigkeit einfach im beforeValidate dazuschalten
n array, das die required keys pro "typ" hat, wird dann dynamisch geadded, bevors zum validieren geht

das wollte ich ähnlich machen.... siehe Grafik, somit kann ich neue Typen anlegen bzw. die optionalen und benötigten Felder verwalten. Das Hinzufügen neuer Typen wäre durch einen Admin auch recht einfach. In die Tabelle "pub_entry_field" würde ich die möglichen Spaltennamen = Feldtypen eintragen und die Beziehugne über zwei HABTM Tabellen herstellen. Ist etwas gegen diese Lösungsmöglichkeit ein zu wenden ?

Das Jahr werde ich dann als "YEAR"-Feld speichern. und den Monat als ein INT zwischen 1-12 (ein MONTH -field gibt es nicht meiner Meinung nach !?)

[euromark]

ich werde, wenn ich dazukomm, mal meine musterlösung im forum präsentieren
solang meine codesnippet bib noch nich steht
wär halt englisch, wenns niemand stört.

dann nimm für month tinyint(2) unsigned
die können auch bis zu 255 werte speichern und brauchen mal wieder weniger platz


//EDIT
hier hab ichs mal schnell rein: http://www.cakephp-forum.com/post2100.html#p2100

[phyrexianer]

ja hab mir das snippen angesehen. Ist auch eine schöne Lösung. Jedoch müsste dann bei der Erstellung eines neuen Types der "code" angepasst werden. Es sollte aber möglich sein, die Typen über ein Admin Menü zu erstellen und die notwendnginde Felder zu einem Typ zuweisen zu können. Ich denke , meine Datenbank ist soweit ok dass ich erste Models und Klassen programmieren kann.
Werde dann berichten ob und wie gut es dann bei mir klappt.

gruß