Datenbankstrukur - Minitabellen

[Xelanja]

Guten Tag an alle! Bitte helft mir. Zunächst zu meinem Wissenstand. Ich bin Anfänger was DatenbankDesign angeht und habe eine Frage. Über viele Jahre haben ich Milliarden Daten in der Ahnenforschung zu Orten und Familien zusammengetragen und bislang in einer "dicken" Excelmappe gespeichert.
Ich würde das aber gern in eine Datenbank übernehmen.
Ich weiß wie das geht, weiß sowohl wie man die Datenbank anlegt,als auch wie man sie abfragt oder ergänzt. Jetzt kommt das ABER. Aus Struktur der Daten ergibt sich das Problem, dass ich, wenn ich die Redunanz reduzieren will, zig Tabellen mit nur 2 oder drei Spalten habe.
Alternativ könnte ich natürlich Include-Dateien mit zahllosen Variablen für die Abfragen nutzen, aber das sieht (für mich) dann ziemlich unsauber aus und wäre auch ätzend zu warten. Bestes Beispiel- Quellen. Es gibt c. 500 Quellen. Um die nicht hinter jeden Datensatz schreiben zu müssen, böte sich eine eigene Tabelle An: Name der Quelle-Primär oder Sekundärquelle. Name der Quelle als Schlüsselwert. So weit, so gut. Aber mehr Inhalte gäbe es für diese Tabelle eben nicht. Und solche Miniaturen ergäben sich 10-15. Kann man das irgendwie umgehen und trotzdem noch eine ordentliche Struktur hinbekommen? Leute, ich weiß, dass ich dahingehend blutiger Anfänger bin uns habe auch weder in der Suche, noch in einschlägigen, allgemeinverständlichen Büchern über Datenbanken etwas darüber gefunden. Danke im Voraus.

 

[castorp]

Ist doch in Ordnung. Es gibt keine Regel, die besagt, dass eine Tabelle mehr als drei Spalten haben muss.

 

[dabadepdu]

Kann man das irgendwie umgehen und trotzdem noch eine ordentliche Struktur hinbekommen?

Das ist eine berechtigte Frage, aber sie trifft nicht den Kern der Modellierungsstrategien in einem RDBMS.
Du willst keine Redundanzen, weder Du noch die Modellierungstheorie allgemein. Die Konsequenz sind solche kleinen Tabellen. Ich schließe nicht aus, dass irgendwo Grenzen erreicht werden, die einen dazu bewegen können, die Grundlagen der Modellierung zu verlassen und andere Wege zu gehen, aber davon bist Du mit 20 Tabellen und ein paar Millionen Datensätzen weit entfernt.

Es gibt das Key Value Datenmodell (wenn es unbedingt sein muss), aber das ist in der Handhabung viel umständlicher, als einmal ein paar kleine, passgenaue Tabellen anzulegen. Es gibt neben der klassischen relationalen Tabellenmodellierung andere Möglichkeiten, JSON (NoSQL) und anderes, die helfen aber an dieser Stelle nur sehr bedingt.

"Sauber" ist also tatsächlich die Modellierung mit "vielen", manchmal kleinen Tabellen. Das ist also eher ein Muss, wenn man sauber sein will. Und darüber hinaus ist es nicht nur sauber, sondern auch kein Handling- oder Performance Problem.

Es ist einfach nur etwas Fleiß und Sorgfalt gefordert.

Name der Quelle als Schlüsselwert. So weit, so gut

Das ist dagegen nicht sauber. Du verwendest idR technische ID als Schlüsselwert, sie haben keine andere Bedeutung/Funktion als der (eindeutige) Schlüsselwert zu sein, Nutzdaten wie Namen, Bezeichner, Abkürzungen, Artikelnummern o.ä. werden dafür nicht verwendet.

Wenn Du bei der Modellierung ein Problem hast, melde Dich einfach hier.

 

[Xelanja]

Das ist eine berechtigte Frage, aber sie trifft nicht den Kern der Modellierungsstrategien in einem RDBMS.
Du willst keine Redundanzen, weder Du noch die Modellierungstheorie allgemein. Die Konsequenz sind solche kleinen Tabellen. Ich schließe nicht aus, dass irgendwo Grenzen erreicht werden, die einen dazu bewegen können, die Grundlagen der Modellierung zu verlassen und andere Wege zu gehen, aber davon bist Du mit 20 Tabellen und ein paar Millionen Datensätzen weit entfernt.

Es gibt das Key Value Datenmodell (wenn es unbedingt sein muss), aber das ist in der Handhabung viel umständlicher, als einmal ein paar kleine, passgenaue Tabellen anzulegen. Es gibt neben der klassischen relationalen Tabellenmodellierung andere Möglichkeiten, JSON (NoSQL) und anderes, die helfen aber an dieser Stelle nur sehr bedingt.

"Sauber" ist also tatsächlich die Modellierung mit "vielen", manchmal kleinen Tabellen. Das ist also eher ein Muss, wenn man sauber sein will. Und darüber hinaus ist es nicht nur sauber, sondern auch kein Handling- oder Performance Problem.

Es ist einfach nur etwas Fleiß und Sorgfalt gefordert.


Das ist dagegen nicht sauber. Du verwendest idR technische ID als Schlüsselwert, sie haben keine andere Bedeutung/Funktion als der (eindeutige) Schlüsselwert zu sein, Nutzdaten wie Namen, Bezeichner, Abkürzungen, Artikelnummern o.ä. werden dafür nicht verwendet.

Wenn Du bei der Modellierung ein Problem hast, melde Dich einfach hier.

Schmunzel. Erstmal danke für die Mühe. Deine Kritik war gut und ich werde sie beherzigen. Mein Problem ist nicht, die x-te Normalform einer Datenbank zu erreichen, ich bin Laie und verstehe davon so gut wie nichts (das mit den Normalformen war das Einzige, was ich in den Fachbüchern verständlich und logisch fand). Aber ich habe vor Jahren für meine private Webseite eine Datenbank gebastelt. 150 Spalten und c. 300 Einträge. Für eine Datenbank ist das natürlich Mikromanagement, aber neben der unglaublich umständlichen Wartbarkeit musste ich das Monster Jahre später mal anpassen ... Sagen wir- ich hab sie nach 4 Stunden Wutausbrüchen gelöscht (auch weil ich den Fehler gemacht hatte, in die Abfragen Inhalte zu packen, die nun natürlich nicht mehr stimmten, aber das ist das andere Problem, auf das Du mich gerade wieder aufmerksam gemacht hattest- keine Inhalte als Schlüssel verwenden).
Die Datenbank, die ich jetzt erstellen möchte ist, natürlich (zunächst), auch winzig. Aber da dort zukünftig viele Personen dran arbeiten werden, möchte ich Folgendes erreichen:
1. Die Tabellen inhaltlich klar voneinander trennen (Personen für sich, Orte für sich, Ereignisse, Quellen für sich, etc.)
2. Alles was mehrfach getippt werden muss, auslagern und in eigene Tabelle schieben, damit es notfalls mit einem Rutsch geändert werden kann. z.B. mehrere Ereignisse mit minimalem Aufwand von einer Person oder einem Ort zu einem anderen verschieben
Daraus ergeben sich wirklich viele Minitabellen und ich war mir einfach nicht sicher, ob das man das so machen darf/kann. Schließlich wäre es ja möglich, dass jemand anders mein Frankensteinsches Geschöpf später weiterpflegen muss.
In meiner "dicken" Excelmappe habe ich das von Grund auf so gehandhabt. Die hat halt unzählige "Bibliothekstabellen" mit 2 oder 3 Spalten, die einfach miteinander verknüpft sind.
Aber dort musste ja auch nur ich damit klarkommen ;-).
Wird bestimmt nicht die letzte doofe Frage sein, die ich hier stelle, aber diese ist erst einmal beantwortet und ich werde nun erstmal eine Landkarte für mein Datenbänkchen erstellen.

 

[dabadepdu]

Daraus ergeben sich wirklich viele Minitabellen und ich war mir einfach nicht sicher, ob das man das so machen darf/kann.

Das "muss" man so machen. Eben wegen der Normalform, die genau die Lösung für all die Redundanz- , Bearbeitungs- und Programmierprobleme ist, die ohne Normalisierung auftreten.

Schließlich wäre es ja möglich, dass jemand anders mein Frankensteinsches Geschöpf später weiterpflegen muss.

Jeder Nachfolger wird für ein normalisiertes Modell dankbar sein, wenn er etwas von der Sache versteht. Und jede andere Form wäre nicht nur bei der Weiterentwicklung aufwändiger. Klingt vielleicht merkwürdig, ist aber einfach so.
Das gilt nicht nur für Deine Nachfolger, sondern auch für Dich: Es ist am wenigsten Arbeit und die sauberste Herangehensweise.

Nur als Beispiel- auch wenn Dir das mglw. bereits lange klar ist.
Du kannst natürlich einen "Kompromis" modelieren.
Im EU Durchschnitt hat eine Familie 1.5 Kinder, also nehmen wir eine Tabelle, wo man 3 Kinder eintragen kann (sicherheitshalber). Der Kompromis dürfte klar sein.
Na gut, ist ja eine Ahnentabelle, früher hatte man mehr Kinder, also nehmen wir mal 7 Kinder. Der Kompromis ist dadurch nicht verschwunden.
Ok, also für alle Fälle 10 Kinder ..

Die Umsetzung (Programmieraufwand) und auch die Bedienung wird dabei immer miserabler.

Und als Gegenbeispiel noch ein Hinweis, Normalisierung ist die Theorie, wie sähe ein guter Kompromis aus, falls er nicht vermeidbar ist?
Das Ziel der Normalisierung ist Konsistenz. Macht man bei der Normalisierung Abstriche - aus Gründen-, dann muss man Extraaufwand in die Konsistenzsicherung stecken. Das ist dann der Preis für unvollständige Normalisierung.

 

[ukulele]

Ein gut normalisiertes Datenmodell ist eigentlich einfach, und mit den passenden Mitteln, also einem vollwertigen DBMS, nicht irgendwie Access oder so, auch einfach zu bedienen. Schwierig wird es aus meiner Sicht erst bei der Darstellung von Daten oder Benutzereingaben, je nachdem wie das umgesetzt wird.

Bilde doch mal ein Beispiel mit konkreten Informationen vom dem du meinst, das eine kleine Tabelle dafür der Logik nach geboten wäre aber wo du auf eine eigene Tabelle verzichten wollen würdest. Ich kann mir nicht so konkret vorstellen, wo jetzt wirklich ein Problem entsteht. Ich begreife das besser anhand konkreter Fälle.

 

[Xelanja]

Nur als Beispiel- auch wenn Dir das mglw. bereits lange klar ist.
Du kannst natürlich einen "Kompromis" modelieren.
Im EU Durchschnitt hat eine Familie 1.5 Kinder, also nehmen wir eine Tabelle, wo man 3 Kinder eintragen kann (sicherheitshalber). Der Kompromis dürfte klar sein.
Na gut, ist ja eine Ahnentabelle, früher hatte man mehr Kinder, also nehmen wir mal 7 Kinder. Der Kompromis ist dadurch nicht verschwunden.
Ok, also für alle Fälle 10 Kinder ..

Die Umsetzung (Programmieraufwand) und auch die Bedienung wird dabei immer miserabler.

Und als Gegenbeispiel noch ein Hinweis, Normalisierung ist die Theorie, wie sähe ein guter Kompromis aus, falls er nicht vermeidbar ist?
Das Ziel der Normalisierung ist Konsistenz. Macht man bei der Normalisierung Abstriche - aus Gründen-, dann muss man Extraaufwand in die Konsistenzsicherung stecken. Das ist dann der Preis für unvollständige Normalisierung.

Weißt Du, genau das ist das Problem. Es ist eben KEINE Ahnentabelle, denn Vorahren interessieren mich eigentlich nur meine. Aber wenn man damit beginnt, stößt man sehr schnell auf unglaublich viele Informationen über die verschiedensten Orte, Ereignisse, die dort stattfanden und die in Beziehung zueinander standen (beweisbar). Da ist auch für Anfänger viel freier Spielplatz, da sich die Zusammenhänge immer aus der ganz individuellen Familienkonstellation ergeben. Ein Beispiel. Einer meiner Vorfahren war während seiner Militärzeit in Potsdam stationiert. Kein Mensch käme auf die Idee, bei der Suche nach Daten über Familienbeziehungen im Erzgebirge, mal eben so in Potsdam zu suchen (es sei denn, es gibt im Erzgebirge einen Hinweis auf einen Zusammenhang). Und dann stößt man beim Sichten der Quellen auf Zufallsfunde. Und es ist auch wichtig, diese Infos zur Verfügung zu stellen, denn bei vielen klemmt es ja schon am Lesen der alten Schriften, am Latein oder einfach daran, dass viele "nichtstudierte" Leute wie ich, Angst haben in ein Archiv zu gehen, aus Angst, dort was falsch zu machen oder sich zu blamieren. Es gibt dafür große Datenbanken, aber nachdem ich 10 Jahre damit gearbeitet habe, weiß ich, dass die meisten super schwer zu durchsuchen sind. Bevor ich mich selbst rangesetzt habe, meine Daten zu ordnen und erstmal den Umfang dessen zu kartographieren, was ich überhaupt speichern will, welche Zusammenhänge dabei hergestellt werden können/sollen und (genau da bin ich jetzt) wie sich das in einer wartungsfreundlichen und übersichtlichen Datenbankstruktur abbilden lässt, hatte ich die Gelegenheit, mir mal die Datenbank eines megagroßen Spieles und eines Versandhandels an zu sehen, erstere mit Milliarden Datensätzen. Und ich dachte mir einfach nur- nein. So will ich das nicht. So geht das einfach nicht. Ich weiß nicht, ob andere an meinem "Werk" jemals Interesse haben werden (obwohl ich daraufhin schon angeschrieben wurde) und wenn ja, wieviele. Aber eine Sache weiß ich aus trauriger Erfahrung. Schließt man am Anfang Kompromisse, wie klein sie auch sein mögen, kann es mit Anwachsen der Datenbank im Nu zu spät sein, das in vertretbarer Zeit wieder zu ordnen, als Einzelkämpfer und mit wenig Kenntnissen, ist diese Grenze noch viel schneller erreicht. Deshalb habe ich hier gefragt. Als Anfänger ist das superschwer, weil man gern "Ergebnisse" sehen würde und als die Geduld verteilt wurde, habe ich mich definitiv geduckt, aber es ist mir wirklich wichtig. Aber indem Ihr mir bestätigt habt, dass ich keinen Fehler mache, wenn meine Datenbank aus x Minitabellen besteht, gehe ich jetzt um einiges erleichterter wieder ans Werk ;-).

 

[dabadepdu]

als die Geduld verteilt wurde

Das ist bestimmt kein Alleinstellungsmerkmal bei Dir

Dein Problem ist also aufwändiger als eine Ahnentabelle. Nur mal als Idee:

Lebensläufe träfe es besser?
Was macht einen Lebenslauf aus?
Menschen, Familie, deren Aufenthaltsorte, Ereignisse, Ausbildungsplätze, Arbeitsplätze, Krankheiten, Freunde, Nachbarn, Kollegen, Vereinsmitglieder, Hobbies ..
Die Modellierung einer Ahnentabelle muss also erweitert werden, man sagt generischer werden.
Ein Mensch hat dann Beziehungen zu anderen Menschen, die Beziehung hat einen Typ, Vater, Mutter, Onkel, Arbeitskollege/Chef, ..
Zu einem Zeitpunkt oder in einem Zeitraum gibt es einen Aufenthaltsort, berufsabhängig vielleicht sehr viele. Früher wahrscheinlich viel weniger als heute, ein Wohnort und ein "Arbeitsort", ..
Daraus folgt, es wird keine Tabelle "Geburtsort" geben und keine Tabelle "Wohnort", es gibt nur "Ort"/"Location", die Verknüpfung zwischen Mensch und Ort soll ein Merkmal führen, das den Zweck beschreibt, den Zeitraum, einen bekannten Zeitpunkt, eine ungefähre Dauer, nichts davon oder Kombinationen ...

Generalisierung, auch der gesamte Modellierungsprozess ist kein einmaliger, großer Wurf. Geduld hin oder her, Du wirst einige Dinge erst "unterwegs" bemerken und dann umbauen. Das ist nicht nur eine Geduldsfrage, sondern auch eine Frage der Werkzeuge und dem Umgang sowie den Möglichkeiten der Werkzeuge.
Man kann an einem Tag 10 Varianten eines Datenmodells anlegen, mit Daten befüllen und ausprobieren, ob alles funktioniert. Dabei braucht man nichts zu programmieren, nur eine Datenbank und einen Editor oder auch eine Tabellenkalkulation. Bei der Datenbank, dem Datenmodell muss man sich bewusst machen, dass es nicht nur um Tabellen geht. Es gibt eine Menge anderer Objekte und Features, die eine DB bereitstellt oder eben auch nicht.
Man kann alle diese Schritte in Scripte eintragen und die entstandene Datenbank anschließend löschen, eine andere ausprobieren oder alte wieder herstellen.
Wenn man mit der Programmierung beginnt, kann man diese Tätigkeiten und die Umsetzung darauf ausrichten, dass es Änderungen geben wird.

Man überlegt sich also nicht nur die Herangehensweise bei der Modellierung, sondern auch bei den Werkzeugen und dem Vorgehen insgesamt. Hat man einen guten Ausgangspunkt gefunden, dann ist der größte Teil der Arbeit stetige Erweiterung, wenig(er) Umbau.

 

[ukulele]

Im Prinzip hast du ein Datenmodell ohne feste Entitäten, also z.B. Autos, Häuser, Personen, etc., alles kann gebraucht werden. Eine Möglichkeit wäre es, es komplett frei anzugehen:

1) Eine Tabelle "Entität". Jede Entität wird dort mit einem Typen klassifiziert und bekommt einen Namen / Bezeichnung und ggf. noch ganz grundlegende Eigenschaften wie Datum von / bis. Man kann dann mit Normen arbeiten aber eigentlich ist alles völlig offen.

2) Eine Tabelle für Attribute zur Entität. Nennt sich Entity Attribute Value vom Design her. Entity–attribute–value model - Wikipedia. )
Dabei sind i.d.R. alle Informationen als Zeichenkette abgelegt, weil die Spalte Value halt nur einen Datentypen haben kann. Man kann das aber auch erweitern so das es z.B. eine eigene Tabelle für Datumsattribute gibt, oder man macht es etwas schmutzig und nimmt mehrere Spalten für verschiedene Datentypen.

Der Punkt ist, das man beliebige Eigenschaften modellieren kann und zwar eben die, die man hat / kennt. Ich habe mir ein Inventar-System so aufgebaut, dort gibt es dann Spalten pro Attribut für Fremdschlüssel zum Inventar, von, bis, typ, bezeichnung, wert, einheit und ggf. bemerkung. Beispiel:

typ = Identifikation
bezeichnung = Produktnummer
Wert = PBU120GS25SSDR

oder

typ = Leistungsmerkmal
bezeichnung = Speicherkapazität
Wert = 160
Einheit = GB

Ein Objekt im Inventar kann damit auch mehrere Produktnummern / Seriennummern haben, das ist durchaus üblich, oder mehrere Leistungsmerkmale oder ich pflege da auch z.B. Anschlüsse von Mainboards.

3) Eine Tabelle für Beziehungen zwischen Entitäten. So kann alles mit allem zusammen hängen. Ich persönlich würde auch noch eine Untertabelle dazu definieren, ich mache das in unserem eigentlichen CRM zwischen Unternehmen und Personen so. Dabei gibt es zwischen Unternehmen und Person immer maximal eine oder eben keine Beziehung. In einer Untertabelle werden dann unterschiedliche Zustände der Beziehung definiert, also z.B. Ausbildung von bis und Arbeitnehmer von bis oder Inhaber von bis. Auch hier wäre ein EAV für Attribute denkbar.

4) Für bestimmte Dinge kann man zusätzlich feste Tabellen definieren, z.B. Quellen. Bei mir im Inventar habe ich das z.B. für Rechnungen so gemacht.

Vorteil:
Das Modell ist extrem flexibel und kommt mit wenig Tabellen aus. Du musst nur eine Tabelle durchsuchen wenn du nicht genau weißt, als was etwas angelegt wurde. Visuell lässt sich das eigentlich auch leicht aufbereiten als Punkte (Entitäten) mit Verbindungen (Beziehungen).

Nachteil:
Referenzielle Integrität kannst du sicherstellen, aber Plausibilität ist natürlich nicht sonderlich einfach. Man kann sich Abfragen bauen die z.B. Personen mit drei biologischen Eltern finden, ich glaube aber gar nicht mal, das das so ins Gewicht fallen wird.

Ein letzter Punkt: Einen Haken habe ich oft bei Beziehungen in meinem CRM. Datumsangaben von bis sind sehr hilfreich. Z.B. von wann bis wann eine E-Mail Adresse gültig war. Leider kenne ich häufig das genaue Datum nicht. Daher würde ich eventuell weitere Spalten anlegen wie z.B. einen Wert bis_Datum, einen Wert bis_Jahr, einen Wert bis_Monat und eine Spalte bis_nicht_nach_datum oder so. Das macht natürlich Suchen über einen Zeitraum sehr aufwendig aber ich habe ganz oft Informationen die ich leider nicht abbilden kann und das ärgert mich.

 

[Xelanja]

Ich habe einfach mal ein Beispiel gestern abend zusammengesucht, um mal zu verdeutlichen, warum ich so in den Seilen hänge. Vieles hast Du mir allerdings bereits beantwortet, das lese ich mir aber heute abend in Ruhe durch, dazu reicht mein Päuschen nicht:

Ich glaube, jetzt muss ich mal konkret werden. Ich nehme mal einen Satz Daten aus den Exceltabellen, die zusammengehören:

Ort: Oelsnitz Erzg.
Flurstück:96
Vorher:94 und 96
Baugrund: Wüstung Größe: (Maße und Einheit)
localisiert: nein (in anderen Fällen gibt es aber Angaben)
Erbaut: (um, nach vor,von-bis) Jahr1,Jahr2 (Quelle)
Abgerissen: (um, nach vor,von-bis) Jahr1,Jahr2 (Quelle)
Nutzung1: Wohnhaus(Quelle)
Nutzung2: Mühle (Quelle)
Besitzer (folgen Besitzer 1-12 mit Jahreszahlen, Preisen (Preis und Währung) und teilweise wiederum Quellen)
Ergänzungen Erbaut (mit Quellen): z.B.im grünbergschen Teil , Festgelegter Zins: (Zahl und Währung) Fronpflichtig: in welcher Höhe, wann abgelöst
Ergänzungen Nutzung: (das ist meist einfach ein Text) z.B. Die zum Grundstück gehörende Teichmühle, eine Mahlmühle mit zwei Gängen, taucht nach 1760 in den Kaufverträgen nicht mehr auf, sie fiel vermutlich 1760 dem großen Brand zum Opfer
Ergänzung Abriss: Beim großen Brand 1760 wurden die Gebäude teilweise niedergebrannt, das Wohnhaus in den Folgejahren neu errichtet.

Quelle:Chronik von Oelsnitz Autor:Emil Junghannß Primärquelle-nein
(Dabei muss bei der jeweiligen bezugnehmenden Information auch die Seitenzahl angegeben sein)
……………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………..…………………………………………………………………………………………………………..

Besitzer3(wieder als Beispiel)
Junghanns, Daniel geboren, getauft, konfirmiert, geheiratet (wen), verwitwet, geheiratet2 (wen), gestorben, beerdigt (immer mit Ort/Datum/Quelle) Ergänzungen: Hier muss ich tatsächlich einen Kompromiss eingehen, indem ich Paten, Trauzeugen etc. nur als Text hinterlege, sonst ufert das aus) Kinder 1-15 (ich habe mich da an der Familie mit den meisten Kindern orientiert, um 1500 haben wir da einmal 12 Söhne und um 1800 13 Kinder)

...........................................................................................................................................................................

Zeittafel: (aus dem oben geschriebenen ergibt sich folgender Eintrag)
Jahr 1760 Ort Oelsnitz/Erzg. großer Brand Weitere Informationen: Der Brand entstand vermutlich wetterbedingt. Es herrschte in jenem Sommer große Hitze.

Was ich habe: c. 50% der Daten bereits atomar in Tabellen erfasst. Eigene Domain mit der Option 10 Datenbänke an zu legen (mySql), eigenen Mailaccounts, mehreren möglichen FTP Zugängen. Ich weiß, wie man Datenbänke abfragt und das in eine Webseite einbindet.

Mir ist klar, dass die Struktur einer solchen Datenbank weit über dem ist, was sich ein Anfänger zumuten sollte, aber es sind wiederum zu wenige Datensätze (insgesamt c. 5000 alles in allem) und es gibt auch mein Budget nicht her, mir das erstellen zu lassen. Außerdem macht es Spaß und ich lerne schnell.

Was klar ist:
Tabelle Wärung:
Abkürzung Name Erläuterung
Tabelle Maße:
Abkürzung Name Erläuterung

Tabellen Wohnhäuser, Gartenhäuser, Frongüter, Mühlen, Sonstige

 

[Xelanja]

Ich habe mir das in der Wiki erstmal durchgelesen. Erste Reaktion - Autsch-da hab ich mir ja wat injetreten! Aber das wäre eine gute Option. Melde mich wieder, wenn ich das Ganze auch noch wirklich verstanden habe ;-)

 

[castorp]

Heutzutage würde ich ein hybrides Modell (relational + JSON) einem EAV Modell vorziehen. D.h. Attribute, die alle Ausprägungen einer Entität gemeinsam sind, werden relational modelliert (sprich explizite Spalten mit den richtigen Datentypen). Dynamische Attribute (die, die bei jedem "Typ" anders sind) werden dann in einer JSON Spalte gespeichert. Im Grunde könnte man den Inhalt der JSON Spalten über check constraints prüfen ob die Werte auch zum Typ des Eintrages passen.

Tabellen Wohnhäuser, Gartenhäuser, Frongüter, Mühlen, Sonstige

Hmm, für mich klingt das erstmal so, als könnte man das in einer Tabelle zusammenfassen (mit einer Spalte "haus_typ" in der dann "wohnhaus", "gartenhaus" usw. drin steht).

 

[ukulele]

Also ich würde meine Idee aus Post #9 dazu weiter verfolgen, ob jetzt mit EAV oder JSON spielt am Ende kaum eine Rolle
. Dazu muss man natürlich genau wissen was eine Entität und was ein Attribut ist, hätte ich vielleicht erwähnen sollen.

Dazu würde ich für einige Dinge richtige Tabellen anlegen, z.B. unbedingt für Quellenangaben.

Auch für Dinge, die oft vorkommen. Eventuell z.B. Flurstücke, wobei das in sich natürlich schon komplex ist wenn z.B. Flurstücke, wie in deinem Beispiel, gemeinsam genutzt werden oder zusammen geführt werden. Aber da gibt es ja klar geregelte Vorgänge, das kann man mit viel Liebe zum Detail abbilden. Man müsste sich aber die Frage gefallen lassen, ob es die Mühe wert ist.

Tabellen Wohnhäuser, Gartenhäuser, Frongüter, Mühlen, Sonstige

Das zeigt mir eigentlich, das du noch ganz am Anfang stehst. Ein gutes Beispiel, um sich mal mit Normalisierung in der klassischen Form zu befassen. Hier wäre definitiv eine Tabelle für die Entität "Gebäude" angebracht, aber sicherlich nicht Tabellen für jeden Gebäudetyp.

 

[dabadepdu]

Im Prinzip hast du ein Datenmodell ohne feste Entitäten, also z.B. Autos, Häuser, Personen, etc., alles kann gebraucht werden. Eine Möglichkeit wäre es, es komplett frei anzugehen

Das wäre eine Möglichkeit, aber die hat relativ viel Overhead, besonders wenn man zwar so speichert, aber in der Nutzung, der Darstellung oder Bearbeitung doch wieder in klassische Tabellenfrom transformiert. Ich mag es nicht so.

Ich würde da immernoch ein möglichst generalisiertes Modell vorziehen. Beispiel "Wohnhäuser", ...

Tabellen Wohnhäuser, Gartenhäuser, Frongüter, Mühlen, Sonstige

Die Tabelle wäre "Gebäude" mit einer Typspalte, Werte wären eben Wohnhaus, Gartenhaus, Mühle, ..

Satz Daten aus den Exceltabellen, die zusammengehören

Man muss irgendwo, zunächst, bei der Umsetzung Grenzen festlegen. Hast Du ja auch gemacht. Wenn Du bereits viele Daten gesammelt hast, bedeutet das nicht, dass sie alle auf dem Müll landen müssen.
Alles was nicht relational modelliert wird, kann man in Document Spalten (JSON) mitführen/aufheben, allem voran komplette Texte, wie Du erwähnt hast. Es geht nicht verloren und man könnte sogar Zugriff, Abfrage und Pflege dazu implementieren. Nach und nach kann man neu gliedern, Modellerweiterungen realisieren und die Daten transformieren.

Viele Stellen muss man vielleicht auch gar nicht mehr komplett implementieren. Orte, Straßen bis hin zu Gebäuden gibt es frei zugänglich und nutzbar als Open Source, inkl. Libs zur Darstellung- falls nötig.

 

[dabadepdu]

ob jetzt mit EAV oder JSON spielt am Ende kaum eine Rolle

Das sehe ich nicht so. Der Umgang mit JSON Objekten unterscheidet sich m.E. schon recht deutlich von EAV und das in diesem Fall vorteilhaft.
Letzlich ist man an der Stelle auch bei dem Punkt Datenbank Features. Wenn die gewählte DB keine oder schlechte JSON Unterstützung bietet, kann man es nicht nutzen und fällt dann auf ein EAV Modell zurück (oder nimmt halt ne andere DB mit guten JSON Features)