SQL: Daten aus zwei nicht verknüpfen Tabellen auslesen

[Saugkraft]

Tag die Herrschaften,

ich brüte grad über einem SQL Problem. Ich habe zwei Tabellen (sagen wir "Kunden" und "Mitarbeiter"), deren Felder teilweise deckungsgleich sind (Name, Straße, etc.), die aber in keinerlei Beziehung zueinander stehen.

Diese beiden Tabellen will ich zu einer virtuellen Tabelle zusammenfügen, so dass die deckungsgleichen Felder im Ergebnis nur einmal auftauchen:

kunden_id | mitarbeiter_id | Name     | Vorname
-------------------------------------------------------
1                            Schmidt    Josef
2                            Müller     Heinz
            11               Meyer      Fred
            12               Schulze    Franz

Schmidt und Müller stehen in der Kundentabelle, Meyer und Schulze in der Mitarbeitertabelle. Als Ergebnis hätte ich gerne eine gemischte Tabelle, in der entweder die kunden_id (bei Kunden) oder die mitarbeiter_id (bei Mitarbeitern) angezeigt wird.

 

[carstenj]

Hi,

Probier mal union:
http://www.w3schools.com/sql/sql_union.asp

 

[apple][c]

Ja, UNION sollte dein Freund sein!

 

[martinibook]

Irgendwie erscheint mir das ganze nicht sinnvoll, also das das umgebene Problem an sich schon merkwürdig ist.

Ich würde entweder eine Tabelle "Personen" machen, in der dann steht, ob sie Mitarbeiter oder Kunden sind.

 

[Troublem4ker]

Du solltest vielleicht auch bedenken, dass Kunden auch Mitarbeiter sein könnten. In dem Fall ist Gernalisierung auf die Felder nicht unbedingt sinnvoll, dann musst du eine Tabelle Person machen in der du eine Personid vergibst und verknüpfungen zu den Tabellen Kunden und Mitarbeiter erstellen, wo die Entsprechenden Kunden oder Mitarbeiter ID´s noch einmal Extra aufgeführt sind und halt andere Spezifische Daten....

 

[Saugkraft]

UNION.

Klar Leute, danke. Das hab ich auch schon diverse Male benutzt, aber mir ist es um's Verrecken nicht eingefallen.

Jetzt muss ich mir nur noch was einfallen lassen, wie ich nach der passenden id selektieren kann. Da es bei den ids Überlappungen gibt (kunde mit id 1 und mitarbeiter ebenfalls mit id 1), muss ich das wohl per Skript lösen. Oder fällt euch da was mit SQL ein?

 

[martinibook]

Ich würde einfach sagen, dass die Tabelle so nicht sinnvoll angelegt ist, wenn du die beiden Tabellen vermengen musst.

Person:
- Person-ID
- Vorname
- Nachname
- Anschrift
- Mitarbeiter-ID (wenn null, dann nur einfacher Kunde)

Mitarbeiter:
- Mitarbeiter-ID verlinkt
- Abteilung


Dann kannst du einfach nach Person-ID suchen und hättest auch Mitarbeiter als Kunden einfach abgedeckt.

 

[Saugkraft]

Du solltest vielleicht auch bedenken, dass Kunden auch Mitarbeiter sein könnten. In dem Fall ist Gernalisierung auf die Felder nicht unbedingt sinnvoll, dann musst du eine Tabelle Person machen in der du eine Personid vergibst und verknüpfungen zu den Tabellen Kunden und Mitarbeiter erstellen, wo die Entsprechenden Kunden oder Mitarbeiter ID´s noch einmal Extra aufgeführt sind und halt andere Spezifische Daten....

Ja, so etwas in der Art wäre meine zweite Wahl gewesen. Für den aktuellen Fall ist es insofern nicht relevant, da auf der Seite die Kunden nur als Kunden auftreten und die Mitarbeiter nur als Mitarbeiter.

Genauer ausgedrückt: Ein Textbeitrag wird von einem Kunden oder einem Mitarbeiter erstellt. Der Mitarbeiter ist aber in diesem Kontext kein Kunde, sondern immer Mitarbeiter.

Grundsätzlich ist die Idee mit der Personentabelle aber vielleicht eine Überlegung wert. Eventuell brauche ich den Zugriff in dieser Weise öfter und da lohnt sich ggf. der Aufwand, das mal zu überführen. Auf jeden Fall liefert es mir Stoff für weitere Überlegungen. Ist also genau der Denkanstoß, den ich gebraucht habe.

 

[martinibook]

Wenn du den Autor des Textes hinschreiben möchtest, brauchst du nur die Autor-ID vom Text aufzulösen. Ansonsten muss der Text ja noch wissen, ob er von einem Kunden oder Mitarbeiter (die IDs werden ja doppelt vergeben) geschrieben worden ist. Sollte es irgendwann noch eine dritte Kategorie geben, müsstest du alle implementierten Dienste ändern, so kannst du diese Gruppe einfach in die Personen Tabelle reinschreiben und zusätzliche Eigenschaften per JOIN aus einer dann angelegten Tabelle übernehmen.

 

[Saugkraft]

Ich würde einfach sagen, dass die Tabelle so nicht sinnvoll angelegt ist, wenn du die beiden Tabellen vermengen musst.

Naja, die aktuelle Variante ist eher der Ausnahmefall. Wenn ich alle in eine Tabelle gesteckt hätte, wäre der überwiegende Teil der Felder nicht belegt, weil die Angaben, die zur Person vorliegen völlig unterschiedlich sind. Bis auf ganz wenige Überschneidungen.

Außerdem hätte ich dann an anderen Stellen ständig abfragen müssen, um welchen Typ von Person es sich handelt, weil die Seiten von der jeweils anderen Gruppe nicht aufgerufen werden dürfen.

Das Hauptproblem: Die ids wurden vor ca. 7 Jahren vergeben. Da hängen also mehrere tausend Datensätze über zig verschiedene Tabellen dran. Wenn ich da jetzt die Überschneidungen auflösen will, muss ich sämtliche ids in den abhängigen Tabellen neu schreiben. Bis ich das erledigt hab, bricht das neue Jahrhundert an.

Aber stimmt schon.. Beim ursprünglichen Datenbankdesign wäre das evtl. die sinnvollere Variante gewesen. Wobei ich auch nicht so der Freund davon bin, jede Datenbank bis zum Gehtnichtmehr zu normalisieren. Wenn du für Daten, die du fast im Kopf behalten kannst, eigentlich einen Filter setzten kannst (personal_id 15 ist das scharfe Luder aus dem 3. Stock ), stattdessen aber seitenweise Abfragen schreiben musst, finde ich es irgendwann übertrieben.

 

[martinibook]

Ja, das stimmt auch wieder. Ich hatte das jetzt eher wie ein Moderationssystem auf einem Blog oder einer Review Seite, wie Amazon das macht, verstanden, 10% sind Beiträge von Mitarbeitern, 90% Kommentare von Kunden.

Gut, wenn du Altlasten hast, dann würde ich das auch mit UNION an den entsprechenden Stellen machen.

 

[Saugkraft]

Ja, das stimmt auch wieder. Ich hatte das jetzt eher wie ein Moderationssystem auf einem Blog oder einer Review Seite, wie Amazon das macht, verstanden, 10% sind Beiträge von Mitarbeitern, 90% Kommentare von Kunden.

Im Grunde ist das auch so ähnlich. Der Mitarbeiter schreibt genauso einen Beitrag wie der Kunde. Der Mitarbeiter eben aus seiner Seite des Intranets mit seiner ID und der Kunde aus seiner Seite mit seiner ID. Der Einfachheit halber haue ich die Beiträge dann in eine Tabelle und schreibe entweder die Mitarbeiter oder die Kunden ID dazu.

Das Anwendungsfeld ist zwar ein anderes (es geht um Dokumente, die von allen gleichberechtigt in einen Pool hochgeladen werden), aber das genauer zu erklären würde zu weit führen.

Letztlich ist es vor dem Hintergrund, was die DB sonst so leistet auch ein völlig untergeordnetes Feature, deshalb bietet sich hier Quick and Dirty an.

 

[martinibook]

Klar, wenn die anderen Funktionen mit der bisherigen Struktur auskommen, dann würde ich hier etwas basteln. Würde ich aber eine Dokumenten-Kollaborations-Plattform entwickeln, wären alle erstmal User, und danach würde ich in Kunden und Mitarbeiter trennen.