nicht angemeldet
Matthias Apsel
Matthias Apsel
dedlfix
dedlfix
Matthias Apsel
dedlfix
Hi,
meine Frage ist irgendwie etwas seltsam; ich schieße einfach mal los.
Häufig kann man ja mittlerweile "Tags" angeben. Wenn ich also eine Nachricht über Griechenland eingebe, könnte ich als Tags zum Beispiel "Athen; Finanzkrise" eingeben.
In meiner Vorstellung steht das dann auch so in der Datenbank (ich gehe mal von MySQL aus).
Wenn ich das jetzt auf mein Problem übertrage, dann würde ich auch gerne solche Tags verwenden. Aber der Sinn dieser Tags besteht doch sicherlich darin, dass ich z. B. alle Nachrichten anzeigen lasse, in denen die Tags "Athen" stehen.
Geht das denn theoretisch? Also reicht da eine Trennung mit Semikolon, um eine WHERE-Abfrage in MySQL zu starten, die sich letzten Endes nur auf "Athen" konzentriert, obwohl da auch noch "Finanzkrise" mit in der Zeile steht?
Versteht einer, was ich meine? Ich habe den Eindruck, dass das irre beschissen formuliert ist ;-).
Danke auf alle Fälle!
Wie du Wörter trennst, ist egal. Wenn du mit LIKE die Abfrage einschränkst, kannst du nach solchen "Tags" filtern, wenn deine Datenbank passende EInträge enthält.
Wie du Wörter trennst, ist egal. Wenn du mit LIKE die Abfrage einschränkst, kannst du nach solchen "Tags" filtern, wenn deine Datenbank passende EInträge enthält.
Mit LIKE allein wirst du nicht weit kommen
foo,bar,nachbarschaft,baz
feld LIKE '%arsch%' wird dir ein Ergebnis liefern, obowhl du keines erwartest
Kommata rundherum
feld LIKE '%,foo,%' wird hier kein ergebnis liefern, weil foo am anfang der liste steht
das Feld vorher mit Kommata umschließen
CONCAT(',', feld, ',') LIKE '%,foo,%'
Wird funktionierten, ist in MySQL-Aber nicht sonderlich schön - mit FIND_IN_SET() lässt sich das zumindest - auch wenn die Daten nicht normalisiert sind - trotzdem noch halbwegs brauchbar lösen.
Om nah hoo pez nyeetz, suit!
feld LIKE '%arsch%'wird dir ein Ergebnis liefern, obowhl du keines erwartest
Meine allererste Ebay-Bewertung vom 12.2.2004
"Danke alles bestens, sogar die Post war schnell."
Lies sich nicht abschicken.
Matthias
Meine allererste Ebay-Bewertung vom 12.2.2004
"Danke alles bestens, sogar die Post war schnell."
Versteh' ich nicht :(
Hello,
Meine allererste Ebay-Bewertung vom 12.2.2004
"Danke alles bestens, sogar die Post war schnell."
Versteh' ich nicht :(
Das kann jetzt entweder unter "Verschwörungstheorie" abgeheftet werden. Vielleicht hat die Post ja Anteile an eBay?
Oder aber der Programmierer hat z.B. erst alle Leerzeichen/Whitespaces entfernt aus dem Satz und hat dann seine "badwordlist" angewandt auf die Zeichenkette.
Oder doch was ganz anderes?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Oder aber der Programmierer hat z.B. erst alle Leerzeichen/Whitespaces entfernt aus dem Satz und hat dann seine "badwordlist" angewandt auf die Zeichenkette.
Vermutlich um
D a n k e a l l e s b e s t e n s s o g a r d i e P o s t w a r s c h n e l l
zu verhindern...
Gruß
K a l k
Hello,
Oder aber der Programmierer hat z.B. erst alle Leerzeichen/Whitespaces entfernt aus dem Satz und hat dann seine "badwordlist" angewandt auf die Zeichenkette.
Vermutlich um
D a n k e a l l e s b e s t e n s s o g a r d i e P o s t w a r s c h n e l l
------- --------- ----- ---------
<ironie>
Ich liebe diese Geheimbotschaften, die sich die Sozies, die Nazis, die CDU, die FDP, die Grünen, die Schwulen und die Lesben und alle, die der Verfassungsschwanz sonst noch so beobachtet (ach ja, die Linken), sich gegenseitig über diese sozialen Netzwerke so senden. Könnten die jetzt nicht "christliche Netzwerke" heißen? Oder doch besser "sekulare Meinungsbörsen"?
Naja, beobachten können wir ja schon mal...
</ironie>
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hallo,
Oder aber der Programmierer hat z.B. erst alle Leerzeichen/Whitespaces entfernt aus dem Satz und hat dann seine "badwordlist" angewandt auf die Zeichenkette.
vermute ich auch. Das ist nicht unüblich, wegen Spam der Sorte "V i a g r a" ...
Freundliche Grüße
Vinzenz
Hallo suit,
"Danke alles bestens, sogar die Post war schnell."
Versteh' ich nicht :(
DankeallesbestenssogardiePostwarschnell
Jetzt?
Freundliche Grüße
Vinzenz
"Danke alles bestens, sogar die Post war schnell."
Versteh' ich nicht :(
DankeallesbestenssogardiePostwarschnell
Jetzt?
Ja jetzt, wobei mir auch nach Toms Erläuterung nicht ganz klar ist, warum man die Leerzeichen entfernen sollte. Dass da Massenweise false positives rauskommen, müsste doch klar sein :)
Hello,
Ja jetzt, wobei mir auch nach Toms Erläuterung nicht ganz klar ist, warum man die Leerzeichen entfernen sollte. Dass da Massenweise false positives rauskommen, müsste doch klar sein :)
Kommt immer darauf an, ob der Auftraggeber nur einen "Programmierer" beauftragt hat, oder auch einen Programmdesigner und einen Soziologen mit Schwerpunkt "programmierte Verhaltensweisen".
Ich denke, dass uns HTML, Semantik, Dialogprogrammierung, technische Möglichkeiten, soziologische Folgen und Hintergründe, Ergebniserkennung und Ergebnisverdichtung, usw. noch mindestens 30 Jahre beschäftigen müssen, bis wir zu einem abgesicherten Zwischenergebnis kommen können.
Voraussetzung dafür ist aber die öffentlche Zugänglichkeit zu den notwendigen Medien, die Lehre des Umgangs mit diesen Medien, die Unzensiertheit der Medien, die (rechtliche + technische) Nutzbarkeit bisher relativ abgesicherter Quellen, usw.
Und selbstverständlich die Erkenntnis, dass kein Doktortitel, kein Bachelor oder Master oder Minister oder Staatsanwalt dazu berechtigen, neue Ideen zu unterdrücken, nur weil sie vielleicht nicht der allgemeinen Lehrmeinung entsprechen.
Die Philosophie dieses Forums, auch die (anfänglich) abstruseten Ideen erstmal als solche (als philosophischen Ansatz) stehen zu lassen, ist mMn ein wensentlicher Ansatz dafür, den richtigen Weg finden zu können, wenn es denn überhaupt nur einen gibt. Ich vergleiche das imnmer gerne mit einem Blitz, der sich entwickelt. Der züngelt anfangs auch einige Tausend Mal, bis er seinen "Lieblingsweg" findet. Das können nachher aber auch noch mehrere bleiben.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Ich fasse mal zusammen:
Etwas Hausverstand beim Programmieren und über die Konseqnezen nachdenken (Blick über den Tellerrand) würden schon reichen.
Und natürlich auch Kunden, die bereit sind das Know-How kaufen zu wollen und nicht nur einen Codeneger wollen und eh alles selbst besser wissen (wie das so üblich ist).
Mit LIKE allein wirst du nicht weit kommen
Wenn der Eintrag passend ist, wird es das. Ich schliesse beispielsweise die Gruppen in einer Rechtespalte mit | ein und trenne sie mit |. Dann suche ich per LIKE %|234|% und bekomme genau diesen Eintrag.
Wenn am Anfang und am Ende kein Trenner eingefügt wurde, hast du natürlich Recht, das hab ich anfangs gelernt und deshalb das Konzept geändert ;)
Für Tags wäre vermutlich eine Indextabelle besser, die die Tagnamen enthält und dann die zugehörigen Artikelindizies zur Verfügung stellt. Hab mich aber mit solchen Systemen nie befasst.
Om nah hoo pez nyeetz, Juppsi!
Rein strukturell müssen die Inhalte von Datensätzen im Sinne der Normalisierung atomar sein:
Entity -- Relationship -- Entity
Deutschland -- exportiert -- Kaffee
Österreich -- exportiert -- Kaffee; Tee
Die Abfrage, wer Kaffee exportiert, würde also nur Deutschland liefern, da "Kaffee; Tee" nicht gleich "Kaffee" ist.
Man kann also in einem solchen Fall keine 1:n-Beziehung verwenden, sondern muss auf n:m ausweichen.
Siehe auch ERM
Glücklicherweise brauchen jedoch solche Tags keine Entitys zu sein, es reicht eine Zeichenkette. Und für solche Fälle gibt es dann in der SQL-Abfrage LIKE. Wenn man jetzt konsequent immer z.B. ein Semikolon nach jedem Wort setzt, kann man sogar "Angel" von "Angela" unterscheiden tabelle.feld LIKE Angel;
Matthias
Tach!
Häufig kann man ja mittlerweile "Tags" angeben. Wenn ich also eine Nachricht über Griechenland eingebe, könnte ich als Tags zum Beispiel "Athen; Finanzkrise" eingeben.
In meiner Vorstellung steht das dann auch so in der Datenbank (ich gehe mal von MySQL aus).
Es mag ja sein, dass du sie mit Semikolon getrennt in ein Eingabefeld eingibst, aber sie so zusammen im DBMS abzulegen ist sehr ungünstig. Denn wenn du Abfragen nach einzelnen Tags stellst, musst du dabei immer die zusammenstehenden Information auftrennen. Das geht zwar irgendwie, ist aber recht aufwendig, weil das bei jeder Abfrage mit jedem Datensatz passieren muss und somit die Verwendung eines Index nicht möglich ist. Na gut, ein Volltextindex könnte gehen. Dadurch wird es aber insgesamt nicht besser. Bei Aufgaben wie "Liste aller Tags" bekommst du dann langsam ernste Probleme. Besser ist, eine m:n-Beziehung zu implementieren. In einer Tabelle stehen die Artikel, in einer anderen stehen alle Tags, aber jeder nur einmal. In einer dritten Tabelle stehen die Zuordnungen zwischen Artikel und Tags über deren IDs.
Wenn ich das jetzt auf mein Problem übertrage, dann würde ich auch gerne solche Tags verwenden. Aber der Sinn dieser Tags besteht doch sicherlich darin, dass ich z. B. alle Nachrichten anzeigen lasse, in denen die Tags "Athen" stehen.
Mit der m:n-Beziehung geht das jedenfalls so: Liste alle Nachrichten, zu deren ID in der Zuordnungstabelle ein Datensatz existiert, dessen Tag-ID der von Athen entspricht.
dedlfix.
Hallo dedlfix,
Besser ist, eine m:n-Beziehung zu implementieren. In einer Tabelle stehen die Artikel, in einer anderen stehen alle Tags, aber jeder nur einmal. In einer dritten Tabelle stehen die Zuordnungen zwischen Artikel und Tags über deren IDs.
Im Falle von Tags sehe ich das ähnlich wie im Fall von Straßennamen:
Die "Hauptstraße" in Buxtehude hat mit der Hauptstraße in Berlin-Spandau nichts zu tun, obwohl sie den gleichen Namen tragen. Ich käme auch nicht auf die Idee, eine Tabelle mit Straßennamen anzulegen und in einer Adresstabelle nur die entsprechende ID des Straßennamens abzuspeichern.
Für mich sind Schlagworte nur ein Attribut und keine Entität (blödes Wort).
Freundliche Grüße
Vinzenz
Tach!
Für mich sind Schlagworte nur ein Attribut und keine Entität (blödes Wort).
Okay, du hast mich überzeugt, dass eine extra Tag-Tabelle nicht nötig ist. (Aber nimm doch bitte die in diesem Fall richtige Mehrzahl: Schlagwörter.)
dedlfix.
Hallo dedlfix,
Für mich sind Schlagworte nur ein Attribut und keine Entität (blödes Wort).
Okay, du hast mich überzeugt, dass eine extra Tag-Tabelle nicht nötig ist.
Das ist besser als überredet :-)
(Aber nimm doch bitte die in diesem Fall richtige Mehrzahl: Schlagwörter.)
Oh je, das stimmt! Mit dem Plural von "Wort" hab' ich mir schon immer schwer getan, Hochdeutsch war schließlich die erste Fremdsprache, die ich lernen musste ...
Freundliche Grüße
Vinzenz
(Aber nimm doch bitte die in diesem Fall richtige Mehrzahl: Schlagwörter.)
Ich komm grade nicht mit: welche Regeln sind für die Verwendung der beiden Plural-Formen von "Wort" (also Wörter und Worte) zuständig?
Hello,
(Aber nimm doch bitte die in diesem Fall richtige Mehrzahl: Schlagwörter.)
Ich komm grade nicht mit: welche Regeln sind für die Verwendung der beiden Plural-Formen von "Wort" (also Wörter und Worte) zuständig?
Ich lese immer gerne Deine Worte über die fachlichen Zusammenhänge.
Aber manche Wörter im Text verstehe ich gelegentlich niocht sofort.
"Worte" habenn einen inneren Zusammenhang, könnten also (fast) schon einen Satz darstellen.
"Wörter" sind eine lose Anreihung unzusammenhängender Begriffe.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Om nah hoo pez nyeetz, Tom!
"Worte" habenn einen inneren Zusammenhang, könnten also (fast) schon einen Satz darstellen.
Ganze Reden!
Matthias
Hello,
"Worte" habenn einen inneren Zusammenhang, könnten also (fast) schon einen Satz darstellen.
Ganze Reden!
Stimmt. Reden müssen ja auch nicht immer aus ganzen Sätzen bestehen :-)
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Ich lese immer gerne Deine Worte über die fachlichen Zusammenhänge.
Aber manche Wörter im Text verstehe ich gelegentlich niocht sofort."Worte" habenn einen inneren Zusammenhang, könnten also (fast) schon einen Satz darstellen.
"Wörter" sind eine lose Anreihung unzusammenhängender Begriffe.
"Preiß" :)
Aber danke für die Aufklärung.
Hi,
Die "Hauptstraße" in Buxtehude hat mit der Hauptstraße in Berlin-Spandau nichts zu tun, obwohl sie den gleichen Namen tragen.
wenn jemand "Hauptstraße" sucht, sind sie beide gleichwertig. Sucht jemand "Hauptstraße;Buxtehude", so sollten vorwiegend Einträge angezeigt werden, auf die beide Tags zutreffen. Umgekehrt ist es ähnlich - da Tags nicht hierarchisch sind, sondern alle die selbe Kraft haben, haben die Hauptstraße in Buxtehude und die Admiral-von-Schneider-Allee in Buxtehude sehr wohl etwas miteinader zu tun; sie gehören beide zum Tag "Buxtehude".
Ich käme auch nicht auf die Idee, eine Tabelle mit Straßennamen anzulegen und in einer Adresstabelle nur die entsprechende ID des Straßennamens abzuspeichern.
Ich schon, wenn der Zweck des ganzen ist, gleichnamige Straßen zusammenzuführen.
Berühmte schwäbische Straße mit drei "o": Bohofstroß.
Für mich sind Schlagworte nur ein Attribut und keine Entität (blödes Wort).
Für mich sind Datenbanken Mengen von Verknüpfungen von Mengen.
Cheatah
Hello,
Die "Hauptstraße" in Buxtehude hat mit der Hauptstraße in Berlin-Spandau nichts zu tun, obwohl sie den gleichen Namen tragen. Ich käme auch nicht auf die Idee, eine Tabelle mit Straßennamen anzulegen und in einer Adresstabelle nur die entsprechende ID des Straßennamens abzuspeichern.
Stimmt. Hier darf nicht bedingungsfrei normalisiert werden. Es handelt sich bei der Tabelle, in der "Hauptstraße" gelistet wird, um Basisstammdaten. Für Basisstammdaten gilt der Grundsatz "angelegt bleibt angelegt", gelöscht oder geändert werden darf nicht mehr. Es darf nur die Referenz auf den Basisdatendatz geändert werden. Und das geht ja auch in diesem Beispiel.
Puristen vertreten sogar die Meinung, dass auch keine Fehler geändert (sic!) werden dürfen in einem solchen Basisdatensatz, sondern auch in diesem Falle ein neuer angelegt werden muss (mit Metadaten) und alle _betroffenen_ Verweise ebenfalls geändert werden müssen, und zwar per kontrollierter Änderung (also Sichtvornahme oder "superschlaue Funktion"). Denn anderenfalls könnte man den einen Fehler tatsächlich nur gegen den anderen geändert haben.
Die Normalisierungsprofis sagen mir hierzu: hier hört der Spaß in der Praxis auf, hier wird einfach nicht weiter normalisiert, weil "Hauptstraße" selber hier einfach als mehrwertiger Schlüssel der Eigenschaft angesehen wird. Man erspart sich eine ganze Menge Arbeit, wenn man direkt den Wert benutzt.
Für mich sind Schlagworte nur ein Attribut und keine Entität (blödes Wort).
Und "Hauptstraße" kennzeichnet keine Identität!
(und siehe oben) ...warum ich Vizenz hier zustimme.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hallo,
Häufig kann man ja mittlerweile "Tags" angeben. Wenn ich also eine Nachricht über Griechenland eingebe, könnte ich als Tags zum Beispiel "Athen; Finanzkrise" eingeben.
dann sollten dieser Nachricht in einer Zuordnungstabelle zwei Einträge zugeordnet werden:
Tabelle "tags"
news_id | tag
----------------------
4711 | Athen
4711 | Finanzkrise
Und nein, es wäre keine gute Idee, die Tags noch einmal in einer Nachschlagetabelle abzuspeichern:
Tabelle "news_tags"
news_id | tag_id
-----------------
4711 | 258
4711 | 107
Tabelle tags
tag_id | tag
------------------
258 | Athen
107 | Finanzkrise
denn das Schlagwort "Athen" in Zusammenhang mit der Finanzkrise in Griechenland hat nichts mit dem Schlagwort "Athen" mit einem Artikel über das alte Griechenland zu tun. Hat sich derjenige, der verschlagwortet, vertan - und ändert das Schlagwort beim Antike-Artikel in "Athene" ab, so darf sich das Schlagwort beim Finanzkrisenartikel ja nicht ebenfalls ändern.
Ein Index über die tag-Spalte genügt vollständig, um schnell die Artikel zu einem bestimmten Schlagwort zu finden.
Geht das denn theoretisch? Also reicht da eine Trennung mit Semikolon, um eine WHERE-Abfrage in MySQL zu starten, die sich letzten Endes nur auf "Athen" konzentriert, obwohl da auch noch "Finanzkrise" mit in der Zeile steht?
Es wäre eine extrem bescheidene Idee in der Nachrichtentabelle eine Spalte "tags" zu haben, in der die Schlagworte per Trennzeichen getrennt ständen.
news_id | news_text | tags
----------------------------------------------------
4711 | Die Finanzkrise ... | Athen;Finanzkrise
Dann liegen die Daten in der Spalte tags nicht atomar vor. Das ist ein Vestoß gegen die Normalisierungsregeln und somit klares Anzeichen von miserablem Tabellendesign:
Athen ließe sich jetzt über einen Index noch schnell finden, Finanzkrise nicht mehr - außer über einen Volltextindex. Schlagworte sind jedoch ganz genau dazu da, einen Volltextindex *nicht* zu benötigen, und dennoch die gewünschten Artikel zu finden.
Freundliche Grüße
Vinzenz
Hi Vinzenz, wenn ich hier von der Insel 'n Bienchen vergeben koennte, wuerd ich dir glatt eins verpassen. Sehr schoen beschrieben!!! Cheers, Frank
Tach!
dann sollten dieser Nachricht in einer Zuordnungstabelle zwei Einträge zugeordnet werden:
Und nein, es wäre keine gute Idee, die Tags noch einmal in einer Nachschlagetabelle abzuspeichern:
denn das Schlagwort "Athen" in Zusammenhang mit der Finanzkrise in Griechenland hat nichts mit dem Schlagwort "Athen" mit einem Artikel über das alte Griechenland zu tun. Hat sich derjenige, der verschlagwortet, vertan - und ändert das Schlagwort beim Antike-Artikel in "Athene" ab, so darf sich das Schlagwort beim Finanzkrisenartikel ja nicht ebenfalls ändern.
Das darf in keinem (Änderungs-)Fall passieren. Wenn die Tags für den User in einem Feld präsentiert werden, und nicht jeder Tag in einem eigenen, dann müssen auch Änderungen möglich sein, wie Athen ganz weg und dafür Griechenland rein, ohne dass dabei sämtliche Athens zu Griechenland mutieren. Deswegen muss man beim Ändern der Tags eines Artikels erst die alten Zuordnungen löschen und dann neue erstellen. Dasselbe Vorgehen wird auch bei der Variante ohne Nachschlagetabelle benötigt. Zumindest ist das einfacher, als zu prüfen, welche geblieben sind und welche sie geändert haben. Bei der Datenpflege sehe ich da grad keinen Vorteil der ersten Variante. Für sie spricht hingegen, dass die Abfragen um einen Verknüpfungsschritt einfacher werden. Und "Liste aller Tags" bekommt man mit DISTINCT hin.
dedlfix.
Hi,
Und nein, es wäre keine gute Idee, die Tags noch einmal in einer Nachschlagetabelle abzuspeichern:
doch, wäre es.
denn das Schlagwort "Athen" in Zusammenhang mit der Finanzkrise in Griechenland hat nichts mit dem Schlagwort "Athen" mit einem Artikel über das alte Griechenland zu tun. Hat sich derjenige, der verschlagwortet, vertan - und ändert das Schlagwort beim Antike-Artikel in "Athene" ab, so darf sich das Schlagwort beim Finanzkrisenartikel ja nicht ebenfalls ändern.
Ein vorhandener Tag wird nie geändert, sondern höchstens gelöscht.
Ein Index über die tag-Spalte genügt vollständig, um schnell die Artikel zu einem bestimmten Schlagwort zu finden.
In einer idealen Datenbank wiederholen sich ausschließlich Referenzen, niemals aber Daten. Das kann man natürlich bis zum Extrem treiben, was potenziell ziemlich sinnlos ist; aber welchen Vorteil sollte man davon haben, Begriffe wie "Weltwirtschaftskrise" tausendfach abgespeichert zu haben?
Der Vorgang, Referenzen zu löschen, ist übrigens der selbe wie der, der bei dem von Dir vorgeschlagenen Modell nötig wäre. Es ist dadurch nichts gewonnen.
Cheatah
