Seit Monaten, wenn nicht Jahren, hadere ich mit dem Wildwuchs an Adress- und Kontaktdaten in meinem Büro. Da gibts die uralte aber täglich in Benutzung befindliche Auftragsdatenbank (PhoenixDB, noch aus Win95-Zeiten in einer VM), dann die Adressdatenbank für UPS (in Worldship), im Web eine DB für die elektron Briefmarke der Post, dann die Kontakte auf iPhone und Macbook und dazu einige Filemaker-Anwendungen, die z.B. für Rundmails und Rechnungsversand per Mail mal eben schnell zusammengehackt wurden. So langsam doht das Ganze ausser Kontrolle und vor Allem immer a-synchroner zu geraten ... Also habe ich mir gedacht, ich lege EINE zentrale Kontaktdatenbank an, an die ich die anderen Lösungen irgendwie anhänge, teils per ODBC oder CalDav/CardDav oder wie auch immer, aber quasi als zentrale Instanz. Ich will in diesem Thread garnicht vordergründig die Programmierumgebung oder das verwendete Datenbanksystem diskutieren - da hat sowieso jeder andere Vorlieben. Aber ich denke, es sollte eine relationale DB sein, die per SQL im Netzwerk gesteuert werden kann. Die Frage ist nun, wie detailiert man das Datenmodell anlegt. Also mit einer einfachen Flat-Table ist es definitiv nicht getan, denn das Thema Kontakte ist bei genauer Betrachtung deutlich komplexer, als man im ersten Moment vermuten mag: - was ist ein Kontakt? Eine Firma, eine Person, eine Anschrift? - Ich kenne Firmen, die sind Kunde oder Lieferant oder beides - ich kenne Leute, die arbeiten in/für Firmen als auch nicht - ich kenne Leute, die arbeiten für mehrere Firmen (Vertreter) - ich habe die unterschiedlichsten Kontakttypen: Anschrift (real, Postfach, für Lieferungen, für Rechnungen, für Rückfragen), Mails, Telefon, Mobil, Fax, div. Messenger) - es gibt Firmen und deren Außenstellen. Da werden z.B. Bestellungen und Lieferungen mit den Außenstellen verhandelt, die Rechnung geht aber an eine gemeinsame Stelle (z.B. Bahn), wie stelle ich das dar? Ich würde auch gerne möglichst "sauber" nach den Regeln für rel. Datebanken arbeiten, also keine Wiederholfelder, keine Redundanzen usw., also die Normalformen 1 bis 3 als Minimum. Noch bevor man die einzelnen Tabellen bestimmt, sollt man evtl. in einer Art "Schichtenmodell" die Hirarchie festlegen. Welch Info hat das Primat? Nennt man sie "Kontakt" und dahinter verbergen sich (Haupt-) Firmen? Lege ich für Außenstellen eine eigene Tabelle an oder verküpfe ich die in der gleichen Tabelle (was technisch geht, aber jedem DB-Theoretiker das Frühstück hochkommen lässt). Wie ordne ich angestellte und freie Personen ein? Das würde ich gerne mal diskutieren. Nicht, dass ich keine eigenen Vorstellugnen hätte, aber man weiss ja auch nicht Alles und evtl. gibts auf diesem Wege die eine oder andere gute Idee?
MySQL. Ich würd das über eine Kundendaten-Tabelle machen, in der alle einzelnen Kontakte drinstehen und diese referenzieren, so daß ich in weiteren Tabellen ihre Zugehörigkeit zu Subunternehmen, Unternehmen, Konzernen festlegen kann. Das kann man dann beliebig kaskadieren und theoretisch mit einer einzelnen Abfrage durch alle Ebenen springen (was dann aber schon mühseelig wird). Man könnte die Zugehörigkeit zu Firmen auch direkt in der Kundendaten-Tabelle speichern, das geht genauso gut. Kostet wegen der Volltextsuche im Index-String etwas Leistung beim Suchen, aber bringt bessere Suchergebnisse, vor allem wenn beliebig viele Ebenen gewünscht sind. Ich find das ist eine reine Programmierübung. Viele Wege führen nach Rom.
:
Bearbeitet durch User
Eigentlich gibt es nur eine zukunftsgerichtete Loesung. MySQL auf einem Webserver. Das kriegt man auch in 10 Jahren noch zum Laufen. Bei der Auslegung muss man Komplexitaet gehen Wartbarkeit aufwiegen. Die Daten kriegt man auch in 30 Jahren noch als CSV raus. Die Uebersicht nicht unbedingt. Mein Vorzug waere eine gerade Liste fuer die Eintraege, und Verknuepfungen als extra tabelle oben drauf. Dh, falls man irgendwann die Verknuepfungen nicht mehr hinkriegt, hat man noch die Liste.
Hallo! Das zu verwendende Datenbanksystem ist NICHT das Thema, abgesehen davon, dass ich heute statt MySQL eher MariaDB nehmen würde - aber darum geht es nicht! Es geht um die Struktur als solche, und die ist DB-unabhägig ...
Wahrscheinlich heißt das MariaDB, weil die DB öfter mal zum Himmel fährt?
MariaDB ist sowieso dasselbe. Falls man sich dann selbst um die Installation kuemmern muesste. Die Struktur.. auf Wartbarkeit ausgelegt. Also eher nicht Version 13.6.7 von einem Opensource programm. Denn die Version 14.0.0 wird das Format schon nicht mehr Lesen koennen, der neue Webserver mit dem PHP will aber keine 13er Version mehr laufen lassen... usw.
magic s. schrieb: > Wahrscheinlich heißt das MariaDB, weil die DB öfter mal zum Himmel > fährt? Nein, die erste Tochter des Entwicklers heisst "My" und die zweite "Maria", echt. Alles klar? MariaDB ist intern wesentlich moderner und im Bugfixing weiter als MySQL. Dem Entwickler ging das Hickhack nach dem Kauf von MySQL durch Sun und später Oracle auf den Geist. Deshalb ist er ausgestiegen und hat sein System quasi neu aufgelegt. Die API ist 100% abwärtskompatibel zu MySQL. Aber nochmal: Ich möchte in dem Thread nicht über die Programmstruktur, sondern das Datenmodell, die TABELLEN-Struktur, die Relationen diskutieren. Warum kapiert das keiner?
:
Bearbeitet durch User
Frank E. schrieb: > Warum kapiert das keiner? Weil sobald es ins Detail geht mehr als dummes Gelaber gefragt ist. Ich kann deinen Ausführungen nur bruchstückhaft folgen, es wäre einfacher Problemanalyse zu betreiben wenn du klare Requirements definierst, was das System an Ende können soll. Ohne Nachdenken gleich auf die 3 Normalformen zu pochen ist auch nicht hilfreich, das kann zu degenerierten Ergebnissen führen. Bisher lese ich nur Adressverwaltung mit bisschen mehr raus. Ansonsten bin ich gerne gewillt mit dir an dem Problem zu diskutieren. Beispiel für Degeneration: Tabelle Vorname id, name Tabelle Nachname id, name Tabelle Name id, vornahme_id, nachname_id
D. I. schrieb: > Bisher lese ich nur Adressverwaltung mit bisschen mehr raus. > Ansonsten bin ich gerne gewillt mit dir an dem Problem zu diskutieren. Ok, danke für deinen guten Willen. Das Problem ist, dass ich nicht richtig weiss, wo ich anfangen soll. Fakt ist, die Adressen sind sehr unterschiedlich. Da sind z.B. Firmen und einzelne "freie" Menschen (z.B. Gutachter). Aber man telefoniert oder vehandelt ja nicht mit Firmen, sondern mit Menschen, beschäftigt in den Firmen. Und Diese Menschen haben wiederum Kontaktmedien (Mail, Mobiltelefon, Schreibtischtelefon usw.). Hinter manchen (Firmen-) Telefonen oder Faxen sind auch mehrere Menschen zu erreichen ... Also mache ich eine Tabelle mit Menschen (z.B. Name, wenn bekannt Privatadresse, Hobbys, Geburtstag, Familienstand usw.). Die, die zu einer Firma gehören, bekommen eine Relation auf die Firmentabelle. Wo ordne ich Selbständige oder Freie ein? Gibts den Mensch Meier UND das Ingenieurbüro Meier? Was mache ich mit den Kontakten (Mail, Telfeon)? In eine eigene Tabelle und je eine Relation auf den Menschen (Privatkontakt wie pers. Handy) oder auf die Firma (Diensttelefon). Was mache ich, wenn er sein Handy bzw. die Rufnummer für Beides verwendet? Wo bringe ich die Position des Menschen (Geschäftsführer, Einkäufer, Ingenierur) in der Firma unter? Gehört die zum Menschen oder zur Firma (im Sinne von: Position ist besetzt mit ...) Ufff. Merkst du was?
:
Bearbeitet durch User
Frank E. schrieb: > Also mache ich eine Tabelle mit Menschen (z.B. Name, wenn bekannt > Privatadresse, Hobbys, Geburtstag, Familienstand usw.). Die, die zu > einer Firma gehören, bekommen eine Relation auf die Firmentabelle. Wo > ordne ich Selbständige oder Freie ein? Gibts den Mensch Meier UND das > Ingenieurbüro Meier? Tabelle mit Menschen ist schonmal gut. Ich würde dann eine Tabelle mit Frimen machen, und eine Firma davon heißt "privat". Zwischen diesen beiden eine besteht eine n:m - Beziehung, also machst Du noch eine dritte Tabelle als Zuordnungstabelle. Somit bekommst Du n Menschen in eine Firma, aber auch denselben Menschen in eine Firma und in die Firma "privat" So würde ich es machen. Plus häufige Fragestellungen als fertige Abfragen hinterlegen (Menschen mit Firmen- und Privattelefonnummern ist mit dem o.g. Prinzip kein Problem)
Gehen wir anderst an die Sache ran. Wir erarbeiten zusammen Modelle, aber du musst letztendlich entscheiden ob das bis dahin ausgearbeitete Modell deinen Ansprüchen genügt. (Ist ja hier schon gratis Consulting :D ) Rainer hat ja schon gut vorgelegt. So könnte ein erster Schuss aussehen (ausgehend von nur innerdeutschen Adressen ohne mich auf konkrete Datentypen festzulegen): Table Address: id street house_nr zipcode city Table Person: id address_id (eine Person wohnt an einer Adresse) surname name email phone ... Table Company: id name ... Table Office (Niederlassung, auch der Hauptsitz waere eine Niederlassung): id address_id (eine Niederlassung hat eine Adresse) company_id (eine Niederlassung gehört zu einer Firma) name ... Table Employee: id office_id (ein Mitarbeiter gehört zu einer Niederlassung) person_id (ein Mitarbeiter ist eine Person) job_role email phone ... Selbstständige/Freie wären Mitarbeiter einer Niederlassung einer Firma
Hier ein Beispiel einer relationalen DB: http://mmvisual.de/Hilfe/EleLa/TutorialDB/TutDB.htm Das ist die DB von "EleLa". Der Adressbereich besteht nur aus einer einzigen Tabelle, die mit der Spalte "ID_ID" sich verweist. Zusätzlich gibt es (neu) nur eine Spalte "KontaktArt" mit der die Adresse als Ansicht z.B. Hotel, Mitarbeiter, Externe usw. deklariert werden kann. Somit kann jeder Adresse eine beliebige Anzahl von Kontaken hinzugefügt werden. Auch kann jeder Kontakt wiederum als einzelne Adresse umdeklariert werden (ID_ID auf NULL setzen) oder jede Adresse als Kontakt einer anderen Adresse gewandelt werden. (ID_ID mit der ID der Hauptadresse versehen) Suchen ist auch viel leichter da alles nur auf eine einzige Tabelle geht. Nachteile: - Adresse (PLZ/ORT/Straße) stehen mehrfach drin. - nicht beliebig viele Verbindungen möglich (E-Mail Adressen, Telefonnummern) Was mich bisher jedoch nicht gestört hat, bzw. ich habe mehr Infos dann in das Feld "Bemerkung" geschrieben. Nur mal so als Anregung wie man das lösen könnte.
Markus M. schrieb: > Nur mal so als Anregung wie man das lösen könnte. Bei allem Respekt vor EleLa welches ja funktioniert, aber scnr: Das kommt raus wenn ein E-Techniker Datenbankmodelle entwirft ;) Warum hast du auf Foreign Keys verzichtet?
D. I. schrieb: > Warum hast du auf Foreign Keys verzichtet? EleLa verwaltet selbstständig die Konsistenz aller Daten, ich habe darauf sehr großen Wert gelegt. Bei ForeignKeys würde bei fehlerhafter Programmierung es knallen und es gäbe eine Exception die man behandeln muss. Außerdem ist das Umorganisieren der Datenbankstruktur während der Entwicklungsphase so leichter (EleLa wird fortlaufend weiter entwickelt). Und EleLa unterstützt direkt 5 Datenbank Systeme, Lokal und Client/Server und kann direkt die Datenbanken anlegen / Updates durchführen. Mit ForeigenKeys wäre dieser Mechanismus deutlich aufwändiger um zu setzen. Nein, EleLa ist KEINE E-Techniker Datenbank. Ich programmiere Datenbanken professionell schon seit 15 Jahren mit unterschiedlichen Systemen. Die Erfahrung daraus nutzte ich für das Design der Datenbank. Ja, man könnte manches "professioneller" machen, ich habe bewusst darauf verzichtet damit auch E-Techniker damit klar kommen. Für mich war der wichtigste Punkt, dass die Daten jederzeit, sogar mit den in EleLa eingebauten Mitteln raus geholt/exportiert werden können, so dass wenn jemand sich für eine andere Software entscheidet, die mühsam eingegebene Daten weiter verwenden kann. Daher auch die dokumentierten Tabellen mit Verknüpfungen. So viele andere Tools die das auch in dem Umfang können kenne ich jetzt nicht. Man kann es halt nicht jedem recht machen ;-)
:
Bearbeitet durch User
Ich entwickle seit mehr als 15 Jahren professionell (und im Hauptberuf!) Datenbanken im GB Bereich ... und finde das Weglassen von Constrains fahrlässig für jedes Datenmodell! Das ein Datenmodell mit referenzieller Integrität schwerer zu warten wäre halte ich für ein Gerücht. Wie immer so gilt auch hier: man muss es nur richtig machen. Es gibt einen guten Grund, warum RELATIONALE Datenbanken so heißen ... dann sollte man die Relationen auch modellieren! Aber das nur am Rande. Zurück zum Thema: eine Adress-Datenbank ist das Einsteiger-Thema schlechthin. Aus diesem Grund gibt es im Netz auch unzählige - meist schlechte - Beispiele. Wenn Du es richtig machen willst, beschäftige Dich mit den Grundlagen der Objeckt-Orientierten-Analyse (OOA) und vor allem mit der Normalisierung (https://de.wikipedia.org/wiki/Normalisierung_%28Datenbank%29). Bringe Dein Datenmodell in die dritte Normalform und alles ist gut :-)
:
Bearbeitet durch User
Günter M. schrieb: > Ich entwickle seit mehr als 15 Jahren professionell (und im Hauptberuf!) > Datenbanken im GB Bereich ... und finde das Weglassen von Constrains > fahrlässig für jedes Datenmodell! Das ein Datenmodell mit referenzieller > Integrität schwerer zu warten wäre halte ich für ein Gerücht. Wie immer > so gilt auch hier: man muss es nur richtig machen. Es gibt einen guten > Grund, warum RELATIONALE Datenbanken so heißen ... dann sollte man die > Relationen auch modellieren! Gerade wenn man das schon lange im Hauptberuf macht, sollte man da meiner Meinung nach deutlich weniger dogmatisch sein. Das sind alles sehr gute Tipps für Einsteiger. Es gibt auch auch Gründe, sich dagegen zu entscheiden. Dazu muss man schon Erfahrung haben, aber das ist nicht automatisch "böse". Gerade in Zeiten, wo viel Logik in die Application-Server gewandert ist, und Datenbanken oft nur noch schnelle Datengräber sind. Auch NoSQL-Datenbanken zeigen, dass der relationale Ansatz nicht immer passend ist. Es gibt durchaus Fälle, wo man das sogar auf eigentlich relationale Datenbanken anwenden kann. Was mich auch wundert ist, dass du dich mit "Datenbaken im GB-Bereich" rühmst. Das sagt ja nichts über die Komplexität aus. Habe schon Datenbanken designt, wo das in einer Tabelle zusammenkommt, in die einfach flach Maschinendaten geschrieben werden. Günter M. schrieb: > Dein Datenmodell in die dritte Normalform und alles ist gut :-) Als Anfängertipp gut, es gibt aber auch hier genug Fälle, wo man mit einem denormalisierten Modell besser fährt. Ob das auch hier bei der Adressdatenbank der Fall sein kann, kann ich nicht beurteilen. Dazu fehlen genauere Anforderungen.
ich will hier keine Grundsatz-Diskussion führen, die den Fragesteller nicht weiter bringt ... aber eine korrekt normalisierte Datenbank im GB-Bereich ist fast automatisch komplex! Es kann im Einzelfall tatsächlich Gründe geben, die ein de-normalisiertes Modell erforderlich machen ... aber dann sollte man sich sicher sein, was man tut. Das ist genauso wie in der Elektronik. Wenn ich als Laie hier eine Frage stelle bekomme ich meist zu hören: lerne erstmal die Grundlagen. Das ist hier genauso. Vermutlich 90% aller Datenbnak laufen auf relationalen DBMS. Demnach sind sie der Standard. Und die Grundlage eine Datenmodells einer relationalen Datenbank sind nunmal Tabellen, die unter einander in Beziehung (Relation) stehen. Und wie wird eine Relation abgebildet? Korrekt: durch Constrains auf Fremd-/Primärschlüssel. Also ist die Grundlage der Datenbankwicklung eben genau dieses: Tabellen und ihre Relationen! Wenn man dann genügend praktische Erfahrung hat, kann man irgendwann man nachdenken, warum es im Einzelfall Sinn machen kann, hiervon abzuweichen. Aber davon ist der TO noch weit entfernt! Und sich mit EleLa zu rühmen ist nun auch nicht unbedingt ein Qualitätsmerkmal für einen Datenbank-Entwickler. Ich habe es vor einigen Monaten mal installiert und kann bis heute nicht verstehen, warum so viele hier es einsetzen - denn aus dem Blickwinkel eines Datenbank-Entwicklers kann es nicht gerade als Vorzeige-Fall dienen. Wie auch diese Diskussion gerade zeigt. Und nochmal: eine relationale Datenbank, die konsequent auf Relationen verzichtet oder bei der keine sinnvollen Relationen gesetzt werden können, hat IMMER ein schlechtes Datenmodell. Ja, das sage ich so dogmatisch, weil ich auch schon genug von diesen Dingern gesehen habe.
:
Bearbeitet durch User
D. I. schrieb: > Table Address: > id > street > house_nr > zipcode > city Das kann schiefgehen, siehe z.B. diesen Artikel: https://news.ycombinator.com/item?id=8907301 Wenn man auf diese Daten keine besonderen Abfragen braucht bzw. Volltextsuche reicht, dann reicht evtl. ein einziges Textfeld für die "Postaddresse" , und man hat weniger Ärger.
Frank E. schrieb: > Ich würde auch gerne möglichst "sauber" nach den Regeln für rel. > Datebanken arbeiten, also keine Wiederholfelder, keine Redundanzen usw., > also die Normalformen 1 bis 3 als Minimum. Vergiss es. Du hast selbst bemerkt, daß eine Datenbankstruktur nicht so einfach auszudenken ist. Vergiss einfach den Ansatz, schon heute zu wissen, was morgen nötig ist. Betrachte deine Datenbank als ein Programm, welches Daten auf einer Seite (Maske, HTML, meinthalben MS-DOS Textbildschirm) mit Eingabefeldern sammelt, diese in (durchsuchbaren, filterbaren) Listen anzeigen kann, und von einer Seite auf eine andere Seite bzw. Liste verweisen kann. Zu Beginn gibt es keine Seite und keine liste und keine dahinterliegende Relationen. Wenn du anfängst, deine Kontakte einzugeben, erzeugst du eine neue Relation (noch ohne Felder) und einen neuen Datensatz auf seiner Seite (noch ohne Eingabefelder) und legst auf ihr die nötigen Eingabefelder an (davon sollte es ein paar nützliche Typen geben, Textfeld, Checkbox, Combobox, Zahl und Datumeingabe ...). Das Programm hat dann die Aufgabe, diese Daten in eine Relation in der Datenbank (beliebige über JDBC/ODBC verknüpfte SQL, z.B. MySQL) abzulegen, und wenn du später was an der Seite änderst (noch ein Feld hinzufügst), dann macht das Programm das eben. Der Seitenediermodus kann ja durchaus eine Sonderoperation sein, aber im laufenden Programm unmittelbar inklusive Reorganisation der Datenbank. Wie flexibel man den Seitenediermodus macht, bleibt dir überlassen, benannte Felder in festem Zeilenabstand im Raster anlegen zu können, verschieben zu können, (entfernen zu können) ist nicht so schwer, wichtig wäre daß eine Seite scollbar wird, wenn sie mehr Eingabefelder bekommt als auf einem Bildschirm darstellbar sind. Du kannst im Laufe der Zeit alle Felder einfügen, die notwendig sind, und alle weiteren Seiten (Relationen) erstellen die du brauchst. Die Einstiegsseite in das Programm ist eine Übersichtsseite auf der die unterschiedlichen erfassten Relationen aufgeführt werden (die uninteressanten legt man ausserhalb des sichtbaren Fensters) plus den Knopf "weitere neue anlegen" und auf die Listenansicht ausgewählter Spalten gehen (die sollte filterbar sein in dem man Feldinhalte, die bekannt sind, vorgibt) und die einen Knopf "neue hinzufügen" hat. Ein nützliches Eingabefeld ist eine Combobox, die Einträge aus einer anderen liste anzeigt, und wenn diese Combobox edierbar ist, diesen Eintrag, falls er noch nicht vorhanden ist, in die andere Relation einfügt. Damit bekommst du "männlich/weiblich" Felder und kannst sie eines Tages um "neutrum" ergänzen etc. Weitere nützliche Felder sind Verweise auf externe Dateien, Bilder. Das letzte, was wirklich interessiert, ist, ob die Relationen normalisiert sind oder nicht. Die Realität ist auch nicht normalisiert. Wichtig ist, daß die Datenbank so flexibel wie die Realität ist.
Also erstmal danke für alle die, die tatsächlich einen Beitrag leisten und nicht nur sich selber darstellen wollten. Ich muss aber wohl nochmal karer machen, warum ich diesen Beitrag geschrieben habe. Bitte den nächsten Satz langsam und Wort für Wort durchlesen: Ich wollte schöpferisch über eine sinnvolle Struktur für eine Adress- und Kontakt-Datenbank diskutieren, deren Inhalte sich bei genauer Berachtung als wesentlich verschiedenartiger und komplexer darstellen, als man bei dem Stichwort "Adressdatenbank" zunächst vermuten mag. Ich benötige keine Grundsatzschulung über Aufbau und Funktionsweise relationaler Datenbankenn oder GUI-Elementen, ich verwende sie ständig selber und gebe sogar Kurse dazu. Mein Beitrag ist kein Hilferuf sondern sollte Diskussion anregen, weil es bekanntlich zu jedem Ziel mehrere Wege gibt ... Es geht nicht darum, dass ich Tabellen mit Keys verbinde, sondern eher um die Abbildung der Realität auf ein Datenmodell. Das Hauptproblem ist aus meiner Sicht die unterschiedliche Wertigkeit der znächst scheinbar gleichwertigen Daten. Die Idee z.B., alle Freien und Selbständigen in eine Firma "Privat" zu stecken, hatte ich auch schon. Das ist zwar im technischen Sinne bequem, ob es auch praktikabel in einer GUI für die Nutzung durch eine Sachbearbeiterin umsetzbar ist, wäre z.B. ein Diskussionsthema ... Die Adress- und Kontakdatebank soll mal Bestandteil einer Wawi-Software werden und auch von nicht-EDV-affinen Anwendern schnell und bequem benutzt werden können, ohne dabei auf Informationen duch "Verflachung" zu verzichten.
:
Bearbeitet durch User
Frank E. schrieb: > Das ist zwar im technischen Sinne bequem, > ob es auch praktikabel in einer GUI für die Nutzung durch eine > Sachbearbeiterin umsetzbar ist, wäre z.B. ein Diskussionsthema ... Das sind zwei unterschiedliche Dinge wie du es intern speicherst und im Frontend dem User präsentierst.
D. I. schrieb: > Frank E. schrieb: >> Das ist zwar im technischen Sinne bequem, >> ob es auch praktikabel in einer GUI für die Nutzung durch eine >> Sachbearbeiterin umsetzbar ist, wäre z.B. ein Diskussionsthema ... > > Das sind zwei unterschiedliche Dinge wie du es intern speicherst und im > Frontend dem User präsentierst. Ja, stimmt schon. Aber der Satz ist ungefähr so wahr wie: "Morgen wirds wahrscheinlich wieder hell." :-) Na klar ist interne Datenhaltung und GUI-Präsentation nicht das Gleiche, aber eben auch nicht vollkommen unabhängig voneinander. Ich kann in der GUI nur darstellen, was das Datenmnodell hergibt - zumindest mit vernünftigem Aufwand. Aber vlt. ist der Gedanke garnicht so verkehrt. Schließlich sieht der Nutzer die GUI ind nicht die Relationen. Möglicherweise sollte man das Problem mehr aus Nutzersicht angehen und dann das interne Datenmodell mehr danach orientieren ...
Naja wenn du weißt, dass Selbstständige / Freie immer einer besonderen Firma zugeordnet sind, dann ist die Information sehr wohl vorhanden. Du könntest aber auch parallel zur Tabelle "Employee" noch eine Tabelle "Freelancer" anlegen, die dann eine Relation zu Person hat und mit keiner Firma verknüpft ist. Es ist Aufgabe der Zwischenschicht, Modelldaten so aufzubreiten, dass sie für die View entsprechend verwendet werden können. Bei MVC ist das der Controller, bei MVVM das ViewModel.
D. I. schrieb: > Naja wenn du weißt, dass Selbstständige / Freie immer einer besonderen > Firma zugeordnet sind, dann ist die Information sehr wohl vorhanden. Naja, "wissen" ist jetzt zuviel gesagt. Es war eine mögliche Variante, zuende gedacht ist das aber noch nicht ...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.