nicht angemeldet
komplexere SQL-Abfrage, (Anfänger)
Hallo,
ich befasse mich gerade neu mit SQL-Abfragen, weiß also noch nicht so viel dazu. Für eine MySQL-Datenbank, die ich hauptsächlich lokal nutzen möchte (MySQL 4.1x), möchte ich komplexe Suchabfragen formulieren.
Ich würde das Ergebnis bekommen, theoretisch!, wenn ich 2 Abfragen formulieren würde, wobei die 2. nur die Ergebnismenge der 1. durchsuchen darf.
-
SELECT feld_id FROM tabelle_1 WHERE feld_gruppe = A
-
SELECT feld_x FROM [alle mit Gruppe=A in tabelle_2] WHERE feld_y LIKE suchwort
Also, wenn jetzt jemand sagen möchte, das die Tabellen anders aufgebaut werden sollten, (so habe ich das vorhin mal im Archiv gelesen) kann ich nur sagen, das ich hier erstmal das Prinzip von solchen Abfragen verstehen möchte. Weiterhin denke ich, wenn ich die Datenbank erst einmal mit Daten gefüllt habe (Musiksammlung mit Genre, Dateiname, und den nützlichsten ID3-Tags) Dann ist es bestimmt (?) schneller, erst in der 1. Tabelle alle IDs zu einer Gruppe zu sammeln und nur diese dann in Tabelle2 nach einem Suchwort in (1, 2, 3) bestimmten Feld/ern (oder in allen Feldern) zu durchsuchen. (Oder nicht?)
Gruß,
Chuchan
-
Hallo Chuchan,
Ich würde das Ergebnis bekommen, theoretisch!, wenn ich 2 Abfragen formulieren würde, wobei die 2. nur die Ergebnismenge der 1. durchsuchen darf.
sorry, das verstehe ich nicht.
- SELECT feld_id FROM tabelle_1 WHERE feld_gruppe = A
Betrachtest Du das als tabelle_2?
- SELECT feld_x FROM [alle mit Gruppe=A in tabelle_2] WHERE feld_y LIKE suchwort
Wenn ja, es gibt die AND-Verknüpfung :-)
Am allerbesten ist es jedoch, wenn Du uns Deine Tabellen mit den relevanten Spalten kurz vorstellst, mit ein paar Beispieldatensätzen und daran zeigst, was Du gerne hättest.
[...] Dann ist es bestimmt (?) schneller, erst in der 1. Tabelle alle IDs zu einer Gruppe zu sammeln und nur diese dann in Tabelle2 nach einem Suchwort in (1, 2, 3) bestimmten Feld/ern (oder in allen Feldern) zu durchsuchen. (Oder nicht?)
Für soetwas verwendest Du entweder Joins oder Subselects. Deine MySQL-Version ist neu genug, um Subselects zu unterstützen. Normale Joins stellen auch kein Problem dar, erst wenn es zu komplexeren Join-Operationen kommt, versagt MySQL 4.1.x.
Ich empfehle Dir zu Joins zwei Artikel:
Einführung Joins
Fortgeschrittene JoinsFreundliche Grüße
Vinzenz
-
Hallo Vinzenz,
Für soetwas verwendest Du entweder Joins oder Subselects. Deine MySQL-Version ist neu genug, um Subselects zu unterstützen. Normale Joins stellen auch kein Problem dar, erst wenn es zu komplexeren Join-Operationen kommt, versagt MySQL 4.1.x.
OK, _so_ komplex wird es hier nicht werden, ;-).
(Ich habe im Postingtitel 'komplex' geschrieben, weil das für _mich_ komplex ist, aber ich verstehe ja auch nichts von der Materie).Ich empfehle Dir zu Joins zwei Artikel:
Vielen Dank für die Links, das ist erstmal Input genug.
Gefällt mir sehr, das es in den Artikeln viele erklärte, aufeinander aufbauende Beispiel-Formulierungen gibt. Cool! Gute Arbeit.Gruß,
Chuchan
-
Abend!
Ich würde das Ergebnis bekommen, theoretisch!, wenn ich 2 Abfragen formulieren würde, wobei die 2. nur die Ergebnismenge der 1. durchsuchen darf.
=> Sub-SELECTs recherchieren!
Dann ist es bestimmt (?) schneller, erst in der 1. Tabelle alle IDs zu einer Gruppe zu sammeln und nur diese dann in Tabelle2 nach einem Suchwort in (1, 2, 3) bestimmten Feld/ern (oder in allen Feldern) zu durchsuchen. (Oder nicht?)
Hört sich nicht gut an, eine DB-Tabelle hat eine ID und bildet eine Entität nach. Entitäten sollten nur in absoluten Ausnahmefällen über mehr als eine DB-Tabelle abgebildet werden.
Grüsse!
-
Tag!
=> Sub-SELECTs recherchieren!
Danke, bin dabei, (incl. JOINS)!
Hört sich nicht gut an, eine DB-Tabelle hat eine ID und bildet eine Entität nach. Entitäten sollten nur in absoluten Ausnahmefällen über mehr als eine DB-Tabelle abgebildet werden.
Hhm, verstehe ich nicht?
Ich habe mir im Vorfeld einige bekannte PHP-Programme angeschaut, und festgestellt das die alle mit mehreren Tabellen arbeiten, immer ähnlich aufgeteilt wie ich das jetzt versuchen will.Gruß,
Chuchan-
yo,
Hört sich nicht gut an, eine DB-Tabelle hat eine ID und bildet eine Entität nach. Entitäten sollten nur in absoluten Ausnahmefällen über mehr als eine DB-Tabelle abgebildet werden.
Hhm, verstehe ich nicht?
Ich habe mir im Vorfeld einige bekannte PHP-Programme angeschaut, und festgestellt das die alle mit mehreren Tabellen arbeiten, immer ähnlich aufgeteilt wie ich das jetzt versuchen will.vergiss einfach die aussage, verwirrt nur und stimmt so auch nicht.
Ilja
-
hoi,
Hört sich nicht gut an, eine DB-Tabelle hat eine ID und bildet eine Entität nach. Entitäten sollten nur in absoluten Ausnahmefällen über mehr als eine DB-Tabelle abgebildet werden.
Hhm, verstehe ich nicht?
vergiss einfach die aussage, verwirrt nur und stimmt so auch nicht.
OK!
Gruß,
Chuchan -
Hört sich nicht gut an, eine DB-Tabelle hat eine ID und bildet eine Entität nach. Entitäten sollten nur in absoluten Ausnahmefällen über mehr als eine DB-Tabelle abgebildet werden.
Hhm, verstehe ich nicht?
Ich habe mir im Vorfeld einige bekannte PHP-Programme angeschaut, und festgestellt das die alle mit mehreren Tabellen arbeiten, immer ähnlich aufgeteilt wie ich das jetzt versuchen will.vergiss einfach die aussage, verwirrt nur und stimmt so auch nicht.
Die Aussage bezog sich möglicherweise auf das entity relationship model und dessen Implementierung in den heutigen RDBMSen. Was stimmt denn "so auch nicht"?
-
-
-