SQL mehrere Tabellen in eine grosse Tabelle zusammenfassen(ohne Join)?
Hallo zusammen, ich möchte gerne mehrere grosse SQL Tabellen in eine grosse Tabelle zusammenfassen, würde es gehen wenn ja wie?
6 Antworten
Man hat so etwas schonmal, wenn man z.B. Ansprechpartner von Lieferanten und Ansprechpartner von Kunden in einer Ansicht zusammen anzeigen möchte. Dann ist zwar im Vorfeld ein Fehler im Datenbankdesign gemacht worden - aber es gibt halt solche Fälle.
Grundsätzlich ersteinmal über eine UNION Abfrage die Daten in einer Sicht zusammenführen. Also z.B. "Select * From KundenAP UNION Select * From LieferantenAP" . Dann sieht man alle in einer Eirgebnissicht. Wenn Du dies dann in eine Tabelle überführen möchtest, kannst Du eine Tabellenerstellungsabfrage auf Basis der UNION Abfrage bauen. Sinnhaftigkeit, oder Alternativen natürlich ausgeblendet. VG, Armin
genau - wenn man eine UNION Abfrage verwendet/benötigt heißt das nicht automatisch, dass das Design schlecht ist. Kann vielfältige Gründe haben. Wir hatten dies einmal bei Datenbanken für große Mailings. Da hat die Firma eigene Adressen und kauft noch welche zu, z.B. von Schoba, oder so. Diese Daten will man dann auch zusammen bringen
Aber ein union würde bedingen, dass die Tabelle KundenAP und die Tabelle LieferantenAP identische Spalten beinhalten. Außerdem würden dadurch die Ergebniszeilen beeinflusst und nicht die Spalten, wie das bei einem join beispielsweise der Fall wäre.
richtig! Wenn es nicht passt von den Feldnamen her, dann mit einem Alias arbeiten. Und Daten sollten mit definierten Feldern nach unten wachsen, nicht in die Breite - sonst kann man auch mit Excel basteln
Nun, wenn ich beispielsweise wissen möchte, welche Artikel der Kunde bestellt hat und in der Bestellung sinnvollerweise nur eine Liste der Artikelnummern habe, aber auch die Artikelbezeichnung brauche, hat es nichts mit Bastelei zu tun, mir die Artikelbezeichnung per JOIN als zusätzliche Spalte geben zu lassen, sondern das ist sogar (im Vergleich zu einen UNION) die einzig sinnvolle Lösung.
Alles klar - Join war ja explizit nicht gewünscht. Ich kenne auch den Anwendungsfall nicht - wollte nur helfen.
Klar! Dagegen sage ich doch auch nichts - wir diskutieren doch gerade mögliche Anwendungsfälle :-)
JOINs sind schon die effizienteste Methode um Tabellen zu verknüpfen, genau dafür sind sie halt da. Je nach Aufgabe stellt sich natürlich die Frage ob sich die Daten ändern oder nicht und ob man das Ergebnis des JOINs für mehrere Verwendungen cached, sei es während der Laufzeit in einem Array, je nach RDBMS in einer Materialisierten View oder einem Objekt Store wie memcached, apcu, wincache oder einer entsprechenden Datenbank wie Redis.
Wenn es ein kleines Projekt ist kann man natürlich auch über eine Denormalisierung nachdenken, wobei das meiner Meinung nach immer der letzte Schritt sein sollte, da es eben potentiell für inkonsistente Daten sorgt und eben auch mehr Speicher benötigt für die Duplikate.
Davon ab bedeutet das dann meist, dass eine SQL Datenbank schlicht das falsche Tool ist, wenn man probiert, abgesehen vom Caching, daraus etwas Anderes zu basteln. Frage liest sich damit wie:
Ich möchte Tabellen joinen in einem Tool, das sehr effizient ist darin Tabellen zu joinen, jedoch möchte ich das ohne JOIN machen.
Der letzte Satz bringt es IMHO ziemlich auf den Punkt.
Denormalisierung kann ich auch bequem in der Anwendung machen, indem ich mir ein temporäres Working Set in einem geeigneten Datenmodeel (Datenstruktur) erzeuge, auf dem ich meine Berechnungsschritte ausführe.
Aber es soll ja auch Leute geben, die an langsamen Range-Matches verzweifeln, weil kein oder ein falscher Index vorliegt.
Ohne Joins macht nur Sinn, wenn es keine Relationen gibt. Du kannst also ohne weiteres einen Select machen im Sinne von
Select * from
table_a, table_b, table_c (usw)
Die Ausgabe wird aber vermutlich nicht ganz dem entsprechen, was du möchtest...
Erkläre doch deine Anforderung ein wenig detaillierter, dann können wir auch spezifischer helfen.
Du könntest mit geschachtelten SELECTs arbeiten, aber das ist immer wesentlich langsamer als ein JOIN.
Du könntest eine VIEW machen (mit einem SELECT Statement, das JOINs enthält) und dann auf die VIEW zumindest lesend zugreifen, als wäre es eine Tabelle.
Jo, das habe ich schon gelesen. Ich habe das deswegen trotzdem vorgeschlagen, weil es ja darum gehen könnte, dass er für verschiedene Abfragen den JOIN immer wieder hinschreiben müsste. Mit einer VIEW bräuchte er das nur einmal zu tun.
Es kommt auf die Aufgabe und die Art der Tabellen an. Ein Zusammenlegen kann in bestimmten Fällen möglich sein. Die relationale Technik, wie SQL das bietet, ist genau für die Fälle gemacht, bei dem sich Tabellen nicht zusammenlegen lassen.
Denke selber mal darüber nach: Man habe eine Tabelle mit Kundenadressen und eine mit dem Warenbestand. Wie sollte da ein Zusammenlegen möglich sein? In einer relationalen Datenbank kann man Tabellen verknüpfen, aber auch nur da, wo es logisch Sinn macht. Und das wird schon beim Konzipieren der Datenbank berücksichtigt.
Wir kennen Deine Tabellen nicht und können Deine Frage nicht speziell beantworten.
Union ... auf diese Idee bin ich beim lesen der Aufgabe nicht gekommen, kompliment... :)
Aber die Verwendung einer Union bedeutet nicht automatisch einen Fehler im DB Design, oder ? ;)