Keine Redundanzen, oder einfacher Programmieren?

  • C#
  • .NET (FX) 4.0

Es gibt 5 Antworten in diesem Thema. Der letzte Beitrag () ist von us4711.

    Keine Redundanzen, oder einfacher Programmieren?

    Servus,
    ich habe, als ich eine Datenbank für eine Adressverwaltung entworfen habe, folgendes Modell für Firmen und deren Standorte Entworfen:

    Dieses Modell sollte die m:n Beziehung auflösen die zwangsläufig entsteht, wenn man Standorte von Firmen trennt:
    Eine Firma kann mehrere Standorte haben (z.B. verschiedene Werke bzw. Zweigstellen bzw. Niederlassungen)
    Ein Standort kann mehrere Firmen haben (z.B. in Gewerbegebieten in denen in einem Gebäude mehrere Büros verschiedener Firmen untergebracht sind)

    Nun jedoch bin ich in der Programmierung angekommen und sehe, dass dieses Modell oft nur Kopfzerbrechen bereitet, und ein 1:n Modell, in der die t__location noch den Key refCompany bekommt und die Verbindungstabelle komplett wegfällt, wesentlich leichter handzuhaben ist, für Programmierer und Anwender gleichermaßen.

    Der Negative Aspekt an diesem Modell ist, dass dadurch in der t__location Redundanzen entstehen können, da sich mehrere Firmen an einem Standort befinden können (man denke an ein Gewerbegebiet, mit mehreren Firmen in einem Gebäude)

    Der Positive Aspekt ist in diesem Falle, dass ich beim Erstellen von neuen Standorten nicht darauf achten muss, ob ein Standort bereits vorhanden ist, der User kann zu jeder Firma einen neuen Standort hinzufügen, und muss nicht danach Suchen. Dies ist für mich ein geringerer Programmieraufwand.

    Ich kann mich leider nicht zwischen den Beiden entscheiden:
    Geringere Datenredundanz dafür höherer Programmieraufwand,
    oder einfacheres Programmieren unter Vernachlässigung von "wichtigen" Prinzipien?
    Ich würde das 2. Model vorziehen.
    Wenn ich Standort als Adresse sehe ändert sich bei verschiedenen Firmen ja wenigstens minimal (z.B. Hausnummer)
    Auch die Pflege der Daten wird Einfacher da ich den Adresspart einer Fima im Falle eine Umzugs o.ä. einfach editieren kann ohne prüfen zu müssen ob die "alte" Adresse noch bei anderen Firmen hinterlegt ist.

    Ich hoffe ich hab deinen Frage korrekt verstanden und nicht nur Blödsinn geschrieben :)
    There is no CLOUD - just other people's computers

    Q: Why do JAVA developers wear glasses?
    A: Because they can't C#

    Daily prayer:
    "Dear Lord, grand me the strength not to kill any stupid people today and please grant me the ability to punch them in the face over standard TCP/IP."

    EaranMaleasi schrieb:

    da sich mehrere Firmen an einem Standort befinden können (man denke an ein Gewerbegebiet, mit mehreren Firmen in einem Gebäude)
    In meiner Überlegung sind das verschiedene Standorte.
    Die haben nur dieselbe Postadresse.
    Der Standort ist ein Item der Firma.
    Der Standort München von Microsoft wurde letztes Jahr von Unterschleißheim nach Schwabing verlegt.
    Das betrifft aber nur Microsoft.
    Die Hausverwaltung des Unterschleißheim-Komplex hat den Standort vermutlich nicht gewechselt.
    Den Standort einer Firma kann man also umziehen, ohne die anderen Firmen am alten Standort mitzuziehen.

    Edit: da war ich wohl zu langsam.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --
    Gerade bei so was wie Personen / Firmen Daten kann man Redundanz nicht vermeiden.

    Schön mir ist das gerade noch ein Beispiel eingefallen.

    In einem Unternehmen kann es ja schließlich auch mehrere Mitarbeiter mit dem gleichen Vor und/oder Nachnamen geben. Vielleicht sogar mit gleicher Adresse (Ehepartner, Kinder usw.). Da wird man in der Personalverwaltung aber auch nicht für Nachname, Vorname und Adresse Verknüpfungstabellen erstellen.
    There is no CLOUD - just other people's computers

    Q: Why do JAVA developers wear glasses?
    A: Because they can't C#

    Daily prayer:
    "Dear Lord, grand me the strength not to kill any stupid people today and please grant me the ability to punch them in the face over standard TCP/IP."
    In einem (älteren) VB6-Projekt habe ich einmal folgenden Ansatz verfolgt:
    - Adressen können sich auf Personen oder Organisationen (alles, was keine Person ist, z.B. Firmen, Vereine, auch Familien) beziehen.
    - Jede Person kann zu einer oder mehreren oder zu keiner Organisation gehören.
    - Jeder Organisation kann eine oder mehrere, oder keine Person zugeordnet sein.
    - Jede Organisation können weitere oder keine Organisationen zugeordnet sein (Abbildung eines filial-/Niederlasungsnetzes)
    - Jeder Person oder Organisation ist zumindest eine Adresse zugeordnet.

    Die Verknüpfung von Organisationen, Personen und Adressen erfolgt dann weitere Tabellen, die in der Regel nur Verweise auf entsprechende ID's der anderen Tabellen enthalten. Ist bie CRUD nicht ganz trivial, bietet aber im Anschluss grandiose Auskunftsmöglichkeiten "on the fly".
    z.B.: Welche Organisation hat welche Personen zugeordnet (i.e. Mitarbeiter, Vereinsmitglieder, Abteilungen, Abteilungsmitglieder)
    Auch die Datenerfassung ist nicht trivial, kann aber über "intelligente Dialoge" doch sehr benutzerfreundlich gestaltet werden.
    Das ganze erfolgte seinerzeit auf Basis einer Accress-Datenhaltung, war als Einzelplatzplatzlöung konzipiert und verwaltete in der Spitze 50.000 Entitäten zufriedenstellend.
    Hab's leider nie nach .NET portiert, wären etliche Mannmonate an Aufwand gewesen.