nicht angemeldet
Zwei unabhängige Tabellen in einer Abfrage?
Hallo,
habe eine MySQL Datenbank mit diversen Tabellen - die meisten sind irgendwie untereinander verknüpft. Nun stehe ich vor dem Problem zwei Tabellen in einer Abfrage abzufragen (schönen Gruß an den Deutschlehrer...) die nicht mit Primary SecondaryKey o.ä. verknüpft sind. Gibt es da eine gute Lösung ohne Zwischentabelle?
z.B. in einer Tabelle habe ich eine Liste von kommenden Konzerten in Eruopa. In der anderen Liste habe ich eine Tabelle von Journalisten in Europa. Jetzt möchte ich jedem Journalisten eine E-Mail schicken mit den Konzertterminen in seinem Land.
Sprich aus der einen Tabelle wähle ich Künstler, Land, Stadt und Termin aus. Aus der anderen Tabelle wähle ich Journalisten_Name, Email und Land aus.
Dann vergleiche ich Land aus Journalisten muß gleich sein Land aus Konzerttermine. Aber natürlich gibt es n Konzerte in einem Land und m Journalisten.
Hat jemand eine gute Idee? Habe ich irgendetwas übersehen, oder geht das nur mit Zwischentabelle?
Danke für die Hilfe und beste Grüße,
Jason
-
Hi,
habe eine MySQL Datenbank mit diversen Tabellen - die meisten sind irgendwie untereinander verknüpft.
nur in Deiner Vorstellung (Deinem Wissen), weil MySQL äh keine Foreign Keys kennt. Selbst wenn, müsste die Beziehung trotzdem explizit genannt werden.
z.B. in einer Tabelle habe ich eine Liste von kommenden Konzerten in Eruopa. In der anderen Liste habe ich eine Tabelle von Journalisten in Europa. Jetzt möchte ich jedem Journalisten eine E-Mail schicken mit den Konzertterminen in seinem Land.
Also hast Du eine Verknüpfung über die Länder-Spalte beider Tabellen. Was willst Du mehr?
Cheatah
-
Hallo Cheatah,
nur in Deiner Vorstellung (Deinem Wissen), weil MySQL
äh keine Foreign Keys kennt. Selbst wenn, müsste die
Beziehung trotzdem explizit genannt werden.diese Aussage war schon bei ihrer letzten Erwähnung durch Dich nicht mehr richtig ...
Viele Grüße
MichaelP.S.: Diese Woche ging eine Veröffentlichung raus, daß der (vollständig transaktionsfähige) InnoDB-Tabellentreiber nun zur Grundauslieferung von mySQL gehört. Es geht voran ...
-
Hi,
nur in Deiner Vorstellung (Deinem Wissen), weil MySQL
äh keine Foreign Keys kennt. Selbst wenn, müsste die
Beziehung trotzdem explizit genannt werden.diese Aussage war schon bei ihrer letzten Erwähnung durch Dich nicht mehr richtig ...
ich gehe von den üblicherweise installierten Systemen aus. Dass jemand eine _so_ neue MySQL-Version einsetzt, ist selten.
Cheatah
-
Hi,
danke erstmal.
Als ich bei einem meiner letzten Postings (schon länger her) geschrieben habe, daß MySql keine FKs unterstützt habe ich bitterböse Antworten erhalten das dies ein schmarrn sei, nun ja wie man's macht macht man's falsch....Zur Antwort natürlich habe ich mehr oder weniger eine Verknüpfung über die Länder - aber das ist ja einen n zu m Verknüpfung und das Ergebniss müßte ja ein ziemlich überdimensioniertes Array sein - oder sehe ich das falsch? - Kann man da was über join machen(mit diesem "Befehl" kenne ich mich leider noch nicht wirklich aus)?
GRüße,
-
Hi,
Zur Antwort natürlich habe ich mehr oder weniger eine Verknüpfung über die Länder - aber das ist ja einen n zu m Verknüpfung und das Ergebniss müßte ja ein ziemlich überdimensioniertes Array sein - oder sehe ich das falsch?
ja, siehst Du :-) Es kommt immer etwas zweidimensionales raus: a Zeilen mit je b Spalten. Wenn hierbei über mehrere Zeilen hinweg einige der Spalten identisch bleiben, ist das so richtig.
- Kann man da was über join machen(mit diesem "Befehl" kenne ich mich leider noch nicht wirklich aus)?
Ein Join ist im großen und ganze nicht mehr als ein "WHERE tabelle_1.spalte_1 = tabelle_2.spalte_2".
Cheatah
-
Hallo Jason,
Du solltest Dich einfach dafür entscheiden, welches Deine "Linke Tabelle" und welches die "rechte Tabelle" ist.
Die Führung geht immer von der "Linken Tabelle" aus. Diese darfst Du in chaotischer Reihenfolge durcharbeiten und die "Rechte Tabelle" muss die dazu passeden Datensätze (DISTINCT ROWS) liefern.
Am sinnvollsten sit sicherlich, die Journalisten zu den "Linken" zu erklären, denn Du willst denen ja nur EINE MAIL mit jeweils mehreren passenden Konzerthinweisen schicken.
Andersherum wäre es, wenn Du die Konzerte eines Gebietes als "Linke Tabelle" deklarierst, dass du pro Konzert mehrere emails mit verschiedenen Empfängern generierst. Das wird bei den Journs aber bestimmt bald sauer aufstoßen.
Da du immer nur Teilmengen verarbeiten kannst, würde ich also ein Script für die VORGANGSVERARBEITUNG erstellen, dass die Konzerte nach links nimmt.
Die Schleife mit der Abfrage erfasst dann immer genau einen Jounalisten und die dazu passenden Konzerte. Also einen "Schritt" in der Journalistentabelle und ein Query auf die Konzerttabelle.
Wenn Deine Datenbank mehrplatz-dialogfähig ist, dann solltest Du zusätzlich eine Kontrolltabelle schreiben, in der Du die pro Info-Nummer (Aufruf des Vorgangs-Scriptes) einen Krontrolldatensatz für jede Journalisten-Konzertpaarung schreibst. Sollte nämlich während des Blätterns von einem zum nächsten "hinter Dir" einer dazugekommen sein, würde der ja keine Info erhalten haben. Den musst Du dann im Kontrolldurchgang erfassen. Wieviele Kontrolldurchgänge du machst, hängt von der Anzahl der Veränderungen der "Linken Tabelle" _während_ der Verarbeitung ab.
Bei Single-User-Betrieb oder Sperre der Tabellen während der Vorgangsbearbeitung ist der Aufwand sicher nicht nötig.
Du solltest aber unter der Info-Nummer erst die Kontrolldatensätze erstellen, und erst aus dieser Tabelle die Verarbeitung (email- Erzeugung) vornehmen. Überleg dir die möglichen Inkonsistenzen:
Solange in der Vorgangstabelle noch unbearbeitete Datensätze (Merker) enthalten sind, dürfen die beteiligten Datensätze der beiden m:n-Tabellen nicht gelöscht werden.
Die Erzeugung der m:n-Tabelle geht selbst bei großen Datenbeständen sehr schnell. Die Abarbeitung kann dann mehrere Stunden dauern.
Grüße aus http://www.braunschweig.de
Tom
-
-
Hi Cheatah,
nur in Deiner Vorstellung (Deinem Wissen), weil MySQL
äh keine Foreign Keys kennt. Selbst wenn, müsste die
Beziehung trotzdem explizit genannt werden.diese Aussage war schon bei ihrer letzten Erwähnung durch Dich nicht mehr richtig ...
ich gehe von den üblicherweise installierten Systemen aus. Dass jemand eine _so_ neue MySQL-Version einsetzt, ist selten.
wenn es für die Lösung eines konkreten Problems das entscheidende Kriterium ist, dann ist mySQL sehr schnell auf eine aktuelle Version upgegraded.
Für die typischen Webworker-Wald-und-Wiesen-Probleme ist referentielle Integrität eher kein Thema - deshalb gehe _ich_ bei solchen Fragen davon aus, daß ich mir eine eigene Datenbank(-version) für meine Problemstellung instalieren darf, wenn ich die brauche.
Und das stellt Deine pauschale Aussage grundlos in Abrede.
Viele Grüße
Michael
-
-
Guten Tag Michael,
nur in Deiner Vorstellung (Deinem Wissen), weil MySQL
äh keine Foreign Keys kennt. Selbst wenn, müsste die
Beziehung trotzdem explizit genannt werden.diese Aussage war schon bei ihrer letzten Erwähnung durch Dich nicht mehr richtig ...
P.S.: Diese Woche ging eine Veröffentlichung raus, daß der (vollständig transaktionsfähige) InnoDB-Tabellentreiber nun zur Grundauslieferung von mySQL gehört. Es geht voran ...
bedeutet das, dass MySQL in Zukunft die referenzielle Integirtät beherrscht, so wie "Access" das z.B. anbietet?
- Kontrolle der Integrität
- Offenlegung der Integritätsverletztung bei Verstößen
- Löschverhalten
- Schlüsselweitergabe bei Änderung des Primärschlüssels
Wo kann ich was darüber nachlesen? hast Du nen Tipp?
Grüße aus http://www.braunschweig.de
Tom
-
Wo kann ich was darüber nachlesen? hast Du nen Tipp?
-
-