DB - Konzept zu Adressen

[Kalle_B]

Hallöle,

bei meiner jetzigen Adressverwaltung habe ich Firma und Person in einem Datensatz. Zur Firma zähle ich z.B. die Anschrift und die Homepage, zur Person die Tel-Nr und Mail.

Das ist problematisch, wenn mehrere Personen zu dieser Firma gehören. Im Fall eines Messeveranstalters gelten Kontaktwünsche der Firma, nicht der Person. Habe den Kontakt bisher mit der ersten Person (laufende Nummer pro Firma) verknüpft.

Wenn die nun ausfällt (Besuch absagt), hängen die Kontakte "in der Luft", es sind aber jetzt die Kollegen gefragt.

Nun möchte ich einen Adresstamm für die Firma machen und einen weiteren für die Person, verknüpft mit der Firma. Doch dadurch entsteht zwangsweise eine Hirarchie (2 Ebenen) in der Adresstabelle und jede Firma hat mindestens zwei Datensätze.

In einem externen Projekt gab es eine extra Beziehungstabelle, in der stand sinngemäß
X ist Mitarbeiter von A
A ist Kunde von B
B ist Lieferant von A
Y ist Zweigstelle von B
...

Ist das eine saubere Lösung für solche Beziehungen?

Lieben Gruß, Kalle

[Ilja]

yo,

grundsätzlich ist es so, dass man den sinn hinter datenmodellierung verstehen muss. es bringt wenig, lösungen für andere projekte auf das eigene zu übertragen, sondern ein datenbank-design ist in fast allen fällen immer eine einmalige sache. sprich du musst das design auf deine individuelle situation übertragen. dabei hilft es ungemein, sich erst einmal zu überlegen, welche entitäten (objekte) eigentlich vorkommen und in welcher beziehung sie miteinander stehen.

das sind bis dahin rein fachliche anforderungen, haben also mit der technischen umsetzung wenig zu tun. es gibt bestimmte modellierungsarten (ER-Modelle), genau das festzuhalten. allerdings sollte dein fall nicht so kompliziert sein. aber sich darüber gedanken zu machen, lohnt sich immer. dann wird auch klar, wie du die datenbank aufbauen musst.

Ilja

[Kalle_B]

hoi, Ilja,

grundsätzlich ist es so, dass man den sinn hinter datenmodellierung verstehen muss. es bringt wenig, lösungen für andere projekte auf das eigene zu übertragen, sondern ein datenbank-design ist in fast allen fällen immer eine einmalige sache. sprich du musst das design auf deine individuelle situation übertragen.

Nöö, ich möchte die Adressverwaltung so universal halten, dass ich sie in mehreren Projekten einsetzen kann. Z.B. auch für Vereine. Da gibt es vielleicht einen Vorsitzenden, mehrere Abteilungen mit ihren Mitgliedern. Also schon 3 Ebenen.

Ich glaube, die Extra- Beziehungstabelle zwischen juristischen und natürlichen Personen macht Sinn. Da könnte man kreuz- und querverweisen. Zusätzlich noch eine Verweisart- Tabelle. Dann könnte damit sogar ein Stammbaum- Projekt realisiert werden (K ist Kind von M, K ist Kind von V ...)

Kalle

[Frank (no reg)]

Hoi!

wenn K auch noch Kind von W ist, dann wird es problematisch ;)

Also schon 3 Ebenen.

Alle Mitglieder einer Abteilung des Vereins sind automatisch (theoretisch) Mitglieder des Vereins selbst. Innerhalb der Abteilungen gibt es dann auch noch Vorsitz-, Beisitz- und Nachsitz-Posten. Die gibt es aber auch für den Verein allgemein. Du kannst entweder für diese Posten eine eigene Abteilung ("Zentralkomitee") erfinden oder erlauben/definieren, dass für Abteilungsübergreifende Vereinsposten keine Abteilung definiert wird.

Kommerzielle Einrichtungen kann man auf das selbe Schema zurückführen. (Will sagen, es ist nicht komplexer im Hinblick auf Kontakt/Adressverwaltung). Es gibt Marketing, Vertrieb, Aufsichtsrat usw. Aber noch komplexere Szenarien für Kontaktverwaltung sind mir im Moment nicht bekannt - mit deinen "3 Ebenen" solltest du also imho ausreichend Fälle abdecken können.

Cheerio, Frank

[Kalle_B]

Hoi, Frank!

wenn K auch noch Kind von W ist, dann wird es problematisch ;)

Du sprichst das Problem der Leihmütter an? Sogar das ist mit meinem neuen Datenmodell darstellbar ;-)

Alle Mitglieder einer Abteilung des Vereins sind automatisch (theoretisch) Mitglieder des Vereins selbst. Innerhalb der Abteilungen gibt es dann auch noch Vorsitz-, Beisitz- und Nachsitz-Posten. Die gibt es aber auch für den Verein allgemein. Du kannst entweder für diese Posten eine eigene Abteilung ("Zentralkomitee") erfinden oder erlauben/definieren, dass für Abteilungsübergreifende Vereinsposten keine Abteilung definiert wird.

F(ussball) ist Abteilung von V(erein), X ist Leiter von F, X ist Vorsitzender von V. Ist doch kein Problem. Dann gibt es eben noch organisatorische Personen (Abteilung) neben den juristischen und natürlichen.

Gruß, Kalle

[Hamstar]

wenn K auch noch Kind von W ist, dann wird es problematisch ;)

Du sprichst das Problem der Leihmütter an? Sogar das ist mit meinem neuen Datenmodell darstellbar ;-)

Nur mal interessehalber, wie willst Du die verschiedenen Beziehungen zwischen den Datensätzen der Tabelle Klumpatsch nachbilden?

[Kalle_B]

Nur mal interessehalber, wie willst Du die verschiedenen Beziehungen zwischen den Datensätzen der Tabelle Klumpatsch nachbilden?

Personen-Tabelle (juristische, natürliche, organisatorische)

25 Max Mustermann
31 Felix Krull
67 Siemens AG
72 Maria Hellmann
75 Johanna Schmidt
83 Siemens-Warenannahme

Bezeihungsarten-Tabelle

11 Mitarbeiter von
25 Kind von
63 Abteilung von

Beziehungs-Tabelle

25 11 83   (Max ist Mitarbeiter bei der Warenannahme)
83 63 67   (Warenannahme ist eine Abteilung von Siemens)
67 25 75   (Siemens ist Kind von Johanna - natürlich Quatsch)

[Hamstar]

OK, bis auf die Tatsache, dass die Tabelle 'Personen' verhunzt wird, was katastrophale Folgen haben kann, ist der Vorschlag nunmehr von mir verstanden (und als kohärent erkannt ;) worden.

Viel Glück!

[Frank (no reg)]

Servus,

wenn K auch noch Kind von W ist, dann wird es problematisch ;)

Du sprichst das Problem der Leihmütter an? Sogar das ist mit meinem neuen Datenmodell darstellbar ;-)

Nein, der Väter. ;)  Falls es das interessant macht.

Frank.

[Hamstar]

grundsätzlich ist es so, dass man den sinn hinter datenmodellierung verstehen muss. es bringt wenig, lösungen für andere projekte auf das eigene zu übertragen, sondern ein datenbank-design ist in fast allen fällen immer eine einmalige sache. sprich du musst das design auf deine individuelle situation übertragen.

Nöö, ich möchte die Adressverwaltung so universal halten, dass ich sie in mehreren Projekten einsetzen kann. Z.B. auch für Vereine.

Eine Adressverwaltung für Vereine ist etwas anderes als eine für Firmen oder Ämter. Es gibt keine universelle Adressverwaltung.

Da gibt es vielleicht einen Vorsitzenden, mehrere Abteilungen mit ihren Mitgliedern. Also schon 3 Ebenen.

Die Position einer Person ist deren Attribut, das sollte die Tabellenstruktur unberührt lassen.

Ich glaube, die Extra- Beziehungstabelle zwischen juristischen und natürlichen Personen macht Sinn. Da könnte man kreuz- und querverweisen. Zusätzlich noch eine Verweisart- Tabelle. Dann könnte damit sogar ein Stammbaum- Projekt realisiert werden (K ist Kind von M, K ist Kind von V ...)

Das hört sich erst einmal ganz vernünftig an, Du willst alle Institutionen (Ämter, Vereine, Firmen) in eine Tabelle Ìnstitutionen packen und eine Beziehungstabelle Ìnstitutionen\_Personen halten um eine "n:m"-Beziehung zwischen Personen und Institutionen nachzubilden?

Eventuell beisst Du Dir an der nicht vorhandenen Homogenität der Institutionen die Zähne aus.

[Ilja]

yo,

Nöö, ich möchte die Adressverwaltung so universal halten, dass ich sie in mehreren Projekten einsetzen kann. Z.B. auch für Vereine.

das ist eine individuelle anforderung. das dein datenbank-design viel fälle (projekte und programme) abdecken soll, hat nichts damit zu tun, dass es dadurch allgemeingültig für andere wird. eine datenbank und damit das modell bildet nicht die gesamte realität ab, sondern immer nur alle "relevanten" daten und beziehungen. das ist sehr wichtig zu verstehen. und was für dich relevant ist, wird sich von anderen unterscheiden.

der versuch, die eierlegende-vollmichsau zu generieren, bzw. die gesamte umgebung mit zukunft und vergangenheit abzubilden, wird meiner meinung nach mit rdbms immer schief gehen. und ich habe ein wenig das gefühl, dass du genau das probierst und es deswegen schwierigkeiten gibt.

Da gibt es vielleicht einen Vorsitzenden, mehrere Abteilungen mit ihren Mitgliedern. Also schon 3 Ebenen.

zum einen verstehe ich nicht ganz, was genau du mit ebenen meinst. zum anderen bist du jetzt schon wieder in der technischen umsetzung. die modellierung ist aber unabhängig davon. und genau da liegt meiner meinunung nach ein problem von dir, du machst schon technische überlegungen, wo du erst einmal alleine die fachlichkeit untersuchen solltest. es macht sinn, das sauber voneinander zu trennen und erst danach, das fachliche auch technisch umzusetzen. ansonsten baut man sich damit größere probleme ein. wichtig ist, fachlichkeit ist das A und O einer guten datenbank. die muss 100% stimmen und das entsprechende umfeld mit allen relevanten punkten abdecken. wenn du das geschafft hast, dann wird auch vieles klarer und somit einfacher umzusetzen.

und das musst du nicht alleine erledigen, sondern ist vielmehr ein prozess mehrerer personen, die alle zusammen eurer individuelles fachliches modell abbilden.

Ilja

[Frank (no reg)]

Hallo,

Wenn die nun ausfällt (Besuch absagt), hängen die Kontakte "in der Luft", es sind aber jetzt die Kollegen gefragt.

Erkläre dies bitte genauer. Entweder es gibt einen Datensatz für die Firma (und der kann von mir aus gern ein Flag haben "besuch abgesagt") oder es gibt keinen.

Behandle die Existenz von Kontakten unabhängig von ihrer realen Aktion, will heissen, es ist vollkommen Wurst ob eine ganze Firma oder einzelne Kontakte dieser Firma unabhängig absagen oder zustimmen. Die Datensätze bleiben bestehen, man kann sie dann (wie grad schon mal erwähnt) mit einer Zusatzinfo belegen "Kein Kontakt erfolgt" oder was auch immer.

A ist Kunde von B
B ist Lieferant von A

Das ist redundant (m.E.n.), Abhängigkeitsbeziehung sollten unidirektional sein (in eine eindeutige Richtung gerichtet sein - ich wollte als Kind schon mal Richter werden *harhar*). Warum, wenn du alles zulässt, kannst du sehr schwer Zirkulärreferenzen vermeiden (die u.U. zu unendlichen Schleifen führen könnten).

Grundsätzlich ist solch eine zusätzliche Zwischentabelle in deinem Fall nicht per se schlecht. Definiere eindeutige Rollen, die untergeordnete Entitäten mit der übergeordneten verbinden (z.b. Marketing, Vertriebler, Support, Manager, ...) und - ich wiederhole mich - vermeide unnötige Redundanzen.

Doch dadurch entsteht zwangsweise eine Hirarchie (2 Ebenen) in der Adresstabelle und jede Firma hat mindestens zwei Datensätze.

Erkläre das bitte ebenfalls! Bei der Hierarchie mit 2 Ebenen gebe ich dir Recht. Aber warum 2 Datensätze? Warum trennst du das nicht in 2 Entitäten (1x Firma, 1x Person) wenn du jeweils unterschiedliche Attribute hast.

Das, der oder die Ilja hat völlig Recht, man sollte nicht von anderen Projekten, die u.U. andersgeartete Anforderungen hatten, schliessen, dass deren Lösung für das aktuelle Problem a) erstmal geeignet und b) effektiv ist.

Für die Verknüpfung zwischen Person und Firma, kannst du alles nehmen, sogar 36stellige UUIDs oder 5stellige alphanumerische Codes (ALKFI = Alfred's Futterkiste). Vergib jeder Entität ihre eigene eindeutige Identifikation und nicht relativ zur übergeordneten.

Dein Postingaufkommen der letzten ca. 6 Monate hatte immer wieder  das Thema "Kontaktverwaltung", "Organisation" etc zum Thema. Ich nehme an, es ist immer dasselbe Projekt? Das zeigt allerdings auch, dass du vor dich hinfrickelst und ständig auf irgendwelche neuen Probleme stösst, die konzeptionell nicht bedacht hast. Vielleicht solltest du ein wenig mehr Aufwand in die Anforderungsanalyse stecken, dass sie nicht immer nur bis zur nächsten Kreuzung (sprich lösung des momentanen Problems) reicht, sondern noch ein oder 2 Querstrassen weiter. Macht dein Projekt nicht wirklich um 100% schneller aber den Frickelaufwand geringer.

Grüsse,
Frank

[Kalle_B]

Hallo, Frank,

danke für deine ausführliche Stellungnahme.

Entweder es gibt einen Datensatz für die Firma (und der kann von mir aus gern ein Flag haben "besuch abgesagt") oder es gibt keinen.

Das ist z.Z. ein Zwitter. Firma inclusise 1 Mitarbeiter.

Die Datensätze bleiben bestehen, man kann sie dann (wie grad schon mal erwähnt) mit einer Zusatzinfo belegen "Kein Kontakt erfolgt" oder was auch immer.

Mal drüber nachdenken.

A ist Kunde von B
B ist Lieferant von A

Das ist redundant (m.E.n.), Abhängigkeitsbeziehung sollten unidirektional sein

Ja, schlechtes Beispiel, du hast recht

Warum trennst du das nicht in 2 Entitäten (1x Firma, 1x Person) wenn du jeweils unterschiedliche Attribute hast.

Habe ich damit gemeint.

Dein Postingaufkommen der letzten ca. 6 Monate hatte immer wieder  das Thema "Kontaktverwaltung", "Organisation" etc zum Thema. Ich nehme an, es ist immer dasselbe Projekt? Das zeigt allerdings auch, dass du vor dich hinfrickelst

Ja, das Projekt kommt alle Jahre wieder auf den Tisch und wird erweitert. Und hinfrickeln ist schon richtig beobachtet, habe keinen kompetenten Gesprächspartner, arbeite "learning by doing". Ist nicht die schlechteste Vorgehensweise.

Vielleicht solltest du ein wenig mehr Aufwand in die Anforderungsanalyse stecken, dass sie nicht immer nur bis zur nächsten Kreuzung (sprich lösung des momentanen Problems) reicht

Ist sowas wie das Schach- Problem. 32 Figuren, 64 Felder. Keine grosse Sache. Bis man anfängt, zu spielen ...

Kalle

[Frank (no reg)]

Hallo nochmal,

as ist z.Z. ein Zwitter. Firma inclusise 1 Mitarbeiter.

1 Datensatz Firma, 1 Datensatz Mitarbeiter mit Refererenz auf Firma und auf Rolle in der Firma. Ich sehe da kein Problem. Von einem Datensatz mehr wird dein System nicht unbrauchbar (selbst wenn es 10.000.000mal vorkommen würde -> Speicher ist heutzutage nicht wirklich ein Problem)

Schach? Mit fehlt leider dazu die Partnerin. (aktuell ;))

Ciao, Frank

[Hamstar]

1 Datensatz Firma, 1 Datensatz Mitarbeiter mit Refererenz auf Firma und auf Rolle in der Firma.

Referenz auf Rolle in der Firma?? - Ich blick einfach nicht mehr, was hier diskutiert wird.

Will der alle "Personen" (jur. bzw. reale) in eine Tabelle packen, die verschiedenen Beziehungen in eine zweite und eine dritte Tabelle für die Art der Beziehungen ("Ist GF von" oder "ist verf.ber. gegenüber" etc.)?

Soll hier das Datendesign an und für sich revolutioniert werden?

[Kalle_B]

1 Datensatz Firma, 1 Datensatz Mitarbeiter mit Refererenz auf Firma und auf Rolle in der Firma.

Referenz auf Rolle in der Firma?? - Ich blick einfach nicht mehr, was hier diskutiert wird.

Will der alle "Personen" (jur. bzw. reale) in eine Tabelle packen, die verschiedenen Beziehungen in eine zweite und eine dritte Tabelle für die Art der Beziehungen ("Ist GF von" oder "ist verf.ber. gegenüber" etc.)?

Ja, genau.

Soll hier das Datendesign an und für sich revolutioniert werden?

Ist das so revolutionär? Dann hat diese Revolution aber unbemerkt schon 1998 stattgefunden.

[Hamstar]

Soll hier das Datendesign an und für sich revolutioniert werden?

Ist das so revolutionär? Dann hat diese Revolution aber unbemerkt schon 1998 stattgefunden.

Ich weiss zwar nicht, wie Du das meinst und was 1998 genau los war (Hat da nicht der Mann von Gazprom die Wahl gewonnen?), aber das was Du vorhast ist in der Tat revolutionär (und an der Ideologie eines RDBMSes völlig vorbeigehend), denn eigentlich willst Du - wenn Du ehrlich bist - alle Entitäten in ein und dieselbe Tabelle packen und mit zwei zusätzlichen Tabellen ('Beziehungen' und 'Beziehungstyp') auskommen.

Damit hast Du _das_ Rundum-Happy-Paket für jedes beliebige Datendesign entwickelt! (Das geht nämlich theoretisch immer was Du vorhast, die Fremdschlüssel werden eben über die beiden zusätzlichen Tabellen verwaltet.)

[Kalle_B]

Damit hast Du _das_ Rundum-Happy-Paket für jedes beliebige Datendesign entwickelt! (Das geht nämlich theoretisch immer was Du vorhast, die Fremdschlüssel werden eben über die beiden zusätzlichen Tabellen verwaltet.)

Tja, dann kommt auch mal was Tolles dabei raus, wenn man Solist ist und keine Ahnung hat, wo die Grenzen verlaufen (sollen).

Kalle

[Hamstar]

Damit hast Du _das_ Rundum-Happy-Paket für jedes beliebige Datendesign entwickelt! (Das geht nämlich theoretisch immer was Du vorhast, die Fremdschlüssel werden eben über die beiden zusätzlichen Tabellen verwaltet.)

Tja, dann kommt auch mal was Tolles dabei raus, wenn man Solist ist und keine Ahnung hat, wo die Grenzen verlaufen (sollen).

Hast Du irgendwas verstanden? Wenn ja, was?

[Frank (no reg)]

Hey Hamstar,

vielleicht nicht ganz, wie du das jetzt verstanden hast.

Ich sehe das ganze so: (jetzt schon mal als Tabellen ausgedrückt)

Tabelle "Firma"
rein "Firma"-spezifische Attribute

Tabelle "Rolle"
Enumeration: GF, IT-Fuzzie, Sekretärin, Maitresse ...

Tabelle "Person"
Name, Vorname, email, ... sonstige personenspezifische Attribute (von mir aus auch Privataddresse
und Referenz auf "Rolle" und "Firma"

Mit der Einschränkung, dass eine Person nur einer Rolle in einer Firma zugewiesen ist

Bei m:n (man kann ja auch Director von mehreren Offshore-Geldveruntreuungsfirmen gleichzeitig sein), sollte die Verknüpfung von Person, Firma und Rolle auf eine eigene Beziehungstabelle verlagert werden.

Wenn sich die Attribute von jur. und natürlichen Personen so _dermassen_ gleichen, dann "warum in 2 Tabellen ablegen?"? Wenn dadurch andere Anforderungen nicht unmöglich werden, sehe ich darin kein Problem. Du etwa?

Ciao, Frank

[Hamstar]

Wenn sich die Attribute von jur. und natürlichen Personen so _dermassen_ gleichen, dann "warum in 2 Tabellen ablegen?"? Wenn dadurch andere Anforderungen nicht unmöglich werden, sehe ich darin kein Problem. Du etwa?

Ich habe gewisse Erfahrungen mit der Adressdatenhaltung (Firmen incl. Firmenzugehörige incl. etc.), es handelt sich real und somit datentechnisch um zwei verschiedene Objekte.

An anderer Stelle hatte ich ausgeführt, dass das, was der Threadinitiator ins Auge fasst, immer geht, also unabhängig von der Anforderungslage immer drei Tabellen 'Objekte', 'Beziehungen' und 'Beziehungstypen' reichen.

(Ich hatte in ähnlichem Kontext schon zig Diskussionen über die letzten Jahre und bin mittlerweile etwas dünnhäutig geworden, wenn es um solche elementaren Fragestellungen geht. Zuletzt hatte ich eine Diskussion, ob Vertragsanfragen und Verträge identische Objekte sind, die Antwort lautet nicht ganz überraschend "Nein", aber ich blieb - wie so oft ;) - unverstanden. BTW - warum ist Datendesign eigentlich vielen nicht zugänglich?)

[Frank (no reg)]

Servus, Moin und Salut,

auch mir sind aus der Praxis bislang nur Adressverwaltungen bekannt, die ebenfalls zwischen "Firma" und "Kontaktperson" trennen. Meine Frage war rein hypotethisch.

Wolltest du jetzt sagen, dass das Modell { "Objekte", "Beziehungen", "Bezhiehungstypen" }
[ ] generell immer möglich ist
[ ] generell eine geeignete Lösung darstellt
[ ] grundsätzlich immer möglich ist, aber nicht immer die ideale Lösung ist

BTW - warum ist Datendesign eigentlich vielen nicht zugänglich?

Gute Frage, es ist nicht l33t und auch nicht kewl?

Und es ist wunderbar zuzuschauen, wie meine OO-Kollegen immer wieder mit ihren OO-Konzepten gegen den eisernen Vorhang der relationalen Welt laufen. Die Datenbanken sind völlig frei von Schlüsseln oder Beziehungen, alle Felder nullable und mehrere Werttypen (Integers, UUIDs) werden in einem varchar(100) Feld abgelegt (man kann ja notfalls explizit casten, wenns nicht implizit geht). Oder es würde generell nur eine Tabelle mit einer Spalte voll XML geben. ;) Hauptsache jeder kann sich selbst verwirklichen.

Cheers,
Frank

[Ilja]

yo,

Und es ist wunderbar zuzuschauen, wie meine OO-Kollegen immer wieder mit ihren OO-Konzepten gegen den eisernen Vorhang der relationalen Welt laufen.

*seufz* und ich muss gerade eine datenbank-migration durchführen, wo oo-user hand angelegt haben. man kann sich auch selber einen strick um den hals legen, ist einfacher und schneller....

Ilja

[Hamstar]

Wolltest du jetzt sagen, dass das Modell { "Objekte", "Beziehungen", "Bezhiehungstypen" }

[x] generell immer möglich ist
(Es ist eigentlich noch schlimmer, zwei Tabellen "Objekte" und "Objektbeziehungen" reichen bereits um jede beliebige relationale DB umgeformt darzustellen)

[ ] generell eine geeignete Lösung darstellt

[x] grundsätzlich immer möglich ist, aber nicht immer die ideale Lösung ist
(Hört sich ein wenig an wie eine Fangfrage. ;)

[x] der absolute Murks ist
(beigefügt)

BTW - warum ist Datendesign eigentlich vielen nicht zugänglich?
Gute Frage, es ist nicht l33t und auch nicht kewl?

Datendesign ist aber cool, merkwürdigerweise ist es aber vielen nicht zugänglich, gerade auch den Bastlern und "talentierten" Schnellkodierern.

Und es ist wunderbar zuzuschauen, wie meine OO-Kollegen immer wieder mit ihren OO-Konzepten gegen den eisernen Vorhang der relationalen Welt laufen.

OO-Datenbasen sind OK und erforderlich, wenn die abzubildenden Objekte zu heterogen sind, als dass sie in ein RDBMS passen. Aber OO-Konzepte decken sich doch gerade mit der RDBMS-Welt.

Die Datenbanken sind völlig frei von Schlüsseln oder Beziehungen, alle Felder nullable und mehrere Werttypen (Integers, UUIDs) werden in einem varchar(100) Feld abgelegt (man kann ja notfalls explizit casten, wenns nicht implizit geht).

(Jetzt habe ich - so hoffe ich - verstanden, was Du meinst) M.E. ist sowas nicht "OO" sondern gut gemeinter (scheinbar auch schön flexibler) Murks. (Aber ich kenne auch solche "fröhlichen" Datenhaltungen.)

[Kalle_B]

Hallo nochmal,

Schach? Mit fehlt leider dazu die Partnerin. (aktuell ;))

Ach, _das_ Spiel ist ja noch komplizierter. Zwei Figuren und die Spielregeln werden täglich neu ausdiskutiert ;-)

Kalle

[Hamstar]

bei meiner jetzigen Adressverwaltung habe ich Firma und Person in einem Datensatz. Zur Firma zähle ich z.B. die Anschrift und die Homepage, zur Person die Tel-Nr und Mail.

Das ist problematisch, wenn mehrere Personen zu dieser Firma gehören.

In der Tat, da empfehlen sich zumindest zwei Tabellen Menschen und Firmen. Inklusive "1:n"-Beziehung zwischen Person und Firma, versteht sich.

Im Fall eines Messeveranstalters gelten Kontaktwünsche der Firma, nicht der Person. Habe den Kontakt bisher mit der ersten Person (laufende Nummer pro Firma) verknüpft.

Die "erste Person" ist Geschäftsführer oder pirimärer Ansprechpartner? Falls ja, OK, falls nein, dann jeweils einen anonymen primären Default-Ansprechpartner (Anrede: "Sehr geehrte Damen und Herren").

Wenn die nun ausfällt (Besuch absagt), hängen die Kontakte "in der Luft", es sind aber jetzt die Kollegen gefragt.

Sowas darf nicht passieren.

Nun möchte ich einen Adresstamm für die Firma machen und einen weiteren für die Person, verknüpft mit der Firma. Doch dadurch entsteht zwangsweise eine Hirarchie (2 Ebenen) in der Adresstabelle und jede Firma hat mindestens zwei Datensätze.

Würgg, was planst Du da?

In einem externen Projekt gab es eine extra Beziehungstabelle, in der stand sinngemäß
X ist Mitarbeiter von A
A ist Kunde von B
B ist Lieferant von A
Y ist Zweigstelle von B
...

Ist das eine saubere Lösung für solche Beziehungen?

Würgg, "Beziehungstabellen" bilden in aller Regel "n:m"-Beziehungen nach, keine Ahnung was Du da vorhast. Denk mal darüber nach und spezifiziere alles bestmöglich.

[Kalle_B]

In der Tat, da empfehlen sich zumindest zwei Tabellen Menschen und Firmen. Inklusive "1:n"-Beziehung zwischen Person und Firma, versteht sich.

Ich möchte keinen Unterschied zwischen Menschen und Firmen machen. Erstere sind natürliche, zweitere juristische Personen. Beide haben einen Namen, Anschrift, Kontaktdaten, ...

Nun möchte ich einen Adresstamm für die Firma machen und einen weiteren für die Person, verknüpft mit der Firma. Doch dadurch entsteht zwangsweise eine Hirarchie (2 Ebenen) in der Adresstabelle und jede Firma hat mindestens zwei Datensätze.

Würgg *), was planst Du da?

War nur laut gedacht, um ohne Beziehungstabelle auszukommen, macht aber wohl keinen Sinn.

Würgg *), "Beziehungstabellen" bilden in aller Regel "n:m"-Beziehungen nach

Das ist in Ordnung und birgt Reserven.

*) und sorry, dass du so würgen musstest.

Gruß, Kalle

[Hamstar]

Ich möchte keinen Unterschied zwischen Menschen und Firmen machen. Erstere sind natürliche, zweitere juristische Personen. Beide haben einen Namen, Anschrift, Kontaktdaten, ...

Wenn Du die Entitäten nicht der Natur entsprechend nachbaust, wirst Du scheitern. Du kannst nicht einfach alles zusammenpacken, da die Attribute der natürlichen und juristischen Personen zu unterschiedlich sind.

*) und sorry, dass du so würgen musstest.

Das geht mir leider oft so bei Datendesign-Arbeiten anderer.