SQL SQL - Mehrfacheinträge in richtiger Reihenfolge selektieren

[razhthak]

Hallo,

habe ein Problem in MySQL: Ich habe eine Abfrage, die unter umständen bestimmte Einträge (IDs) mehrfach enthält. Nun filtert MySQL diese mehrfachen Einträge weg und gibt jeden Eintrag nur einmal aus.

Ich möchte aber alle Werte in ihrer Reihenfolge selektiert haben - auch mehrfach.... ist das möglich?

Hier die Abfrage:

SELECT * FROM lexikon WHERE name IN('A','B','C','D','B','A','F','C','B') ORDER BY FIELD(name, 'A','B','C','D','B','A','F','C','B')

 

[Jesterfox]

Selektier jeden Datensatz einzeln und häng sie mit UNION ALL zusammen. Oder überdenk nochmal das Datenmodell, klingt irgendwie krank was du da vor hast ;-)

 

[razhthak]

Naja, Hintergrund ist, ich möchte auf einer Webseite ein Live-Glossary der Fachbegriffe anbieten. Dazu sind diese Fachbegriffe und Abkürzungen in einem abbr-Tag erfasst.

Nun sucht eine Javascript-Funktion alle abbr-Tags, und übergibt deren Inhalte per AJAX an eine PHP-Datei, die dazu die Beschreibungen liefern soll. Daher ist wichtig, dass die Reihenfolge immer stimmt, da eine Abkürzung durchaus auch mehrfach in einem Text vorkommen kann.

Natürlich könnte ich auch X Einzelabfragen tätigen - das will ich aus Performancegründen jedoch vermeiden (längere Texte)...

 

[Xport]

WHERE name IN('A','B','C','D','B','A','F','C','B')

Das ist schon mal - sorry - Unfug, weil "<bezeichner> IN (..)" eindeutige Kriterien erwartet und auswertet, und zwar genau nur zu TRUE (bei wenigstens einem Treffer) oder FALSE (bei lauter "Fahrkarten"). Also nichts weiter als eine elegantere Form von "OR" -> ob da nun ein(1) mal 'A' drin steht oder mehrmals, ändert am Ergebnis nichts.

ORDER BY ...

Diese Klausel sortiert das Ergebnis nach dem Inhalt der angegebenen Felder - gibst Du hier "Name" an, kommen die Ergebnisse in der Reihenfolge, wie sich die Inhalte von "Name" lexikalisch und entsprechend der eingestellten Sortierfolge aufsteigend darstellen würden. Literale sind hier bestenfalls wirkungslos, im Zweifel hebeln sie jedoch eine Sortierung komplett aus.

Beides ist *nicht* grundsätzlich Ursache für das Fehlen von Einträgen, und ich denke es ist beides nicht das, was Du beabsichtigst. Man müsste wenigstens die Daten kennen ...

 

[andy_0]

Ich verstehe das nicht. Wieso soll die SQL DB da was filtern? Ein SQL SELECT Statement liefert die Daten exakt wie sie stehen - außer sie werden speziell sortiert. Die einzelnen Felder zu jeweils einer Spalte zu machen ist - pardon - WAHNSINNIG. In SQL speichert man Daten "zeilenbasiert", nicht "spaltenbasiert" (d.h. "Ein eindeutiger Wert in eine Zeile").

Die Tabelle mit den Einträgen sollte also grob so aussehen:
Table: SiteElements
ID: Int (PK)
SiteID: int (FK)
FieldOrder: int
FieldID: int (FK)

Zu SiteID und FieldID gibt es dann jeweils eine extra Tabelle mit deren Details also z.B.:
SIteID: int (PK)
SiteDescription

Ein SELECT * FROM SiteElements gibt dann sämtliche EInträge raus. Filterst du nach SiteID = 1 bekommst du alle EInträge für die Seite 1, mit ORDER BY FIeldOrder bekommst du die Einträge der Reihe nach.

 

[Jesterfox]

@Xport: doch, genau das Verhalten von IN() ist sein Problem, weshalb etwas "fehlt", er erwartet Einträge doppelt wenn er diese mehrfach im IN nennt. Das geht aber eben nicht...

@TE: wenn du keine Mehrfachabfragen mit UNION willst musst du die Programmlogik umbauen. Wäre auch mein Tipp, da es das ganze robuster macht. Rechne nicht mit einer Reihenfolge oder Mehrfachnennungen bei der Rückgabe, sondern suche dir aus dem Rückgabeergebnis anhand der Abkürzung jeweils das gesuchte Textstück raus. Dann kann dir die Reihenfolge egal sein und es muss auch keine mehrfachen Datensätze geben (spart auch noch Traffic)

 

[Daaron]

Naja, Hintergrund ist, ich möchte auf einer Webseite ein Live-Glossary der Fachbegriffe anbieten. Dazu sind diese Fachbegriffe und Abkürzungen in einem abbr-Tag erfasst.

Das ist semantischer Unsinn. <abbr> enthält Abkürzungen und optional deren Bedeutung, ist aber NICHT für Glossar-Einträge gedacht. Dafür gibt es <dfn> und in gewissem Rahmen auch <dl>.
Außerdem ist es hinsichtlich Ladezeit, Barrierefreiheit und SEO ziemlicher Murks, die Beschreibung eines Wertes per JS nachzuladen.