Office: Primärschlüssel in jeder Tabelle zwingend?

? ... die Firmendaten in den Firmenstamm, die Adressdaten in den Adressstamm. Was ist da unflexibel?
Das hat sogar den Vorteil, dass die Rechnungsanschriften sogar bei vollständiger Nutzung der RI (ohne Kopie der Adressdaten im Rechn.Stamm) stimmen würde, da damit jederzeit eine neue Rechnungs-Adresse für die Firma XY festgelegt werden kann, wenn die bestehende ungültig wird.

Und damit hast du genau diese "Kundentabelle" erstellt. *Smilie

Ich verstehe unter Mandantenfähigkeit die getrennte Führung von Geschäftsdaten, die keinesfalls miteinander gemischt werden dürfen. Was allerdings nicht verhindert, dass trotzdem gemeinsame Daten - wie z.B. Firmenstämme genutzt werden. Diese würde ich aber für jeden Mandant in einer extra Tabelle freischalten. Somit hätte ich schon wieder die Kundentabelle für die Mandanten erzeugt.
Was sinnvoll ist und was nicht kann aber glaube ich keiner von uns ohne konkreten Anwendungsfalls beurteilen. Ich will damit nur andeuten, dass es immer wieder andere Wege gibt und nicht nur den einen einzig richtigen. *wink.gif*

mfg
Josef

 

\@Atrus: Schon klar, das meine ich auch und hast du richtig verstanden. *wink.gif*
Aber dein Szenario würde ich programmiertechnisch lösen und nicht auf Datenebene.

Je nach dem wie viele Datensätze vorhanden sind, würde ich die entsprechenden Daten in Zusatztabellen auslagern welche 1:1 mit dem Personenstamm verknüpft sind. Ein Bei kleineren Beständen in die gleiche Tabelle nehmen. Die Felder sind dann halt leer. Die Verlinkungen würde ich aber über die Haupttabelle machen. Einfache Wertzuweisungen welche Abhängig von einer Verknüpfung von Kontakt zu Kontakt sind kommen alle in die Verlinkungstabelle.

@josef: Was ist der Vorteil wenn du Firmenstamm und Adressstamm trennst? Ich kann so überall hinbuchen mit einer tablle Kontakte. *wink.gif* Sprich egal was man machen will, hätte ich diesbezüglich nie einschränkungen oder Designänderungen. Die Beschränkung löse ich programmiertechnisch bzw. auch über das Datenmodell, welche ja die Filterung vorgibt, nur eben nicht in der Verknüpfung an sich. Die Auswahl der entsprechenden adressen geschieht dann über deine sogenannte Kundentabelle oder bei mir eben über diese Typisierungstabelle, welche verschiedenste Funktionen hat.

Die Kundentabelle hat aber keinerlei funktion für verknüpfungen, sondern dient lediglich als "Information". Das meine ich damit.

Das verstehe ich durchaus auch unter Mandantenfähigkeit. Aber es gibt auch Szenarien wo eben ein gemeinsamer Adresstamm gewünscht ist und der rest komplett getrennt. Ist bei Verkaufsfirmen oft der Fall. --> Zahlungsmoral usw. Kenne da eigene.
Den gewünschten Effekt kann man problemlos auch per Programmierung erreichen, warum also diesen Weg im Datenmodell verbauen? Ich verstehe schon, der Ansatz ist sehr unkonventionell, aber er ist eben flexibler.

 

\@Steve:
Zwei Kundennummern sind Unsinn.

Dein Schlüsselvorschalg ist auch ungut. Da die Kundenummer alleine schon eindeutig wäre, sind die Zusatzfelder Vorname und Nachname zuviel des Guten.

Im übrigen ist es nicht verboten, dass zwei Kunden den gleichen Namen haben. Bei Massennamen wie Müller, Meier, Schmitt ist das zu erwarten. Auch die Adresse darf gleich sein, wenn z.B. mehrere Schmitts im gleichen Wohnblock in Hamburg wohnen.

Es spricht sogar kein Naturgesetz dagegen, dass alle deine Kunden Schmitt heißen, im gleichen Haus wohnen und das gleiche Geburtsdatum haben. Sicher, das ist extrem unwahrscheinlich, aber es ist nicht unmöglich. Kundenduplikate kannst du also prinzipiell nicht ausschließen, du kannst aber prüfen, ob ein Kunde in den vorhandenen Kunden vielleicht schon vorhanden ist.

HTH

 

Wenn das die Kunden-Tabelle darstellt, könntest du einen eindeutigen Schlüssel auf Kundennummer legen.
Beachte aber, dass du möglicherweise auch einmal Lieferanten in einer Tabelle ablegen willst. Da wäre es dann sicherlich praktisch, wenn sowohl die Kunden als auch die Lieferanten-Daten in einer gemeinsamen Tabelle gepflegt werden können. Es könnte ja sogar auch sein, dass ein Kunde gleichzeitig auch Lieferant ist.

Ein Ansatz könnte dann sein:

tabKontakte
- idKontakt (Autowert, PK)
- KontaktName1 (bei Personen: Nachname)
- KontaktName2 (bei Personen: Vorname)
- ...
- Kundennummer
- Lieferantennummer

=> weniger Tabellen, aber ich würde es so nicht lösen. *wink.gif*

vielleicht eher so:
tabKontakte
- idKontakt (Autowert, PK)
- KontaktName1 (bei Personen: Nachname)
- KontaktName2 (bei Personen: Vorname)

Anm.: KontaktName1 / KontaktName2 ... mir ist nichts besseres eingefallen. Es werden ja bestimmt in dieser Tabelle Personen als auch Firmen eingetragen werden.


tabKunden
- fiKontakt
- Kundennummer

tabLieferanten
- fiKontakt
- Lieferantennummer


Bearbeitet werden die Daten dann über ein Formular, dass erstmal nur die Kontaktdaten zur Verfügung stellt.
Sobald ein Kontaktstamm als Kunde gekennzeichnet wird, wird im Hintergrund ein neuer DS in der Tabelle tabKunden eingetragen und schon ist der Kontakt zum Kunden geworden.
Überall wo nur Kunden zur Auwahl stehen dürfen, verknüpfts du tabKunden (per inner join) mit tabKontakte.

Auch zu überlegen:
Was ist, wenn einmal ein Kunde kein Kunde mehr ist?
... Dann könnte man vielleicht so eine Art "Ablaufdatum" in die Kundenstammtabelle mit aufnehmen.

Und genau hier unterschieden sich unsere Meinungen gravierend, denn über eine FE kann aus meiner Sicht nicht sichergestellt werden, dass ein zweites Frontend die Daten nicht falsch nutzt. *wink.gif*
Oder ein kleiner Schlampigkeitsfehler im FE .. und schon sind fehlerhafte Einträge vorhanden.

Ganz einfach: eine Firma (=rechtlicher Rahmen) kann mehre Standorte (Adressen) haben. U.a. kann eine Firma auch den Standort verlegen und trotzdem die gleiche Firma bleiben.

Und warum nutzt man diese Tabelle nicht? Diese Tabelle ist doch besonders gut geeignet, um eine Auswahl der Kontakte auf Kunden einzuschänken.

 

\@Weingeist:

Wenn du das alles ausprorgammieren willst, wird aber manches vom Programm erledigt, was eigentlich ein DB-Job ist.

Ein Beispiel aus meiner Praxis: Führung eines Terminkalenders, der Bezüge auf Objekte verschiedenster Art (Projekt, Dokument, Mitarbeiter, Projektobliegenheit) haben kann.

Man kann das so lösen:
Code:

Dabei ist die Bezug_GUID dann je nach Terminart die GUID eines Projekts, eines Dokuments, eines Kunden etc. Vorteil: der Terminkalender kann Daten aller Art aufnehmen; neue Arten können einfach durch neue Terminarten kenntlich gemacht werden. Nachteil: will man z.B. wissen, was für ein Objekt gemeint ist, muss man programmatisch je nach Terminart unterscheiden und dann die Projekt-, Dokument- oder Mitarbeitereigenschaften auslesen. Im Prinzip ist das ein Verstoß gegen die erste Normalform, weil das Feld Bezug eben nicht nur auf Projekte oder Dokumente verweist. Im Feld "Nachname" schreibe ich ja auch nicht bei Firmen die PLZ rein, weil die keinen Nachnamen haben, oder?

Alternativ wäre der "DB-orientierte Ansatz":
Code:

Hier braucht es keine Terminart, da projektbezogene Termine am Eintrag in der Spalte F_Projekt_GUID erkennbar sind. Die entsprechenden Felder und Tabellen lassen sich direkt verjoinen, da in jeder GUID nur eine "Sorte" Guids drinstehen kann. Nachteil: wenn hier neue "Sorten" eingebaut werden sollen, sind das Designänderungen an der DB, allerdings keine Keyänderungen.

Aber das ist ein weites Feld.

 

Das geht aber mit beiden Ansätzen. *wink.gif* Bei mir ist dan eine Typisierung dieser Adresse mehr. --> Standort

OK, das könnte man durchaus machen wenn man möchte. Zumindest überall wo die Daten sich auf diese Verknüpfung beziehen. Wäre in der Tat je nach Szenario sinnvoll oder auch möglich. Da muss ich dir/euch Recht geben. Nur würde ich trotzdem alle Kontakte in der Kontakttabelle speichern, inkl. der Standorte, Lieferadressen und was es sonst noch alles gibt. Typisierungstabellen gibts dann eine welche zwei FK's auf die Kontaktetabelle hat und nicht für jede Art eine. Dann bleibts immer noch so gut wie identisch flexibel. Die Fehlerquelle ist allerding auch anders recht klein, weil die ja höchstens darauf beruht, dass der User zu viele oder zu wenige Adressen zu Auswahl hat welchen er eine Rechnung oder auftrag schreiben kann. Diese erhält er ja aufgrund der Verknüpfungen der TypTabelle. Die entsprechend gefilterterten kann man ja immer noch per Views als Lieferant oder Kunde zu Verfügung stellen, je nach Typ halt ums bissel einfacher zu machen. Das ist entweder in der Frontend oder eben in der Backend. Wo ist ja eigentlich egal.

@Atrus: so war das nicht gemeint. Die Daten sind auch hier immer per referentieller Integrität verknüpft. Das einzige was wirklich auszuprogramieren ist, sind ja die Verwendung der richtigen Filter bzw. Tabelle, das ist aber in jedem Fall so. Diese kann man aber nach wie vor per Query oder View zu Verfügung stellen anstatt eben die ganze Tabelle.

EDIT: Beispiel:
Ich möchte von Mandant 1, alle Kunden haben:
Eine Query oder View mit:
TabKontakte
tabKontaktePos (oder welcher name auch immer)

Als Kriterien: In TabPos
SUB_ID: Die Mandanten_GUID
Typ_ID: Die Art der Verknüpfun, also Kunde

Und schon habe ich die entsprechenden Adressen.

Für Standorte einer Firma dito, einfach eine andere Typ_ID

In deinem Beispiel zum Terminkalender wäre dies nicht der Fall. Dein Beispiel kann man so nicht umsetzen, wie in der Adresskartei und würde ich, so auf die schnelle überlegt, genauso lösen wie du. Setze ich auch so ein in einigen Fällen. Wen man etwas kreativ denkt, isses ja eigentlich nix anderes wie meine Typtabelle. Nur halt mit ein paar FK-Möglichkeiten mehr.

 

Irgendwie denken wir (vermute ich zumindest) in unterschiedliche Richtungen.

Ich versuche es einmal mit einem Beispiel:

Firma, rechtlicher Name des Unternehmens: XYZ
UID: ATU1233678
Hauptstandort/Zentrale: Hauptstrasse 4711
Standort des Anlieferungslagers: Lagerweg 17
Anm.: Anlieferungslager ist nicht rechtlich eigenständig ... hat also keine eigene UID-Nr usw.

Wie speicherst du das nun in einer einzigen Kontakte-Tabelle?
Du benötigst damit auf jeden Fall zwei Datensätze und erzeugst somit auch zwei unabhängige Kontakte. (Auch wenn du diese in einer 1:n-Struktur abbildest musst du doch mehr Felder doppelt befüllen.)

Ich hätte das nach meinem Schema so gespeichert:
tabFirmen
- idFirma: 1234567
- Firma: XYZ
- UidNr: ATU1233678
- ...

tabAdressen:
Zentrale:
- fiFirma: 1234567
- AdrNr: 1
- Straße: Hauptstrasse 4711
- ...
- StandardRechnungadresse: Ja (... könnte man je nach Bedarf auch in 1:n-Struktur ablegen)
- ...

Lager:
- fiFirma: 1234567
- AdrNr: 2
- Straße: Lagerweg 17
- ...
- StandardLieferadresse: Ja
- ...

Anm.: ob die Tabelle nun Kontakte oder Firmen heißt ist nebensächlich.

 

\@Josef: Das denke ich auch. *wink.gif* Du hast richtig erkannt, ich benötige auf alle Fälle zwei Datensätze. Du aber auch. Ich einfach in der selben Tabelle.

Für den Firmenhauptsitz:
- AdrGUID: ID1
- NAME1: Firma XYZ
- SteuerID: ATU1233678

Für den Lager-Standort:
- AdrGUID: ID2
- Name1: Firma XYZ

Jetzt gibts in meiner Typisierungstabelle noch folgenden Datensatz:
- TypID: Standort
- AdrMainGUID: LagerStandort
- AdrSubGUID: Firmenhauptsitz

Ich wähle nun also einen Auftrag für Kunde mit ID1 aus, wenn ich nun die Lieferadresse möchte, dann kommen in der Auswahl die Filterkriterien aufgrund des Typs und der Verknüpfung zum Haupsitz.

Durch die beliebige Anzahl Typisierungen, kann man es auch für die verschiedensten Varianten und Filter einsetzen. Ob ich nun Programmiertechnisch meine View/Query oder Hardcodeten Typ zu Verfügung stelle oder aber eine gänzlich separate Tabelle ist doch latte oder? Dafür habe ich aber eine enorm viel grössere Flexibilität. Brauche nie eine zusätzliche Tabelle und neue Programmierung, sondern greife auf bereits bestehende zurück. Es gibt einfach einen Typ mehr.

 

ich benötige sogar 3 Datensätze (1 + Anzahl der Adressen)
Du speicherst aber Daten redundant und ich nicht. *Smilie

Es geht mir hier nicht um das Verknüpfen von Kontakten, sondern um das getrennte Speichern der Adressen, da gerade die Adressen aus meiner Sicht sehr oft ein Problem in einem DB-Modell verursachen, wenn sich die Adresse eines Kontaktes ändert, die alte Adresse aber gespeichert bleiben muss.

 

Nein, du verstehst es noch nicht ganz. *wink.gif*

Ich speichere absolut keine Adresse redundant! Nie! Egal wie viele Mandanten mit dieser Adresse arbeiten. Ist von einer Kontaktperson die Privatadresse bekannt, wird die Adresse heraufgestuft und man hat das komplette Formular. Bei Mandanten mit strikter Trennung, kann natürlich auch vorgesehen werden. kein Thema. Egal obs eine Lieferadresse, Rechnungsadresse oder weiss der Geier was ist. Eine Adresse bleibt eine Adresse. Ist der Firmensitz mit der Lageradresse identisch, gibts eine Standortzuweisung mit Sub und HauptID die identisch ist bzw. der einfachheitshalber gar nix. Das ist ja gerade einer der Vorteile des Systems. Absolut jede Adresse gibt es genau einmal. Auch nicht verzettelt über mehrere Tabellen. Dadurch kann ich sogar einen Automatischen, einfachen Kontakteabgliche über sämtliche Adressen in Exchange machen. Da gibts auch nur einzelne Kontakte *wink.gif* Aber das ist hier nicht das Thema.

Standardmässig wird immer die Hauptadresse, also der Kunde verwendet. Sind weitere Adressen vorhanden für den entsprechenden Typ, hat der Benutzer eine Auswahl.

Klar gewisse Typen mit Erweitertem Funktionsumfang sind auch hardcodet hinterlegt, diese Typ-GUID bzw. in meinem Fall die TypGruppe welche die Typs klassifiziert, sollte logischerweise nicht modifiziert werden, gibt auch keinen Grund dazu. Dazu gehören zum Beispiel Mandanten, Standorte, Kunden usw. Diese sind in der Typtabelle identisch wie die hardcoded hinterlegten GUID's. Ist für gewisse Typen auch unerlässlich. Nichts anderes machst du ja auch, mit der separaten Tabelle.

Wie gesagt, im Grunde ändert sich nix, ausser das man eben auf eine einheitliche Struktur zurückgreifen kann. Diese muss einmal sauber programmiert werden, dafür ist man super flexibel. Typerweiterungen für reine Auswertungen sind kein Problem, HauptTypen müssen eben in der entsprechenden Klasse mit Berücksichtigt werden. Der Aufwand hierzu ist aber bestimmt kleiner, als wenn ein separates System verwendet wird. Oder zumindest sämtliche Erweiterung. Ich programmiere meist über die TypGruppe, dann kann ich beliebig viele Untertypen erstellen, welche zum Beispiel für einen Kunden wichtig sind. Die Grundfunktion ist hardcodet in der klasse mit der TypGruppe synchronisiert und in ausnahmefällen direkt über die TypGUID.

Wenn unsere Ernte vorbei ist, werde ich mal ein solches Adressystem als Beispieldatei konstruieren. Dann ists vielleicht auch klarer wie die Anwendung abläuft. Im Prinzip ist es absolut simpel, lediglich die Kernelemente müssen sauber programmiert werden. Aber das ist überall der fall, du musst auch die richtige Tabelle angeben, wenn nicht, speicherst auch Müll. Ich muss eben zusätzlich den richten HauptTyp mit übergeben. Der Unterschied ist marginal. *wink.gif*

Der einzige Unterschied: es ist halt nicht konventionell. Ist ja auch nicht ganz üblich, dass jeder Kunde auch gleichzeitig ein Mandant sein kann, jede Person ein Kunde, jeder eine Warenbuchhaltung usw. In meiner Struktur ist das absolut kein Problem, die nötigen funktionen werden mit einer simplen Typzuweisung freigeschaltet. Darum ja auch meine Aussage, dass für unseren Betrieb vermutlich 99% der ERP-Lösungen einfach untauglich sind, das fängt beim Adressystem an und hört in der Produktion auf.

 

Ich schrieb ja auch nicht, dass du Adressen redundant speicherst - sondern Daten. *wink.gif*

"Firma XYZ" ist redundant gespeichert. *Smilie


Dein Prinzip mit der Verschachtelung von Kontaktdaten könntest du imo mit meiner Struktur genauso anwenden.
Ich trenne nur zusätzlich zw. Kontaktstamm und Anschrift.
Eine Anschrift ist bei mir die Adresse unter der ein Kontakt (oder vielleicht auch mehrere Kontakte) erreichbar sind. Und so eine Adresse hat nun einmal nach meinem Verständnis keinen Vornamen oder Nachnamen. *wink.gif*

 

Firma XYZ Z ist nich redundant gespeichert. Weil in diesem Fall die Anschrift identisch ist, gibts gar keinen zweiten Datensatz. Sondern wenn überhaupt eine TYpzuweisung auf sich selbst. *wink.gif* Ist die Adresse nicht identisch, isses so auch latte wenn der Name bissel anders lautet, ist sogar öfter mal der Fall. Wir haben einige Kunden, die Lagern bei anderen Firmen ein, das ist so automatisch mit abgedeckt. Nicht jeder Kunde ist eine Firma und nicht jeder Standort/Lager ist automatisch auch in Firmenbesitz. da nehme ich eine Gruppenmutation bei einer Firmennamen-änderung in kauf wenn wirklich viele Standorte vorhanden sind. Das ist imho das kleinste übel.

Wie immer, es führen viele Wege nach Rom. Mit meinem deckt man imho alles mögliche ab. Vor einigen Jahren hatte ich das gleiche System wie du, gab immer munter neue Tabellen usw. Mit jeder neuen erweiterten Funktionalität stieg die Komplexität. Irgendwann hab ich das ganze Adressystem über den Haufen geworfen und das System so aufgebaut. Seither ist ruhe. Fast egal welche erweiterung, sie ist schnell erstellt und hat keinen Einfluss auf die Datenstruktur, da diese schon flexibel gehalten ist. Gibt höchstens nen Feldchen oder ein paar mehr.

Möchte ja auch nix aufzwängen, aber imho ist genau das die Schwachstelle in den meisten Lösungen. Aber logo, nicht alle brauchen die Flexibilität. Ich sehe es nur nicht ein, warum man sie von Anfang an aufgeben sollte, das ist alles. *wink.gif*

 

\@Weingeist:
Redundanz liegt nicht erst dann vor, wenn es mehrere Datensätze zum gleichen Objekt gibt. Redundanz ist auch schon gegeben, wenn innerhalb von Datensätzen Daten gleich sind. Und da du in deinem Firmenhaupzsitz-DS und im Adresse-DS den Name1 speicherst, mit notwendigerweise gleichen Werten, ist das Redundanz.

Wohl! *stampf* *Smilie

Edit:

Hierzu eines meiner Lieblingszitate, leicht abgewandelt: "Wenn eine Glaskugel aus Holz ist und 6 paarweise parallele gleichgroße Flächen hat, dann ist es nicht eine "flexible" Glaskugel, sondern ein Holzwürfel." Du würdest da wohl sagen, das darf man nicht so eng sehen *hihi* Ich meine damit, das alle Flexibilität Grenzen hat. Deine Kunden-DB kann sicher nicht die Steuererklärung des Kunden machen; sie ist deshalb aber nicht unflexibel, sondern einfach außerhalb ihres Anwendungsbereichs betrieben worden. Und das ist nicht "flexibel", sondern einfach etwas anderes.

HTH

 

\@Atrus2711: Da stimme ich dir teilweise zu. Aber da wos eben einfach geht, sehe ich nicht ein, warum man es kompliziert machen muss. Auch *Stampf* *grins

Habe meine Aussage oben noch etwas erweitert betreffend der redundanz des firmennamens. Imho ist das über alles gesehen ein wirklich verschmerzbares übel!
Der Firmenname lautet zum Beispiel auch Firma XYZ Schweiz AG, am Anderen Ort vielleicht XQZ Zürich AG. Und schon ist man mit dem fixen System am Ende bzw man fängt an zu basteln, in diversen Softwarelösungen schon gesehen. Da fängt dann die Redundanz erst an, mit der Hinterlegung von duplizierten Steuernummern etc. usw. Mit meinem kostet mich das ein kühles lächeln. Da bin ich froh wenn ich den Namen anpassen kann. Gibt auf oft firmen die sowas gerne definiert in der Adresszeile haben. Darum muss ich mich nicht kümmern. Wird einfach so zusätzlich erstellt.

Wird nun also ein Firmenname wirklich geändert, dann kann man ein Formular einblenden mit allen abhängigen Adressen und auswählen, wo den nun geändert werden soll. Das ist wirklich ein sehr kleines übel oder? *wink.gif* Oder sogar in der Typdefinierung so hinterlegen, dass diese automatisch geändert werden, bzw. nur im Hauptsatz geändert werden dürfen. Das war jetzt das Beispiel für die abstrakte Version. Also ein eigener Typ für die automatischen einer für die manuellen, einer ist gestattet, einer nicht. Die TypObergruppe bleibt identisch welche für die Auswahl gebraucht wird, welcher der User zu gesicht bekommt. ändern kann er sie aber nich in jedem Fall.

 

Jetzt steige ich aus, da ich nicht mehr durchblicke. *Smilie

Ausgangsbasis:
tabFirmen
- idFirma: 1234567
- Firma: XYZ
- UidNr: ATU1233678
- ...

tabAdressen:
Zentrale:
- fiFirma: 1234567
- AdrNr: 1
- Straße: Hauptstrasse 4711
- ...
- StandardRechnungadresse: Ja (... könnte man je nach Bedarf auch in 1:n-Struktur ablegen)
- ...

Lager:
- fiFirma: 1234567
- AdrNr: 2
- Straße: Lagerweg 17
- ...
- StandardLieferadresse: Ja
- ...

Dein Vorschlag:
Für den Firmenhauptsitz:
- AdrGUID: ID1
- NAME1: Firma XYZ
- SteuerID: ATU1233678
- Straße: Hauptstrasse 4711 (.. ok diese Feld hast du so nicht geschrieben, aber ich nahm an, dass das hier her gehört.)

Für den Lager-Standort:
- AdrGUID: ID2
- Name1: Firma XYZ
- Straße: Lagerweg 17

Es gibt also 2 Adressen und somit 2 Datensätze wobei beide immer den selben Firmenwortlaut haben müssen. Und in diesen 2 Datensätzen speichert du gemäß deinem Beispiel den Wert "Firma XYZ" also 2x ab. Das ist für mich Redundanz.

Ich kann mir aber vorstellen, dass du per Code das so regeln wirst, dass bei einer untergeordneten Kontaktadresse vom Typ "Standort" kein Wert in "Name1" gespeichert wird, sondern in der Maske dann der Wert des übergeordneten Datensatzes angezeigt wird. Somit vermeidest du per Code, dass falsche Daten in den Tabellen landen.

Zum Abschluss noch einmal die Wiederholung: dein Konzept der Verschachtelung von Kontaktdaten finde ich sinnvoll - mir gefällt nur das Mischen von unterschiedlichen "Objektkategorien" nicht. Eine Person (Firma, Privatperson,....) ist nun für mich etwas anderes als ein Haus. *wink.gif*

/edit:

Wenn der Firmenname anders ist, dann ist es auch nicht mehr eine Firma. Dann passt dein System zum Verschachteln von mehreren Firmen zu einem "Konzern" sehr gut.
Das hat aus meiner Sicht aber wiederum nichts mit den Anschriften zu tun.
Vielleicht war das Wort "Standort" auch schlecht gewählt von mir, da es sehr oft vorkommt, dass ein Standort eine eigenständige Rechtsperson ist. ... also eine eigene Firma.
Mit "Auslieferlager" wollte ich eine 2. Adresse einer Firma andeuten, meinte damit aber keine "Zweigstelle" mit eigenem Firmennamen.

mfg
Josef