Mailinglisten-Archive |
Hi Nico, meine Idee, Quatsch, sowas ist schon jahrzehntelang Standard. Man arbeitet mit mehreren Tabellen: 1. TAB: alles was es nur einmal zu einer Information gibt - Buchtitel, Autor, ISBN, ..., die eigene ID (auto_increment) 2. TAB: alles was mehrmals auftreten kann - Rezensionen, Meinungen, Wertungen, Links, u.s.w. Das wird mit der eigenen ID verknuepft: siehe foreigen_key Ziel ist es, nichts doppelt zu speichern, um z.B. bei Aenderungen nicht total durcheinander zu kommen, Plattenplatz und Performace optimal zu nutzen. Das kann man beliebig weit treiben, gibt es richtige Wissenschaftler fuer und nennt sich Normalisierung. Richtige 'Normalisierungs'-Fanatiker wuerden alle Links in eine extra Tabelle packen und nur deren ID referenzieren. In der Praxis, macht man das naturlich nur so gut als noetig. z.B. Links: Links aendern sich doch des oefteren. Wenn die im Text sitzen, hat man Probleme ohne Ende. Also schreibt man einen Verweis der immer konstant bleibt, z.B.: ##aaa.bbb_description##, und fuegt an der Stelle den aktuellen Link in den Text ein. Dabei ist 'description' das zu verlinkende Wort und aaa - die ID zu der Information, z.B. die auto_increment-ID aus der ersten Tabelle bbb - die ID aus der zweiten Tabelle, also die Zaehlnummer der jeweiligen Zusatzinformation Bei dem Beispiel sieht man auch sofort, warum man ID's nicht aendert, komme was da will. Einmal vergeben und basta, sonst haut es einem spaeter alles kreuz und quer durcheinander. Aus eben diesen Gruenden, sollte man fuer ein DB-Design sich echt Zeit goennen. Was da versaeumt wird, beschert einem im Nachhinein nur Probleme (so faengt jedes DB-Buch an ... ;-) m. b. G. Norbert _____________________ normal: 02292-681769 Notruf: 0177-2363368 --------------------- e.o.m.
php::bar PHP Wiki - Listenarchive