|
Datenbank: steht noch nicht fest • Zugriff über: steht noch nicht fest
Eine Tabelle verweist auf sich selbst
Ich versuch grad meine erste Datenbankanwendung (Ein CD/Platten-Archiv) zu schreiben und bin dabei auf folgendes Problem gestoßen:
In einer Tabelle will ich die Künstler ablegen. Jeder Künstler soll mit mehreren anderen Künstlern in Verbindung stehen können (Unterschiedliche Projekte von einem Künstler, Verwandschaften ;-) usw.) Die Art der Beziehung ist dabei nicht wichtig. Es geht nur drum von einem Künstler auf eine Handvoll andere zugreifen zu können. Wie kann ich diese Verknüpfung machen? Ist eine Tabelle möglich die sich mit zwei verschiedenen Fremdschlüsseln auf den gleichen Hauptschlüssel bezieht? Beziehung ========= PK Beziehung_ID FK Künstler_ID FK Künstler_ID |
Re: Eine Tabelle verweist auf sich selbst
hi!
Zitat:
Beziehung ========= PK Künstler_ID ..dieser Künstler FK Beziehung_ID ...hat diese Bezieuhng ToKünstler_ID ...mit dieser Künstler Dann... SELECT Künstler_ID AS Künstler , ToKünstler_ID AS Bezieuhng_zu ...hier hast du dein Künstler und der Künstler zu dem er eine Bezuiehung hat. FROM Beziehung WHERE Bez.Beziehung_ID = <die Gewünschte Beziehung> AND Künstler_id = < dein gesuhtes Künstler> ....hier das Wichtigste!!! so legst du fest wie die Verknüpfungen aussehen ..damit hast du einen Künstler ausgewählt und kriegst all seine PArtner mit der er in eine Beziehung steht. wenn du ALLE mit ALLE ( kartesicher prodzukt aller Beziehungen ) dann: Select bez1.Kpnstler _id, bez2.Künstler_ID from Beziehung AS Bez1 , Beziehung As bez2 where bez1.ToKünstler_ID = bez2.Künstler_ID ..im Gross und Ganzen sieht deine Abfrage so aus. Jetzt kommen DB-abhängige Änderungen noch dazu :) . gruss, daniel |
Re: Eine Tabelle verweist auf sich selbst
Zitat:
Aber doch nicht über solche kranken Namen! Wie willst du denn sowas in deinem Programm abbilden? :shock: Mache nicht den Fehler dieser ganzen DB Hirnies, die damit später nicht arbeiten müssen. (oder wollen <g> ) *sich einen Spruch zu wohl 80% aller Datenbanken verkneift...* Zitat:
Dafür könnte eine einfache Beziehung eines Künstlers zu einer Familie reichen: Artits:
Hast du aber viele Beziehungen, Beziehungen mit mehreren übergeordneten elementen oder willst nchträglich Beziehungen hinzufügen sind Zwischentabellen ein gutes Werkzeug: (Hier besonders interessant, da Mutter & Vater unterschiedlichn Familien entstammen ;) ) Artits:
Der letzte ansatz dürfte in vielen Fällen der bevorzugte sein, da man die Ursprungsdaten möglichst weit von der Verwendung trennen kann. Dadurch lassen sich zu jeder Zeit neue Beziehungen und Eigenschaften einbauen ohne die Ursprungsdaten anfassen (==invalidieren) zu müssen. ;) Edit: Ich hatte meinen alten Beitrag blind editiert anstatt zu antworten. :wall: *rekonstruiert...* |
Re: Eine Tabelle verweist auf sich selbst
@2_daniel:
Ich will ja wie gesagt auf eine Art der Beziehung verzichten (Das mit der Verwandschaft war nur eine Rechtfertigung warum ich überhaupt Beziehungen zwischen den Künstlern einführen will) Könnte ich die Tabelle Beziehungen dann so anlegen: Beziehungen =========== PK Künstler_ID FK ToKünstler_ID Wenn ein Künstler mehrere Beziehungen haben kann muss die Tabelle dann so aussehen: Beziehungen =========== PK Beziehungen_ID FK Künstler_ID FK ToKünstler_ID @Robert_G: Was ist mit meinen Namen? Ich fange gerade erst an mit Datenbanken und hab die meisten Namen aus einem Buch übernommen in dem als Beispiel auch ein CD-Archiv beschrieben wird. In deinem ersten Beispiel wäre dann jeweils ID der PK und Family ein FK auf die Tabelle Families, richtig? d.h. wenn zwei Künstler was miteinander zu tun haben gründe ich eine Familie und steck sie da beide rein. Könnte ich dann noch einem Künstler mehrere Beziehungen zuordnen? Mit dem zweiten Beispiel geht das ja auf jeden Fall (soweit ich das sehe) aber da brauch man ja eine Tabelle mehr als mit einer Beziehungstabelle (vorrausgesetzt man darf das) |
Re: Eine Tabelle verweist auf sich selbst
Zitat:
Du müsstest dann mit jeder Ableitung das Rad neu erfinden. Außerdem sieht es einfach unschön aus. ;) Zitat:
Zitat:
Zitat:
Der Trick mit den Zwischentabellen ist, dass du ganz easy weitere Eigenschaften an deine Ursprungsdaten hängen kannst. Albums:
|
Re: Eine Tabelle verweist auf sich selbst
Hi,
das Problem kenne ich, hatte ich selbst vor Jahren, als ich mir ein Archiv für CDs, Schallplatten etc. angelegt habe. Plötzlich wollte ich alle Informationen, die man so bekommt, speichern. Und Tabelle verweist auf sich selbst geht gar nicht so schwer. Ich versuche mal, jetzt ordentlich zu erklären, wie ich das gelöst habe. Ich habe zwei Tabellen: Artist - hier sind sämtliche Künstler eingetragen
Damit ist auch automatisch der erste Künstler festgelegt und dessen ID bekannt. Auf dem zweiten Form habe ich dann sicherheitshalber oben noch mal den Namen des aufrufenden Künstlers vermerkt, damit ich das auch noch weiß, wenn ich im Hauptform schon andere Dinge tue. Weiterhin liegt dort ein DBGrid, in dem die Einträge niedergelegt werden und eine DBLookupComboBox. Wenn ich aus der Look..Box einen Namen auswähle, dann wird er direkt ins Grid eingetragen. Und die Beziehungen stelle ich folgendermaßen her: Dem DBGrid liegt eine Query zugerunden mit folgender SQL:
Delphi-Quellcode:
Den Parameter Number übergebe ich bei Aufruf des zweiten Forms.
SELECT
Artist_ByArtist.*, Artist.Artist_Name, Artist_ID FROM Artist, Artist_ByArtist WHERE (ByArtist_ID = Number OR Artist_ID = Number) AND (Artist.Artist_ID <> Number AND (ByArtist_ID = Artist.Artist_ID OR Artist_ID = Artist.Artist_ID)) ORDER BY Artist_Name Die Loo....Box nutzt folgende Query:
Delphi-Quellcode:
Das ganze klappt seit Jahren einwandfrei, hab allerdings 'ne Weile rumgefrickelt, bis ich es hatte und mir auch von schlauen Leuten helfen lassen.
SELECT
Artist_ID, Artist_Name FROM Artist ORDER BY Artist_Name Oh, beinahe hätte ich's vergessen, nutze ADO und ACCESS. Gute Nacht! |
Re: Eine Tabelle verweist auf sich selbst
Zitat:
Zitat:
Beziehungen =========== PK Beziehungen_ID FK Künstler_ID FK ToKünstler_ID Ich denke damit werde ich es jetzt versuchen. Wenn ich deinen letzten Beitrag richtig verstehe schlägst du sowas in der Art auch (für Künstler <-> Album) vor. Und auch das was Yadon gepostet hat deckt sich fast damit (welches Feld ist denn bei dir (Yadon) in der Tabelle ArtistByArtist der PK ?) [OT] Zitat:
[/OT] |
Re: Eine Tabelle verweist auf sich selbst
Zitat:
Und wenn etwas einen Namen hat, warum sollte man so dumm sein und ihn immer wieder anders nennen? Solange man Quick'nDirty nur DataSets und keinerlei Abbildung in Klassen verwendet mag das nur dumm aussehen, versucht man es aber mal vernünftig zu machen lässt es sich auch noch dumm damit arbeiten. ;) Zitat:
Ich glaube man merkt hier deutlich, dass ich deshalb schon öfter Zank mit solchen DB Hanseln hatte, die irgendwas hinschludern, Spalten immer wieder anders nennen, nur weil sie zu faul/unfähig sind Aliase in Abfragen zu verwenden. (Da ist so ein Punkt auf den ich etwas allergisch reagiere...) Zitat:
Zitat:
DB Design geht mit IbExpert und Firebird IMHO sogar einfacher und schneller. :) |
Re: Eine Tabelle verweist auf sich selbst
Es ist ja nicht so, dass das ganze nur hingeschludert ist und kein System hat. Es ist halt ein anderes System.
Dadurch das im PK der Tabellenname mit drinsteckt kann man den FK eben genauso nennen. Wenn alle nur ID heißen muss man sich für den FK einen neuen Namen ausdenken. Aber ich will mich mit dir hier nicht über die Namesgebung streiten (vor allem weil das meine erste Datenbank ist ;-) ). Ich nehme das alles einfach erst mal als Anregung auf und mache dann vielleicht die nächste DB nach diesen Kriterien. Im Moment will ich jedoch erstmal bei dem bleiben was das Buch mir anbietet (sowohl die Namen als auch die Kombination Access und ADO) damit ich mich daran entlangarbeiten kann und nicht dauernd überlegen muss "Was wäre das dann in meinem Fall?" Das hier ist übrigens das Buch von dem ich die ganze Zeit rede: |
Re: Eine Tabelle verweist auf sich selbst
Zitat:
Deshalb ja meine Hinweise mit den Benennungen und FB. ;) Außerdem habe ich nie behauptet, dass kein System darin wäre, aber eine Namenskonvention, die dich bestraft objektorientiert gegen die DB zu programmieren ist ein Paradebeispiel für "hingeschludert". ;) Ignoriere das meinetwegen beim Arbeiten mit dem Buch, aber behalte es im Hinterkopf, wenn du selbst etwas anfängst. ;) |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 11:02 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz