10. März 200520 j Hallo Leute, ich habe da mal eine Frage bzgl. Is-A-Beziehungen. Eine Isa-Beziehung ist ja mit der Vererbung zu vergleichen. Also, man hat zum Beispiel eine Tabelle Bedienstete mit Personalnr, Geburtsdatum,... . Und darunter zwei Tabellen, Angestellter(Personalnr, Monatsgehalt...) und Arbeiter(Personalnr, Stundengehalt, ...). Wie realisiere ich das jetzt in einer Programmiersprache? Also, ich möchte eine Abfrage über alle Bediensteten die am 18.09.1980 Geburtstag haben und das dazugehörige Gehalt. Dann müsste ich ja zuerst in der Tabelle Bedienstete nach Mitarbeitern mit diesem Geburtstag suchen und dann, ??? Muss ich dann jede Tabelle, die mit der Obertabelle in Beziehung steht nach der Personalnr durchsuchen, oder wie kann man das sonst realisieren? Bei zwei Tabellen geht das ja, aber wenn das mal hundert Untertabellen sind, werden das dann schön viel Selects und vom Traffic aufn DB-Server gar nicht zu sprechen. Vielen Dank für eure Antwort im Voraus. Viele Grüße, Fabian Weber
10. März 200520 j Du kannst die "Untertabellen" doch alle auf einmal joinen und erhaelst so das entsprechende Gehalt von den Mitarbeitern (fuer die einen halt bezogen auf den Monat und fuer die anderen auf die Stunde). Wenn du allerdings mal 100 solcher Tabellen hast, dann ist wahrscheinlich nur dein DB-Design schlecht Goos
10. März 200520 j Wenn du allerdings mal 100 solcher Tabellen hast, dann ist wahrscheinlich nur dein DB-Design schlecht Goos das sehe ich genauso, Ich kenne die Anforderungen der Software nicht, aber ev. wäre es sinnvoller ein BitFeld in der Tabelle "Bedienstete" zu setzen, je nachdem, ob der Mitarbeiter nun Angestellter o. Arbeiter ist und eventuell "Verknüpfungstabellen " anzulegen.das spart u.U. wieder ein paar Joins aber wie immer gibt es 1000 'e Wege , um das Problem zu lösen
10. März 200520 j Das mit den 100 Tabellen war auch nicht so ernst gemeint. Würde ich jetzt aber auch nicht als schlechtes DB-Design ansehen. Wenn ihr zum Beispiel den Datenbankaufbau der Agentur für Arbeit als Beispiel nehmt. Eine generelle Obertabelle "Arbeitlose" und dann gibt es ja zig Untertabellen bei den Berufen. Arzt, Mechaniker, ..... Und da kommen dann ganz schnell 100 Tabellen zusammen. Und das ist dann sicher kein schlechtes DB-Design. Aber zurück zum Thema. Also das mit dem Bitfeld hab ich mir auch schon überlegt, war für mich aber irgendwie nicht die sauberste Lösung für dieses Problem. Dachte, da gibts andere Möglichkeiten. Aber Danke.
10. März 200520 j Das mit den 100 Tabellen war auch nicht so ernst gemeint. Würde ich jetzt aber auch nicht als schlechtes DB-Design ansehen. Wenn ihr zum Beispiel den Datenbankaufbau der Agentur für Arbeit als Beispiel nehmt. Eine generelle Obertabelle "Arbeitlose" und dann gibt es ja zig Untertabellen bei den Berufen. Arzt, Mechaniker, ..... Und da kommen dann ganz schnell 100 Tabellen zusammen. Und das ist dann sicher kein schlechtes DB-Design. Woher bist du dir sicher, dass es bei deinem genannten Beispiel zig Untertabellen gibt? Goos
10. März 200520 j Naja, wenn man für jede Berufsgruppe eine Tabelle erstellt, dann kommt man auf diese Menge. Was haltet ihr von diesem Datenbankaufbau: Checkpoint Datenbankaufbau Erklärung dazu gibts hier: http://forum.fachinformatiker.de/showthread.php?t=75476
10. März 200520 j Bleib doch bitte in einem Thread bei einem Thema, sonst wirds nur unnötig unübersichtlich.
11. März 200520 j Naja, wenn man für jede Berufsgruppe eine Tabelle erstellt, dann kommt man auf diese Menge. Weshalb sollte man aber fuer jede Berufsgruppe eine eigene Tabelle erstellen? Goos
Archiv
Dieses Thema wurde archiviert und kann nicht mehr beantwortet werden.