nicht angemeldet
mysql: tags
Wie speichert man eigentlich tags in der Datenbank?
Angenommen ich habe einen Datensatz zu dem der User tags festlegen kann.
Wie würden diese gespeichert? Soll ich sie splitten (nach Kommata, Anführungszeichen etc.) und dann für jeden einen Datensatz anlegen? Oder alle tags in eine FULLTEXT -Spalte?
Bei http://www.flickr.com/photos/upload/basic/ kann man alle tags durch Kommata getrennt eingeben. Zusammenhängende Wörter werden durch Anführungszeichen verbunden. Wörter wie "zu, in, bei, der, die, das" usw. werden automatisch gelöscht.
Was denkt ihr, wie werden die tags bei Flickr in der Datenbank gespeichert?
-
Hi,
Was denkt ihr, wie werden die tags bei Flickr in der Datenbank gespeichert?
typischerweise dürfte es als n:m-Beziehung in normalisierter Form (also z.B. in Kleinschrift, Umlaute entfernt, überschüssige Leerzeichen weggetrimmt) mittels einer Kreuztabelle gespeichert werden.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes -
Hi,
Bei http://www.flickr.com/photos/upload/basic/ kann man alle tags durch Kommata getrennt eingeben.
Und was soll die *Eingabe* mit der *Speicherung* zu tun haben?
Was denkt ihr, wie werden die tags bei Flickr in der Datenbank gespeichert?
Soweit ich mich erinnere, kursierte mal ein PDF im Netz, welches das Datenmodell von flickr beschrieb. Und da wurde von der üblichen Normalisierung bewusst Abstand und auch Redundanz in Kauf genommen - weil es für die Gesamtperformance eines Systems mit dem Datenumfang, wie flickr ihn zu meistern hat, als günstiger erwiesen hat, als strikt "nach Lehrbuch" vorzugehen.
MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak.-
echo $begrüßung;
» Was denkt ihr, wie werden die tags bei Flickr in der Datenbank gespeichert?
Soweit ich mich erinnere, kursierte mal ein PDF im Netz, welches das Datenmodell von flickr beschrieb.Man findet es mit dem netten Suchbegriff: normalized data is for sissies.
Und da wurde von der üblichen Normalisierung bewusst Abstand und auch Redundanz in Kauf genommen - weil es für die Gesamtperformance eines Systems mit dem Datenumfang, wie flickr ihn zu meistern hat, als günstiger erwiesen hat, als strikt "nach Lehrbuch" vorzugehen.
Die Tags nicht atomar zu speichern gehört vermutlich nicht dazu, denn das würde verhindern, dass ein Index beim Suchen verwendet werden kann. Beim kommagetrennten Speichern von Werten tritt auch keine Redundanz auf. Es wäre eher von der Art so, dass man zu jedem Rechnungsdatensatz die kompletten Kundendaten ablegt, statt den Kunden in einer eigenen Tabelle abzulegen und bei jeder seiner Rechnungen nur darauf zu verweisen.
echo "$verabschiedung $name";
-
Hello,
Die Tags nicht atomar zu speichern gehört vermutlich nicht dazu, denn das würde verhindern, dass ein Index beim Suchen verwendet werden kann. Beim kommagetrennten Speichern von Werten tritt auch keine Redundanz auf. Es wäre eher von der Art so, dass man zu jedem Rechnungsdatensatz die kompletten Kundendaten ablegt, statt den Kunden in einer eigenen Tabelle abzulegen und bei jeder seiner Rechnungen nur darauf zu verweisen.
Schlechter Vergleich. Denn wenn ein Buchhaltungsbrogramm eine Abnahme von der OFD bekommen soll, dann muss das dort genau passieren. In jedem Rechnungskopfsatz muss ein kompletter Snapshot der relevanten Kundendaten vorhanden sein :-)
Ein Buchhaltungsprogramm hat da keine Wahl.
Das ist betriebsbedingtes Datenbankdesign.
Mit reiner technischer Normalisierung kommt man da nicht auf die Lösung.Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
echo $begrüßung;
Schlechter Vergleich. Denn wenn ein Buchhaltungsbrogramm eine Abnahme von der OFD bekommen soll, dann muss das dort genau passieren. In jedem Rechnungskopfsatz muss ein kompletter Snapshot der relevanten Kundendaten vorhanden sein :-)
Dabei wollte ich noch einen Nachsatz bezüglich dieser Problematik anfügen ... Allerdings kann man auch in dem Fall Rechnungsposten und Metadaten trennen. Die alten Metadaten werden dann eben als veraltet gekennzeichnet, tauchen in aktuellen Auflistungen nicht mehr auf, sind aber immer noch für die Historie mit den Rechnungsposten assoziiert.
echo "$verabschiedung $name";
-
-
-