Datenbank Design

[Forumsgast]

Welche Möglichkeiten gibt es möglichst viel unbekannte Entitäten abzubilden ohne die Zahl der Tabellen ständig anzupassen oder Spalten hinzuzufügen?

Ich habe z.b. Eine Ländertabelle, der ich immer mehr Daten zuordnen möchten. Also z.B. Telefonvorwahlen, Länderkennzeichen, usw. Nun habe ich erstmal die Datenbank so erstellt, dass eine Tabelle mit Namen der Länder meine Basis darstellt. Diese enthält IDs als Primärschlüssel. In einer weiteren Tabelle habe ich Entitäten stehen wie z.b. diese Länderkennzeichen. Allerdings nicht in Spalten sondern als Name der Entität. z.B. hab ich einen Eintrag Länderkürzel nach ISO... und eine ID als Primärschlüssel. In einer 3. Tabelle habe ich die Werte dann zusammengeführt. Also den Fremdschlüssel der Ländertabelle und den Fremdschlüssel der Entitäten-Tabelle mit z.b. Länderkürzel.

Der Nachteil dieses Vorgehens ist allerdings, dass meine Abfragen recht kompliziert werden. Da ich davon ausgehe, dass es ein Standartproblem sein muss, haben sicher Leute schon Lösungen oder geeignete Antworten. Ich habe bisher keinen anderen Weg gefunden, wenn die Tabellen nicht angepasst werden sollen.

[Forumsgast]

Was spricht dageben, das als JSONB abzubilden?

test=*# create table laender(id int primary key, name text, eigenschaften jsonb);
CREATE TABLE
test=*# insert into laender values (1, 'Deutschland', '{"Kennzeichen": "DE", "Vorwahl": "0049"}');
INSERT 0 1
test=*# insert into laender values (2, 'Vietnam', '{"Kennzeichen": "VN", "Vorwahl": "0084"}');
INSERT 0 1
test=*# insert into laender values (3, 'USA', '{"Praesident": "Trump", "Kontinent": "Nordamerika"}');
INSERT 0 1
test=*# select id, name, eigenschaften->>'Kennzeichen' from laender ;
 id |    name     | ?column?
----+-------------+----------
  1 | Deutschland | DE
  2 | Vietnam     | VN
  3 | USA         |
(3 Zeilen)

Das ist bei Bedarf indexierbar und damit auch schnell, mehr Infos z.B. hier: https://blog.2ndquadrant.com/tag/json/

[Forumsgast]

Man kann auch einfach ein paar Views bauen.
Entweder baut man die thematisch oder meinetwegen auch historisiert oder kombiniert, je nach Bedarf. Man muss es natürlich unter Kontrolle haben.
Extremfall wäre ein Boss View, in dem alle Tabellen zusammengeführt werden. An vielen Stellen sicher unnötig und vielleicht ein Performancefresser, an anderen vielleicht sehr praktisch, weil übersichtliches select statement.
Nachträgliche Änderungen können in neue Views fließen, die in neuen Seiten eingesetzt werden oder mit einer kleinen Änderung eines bestehenden Views an jeder Stelle im bestehenden Code genutzt werden. Die Nutzung von Views statt Tabellen empfiehlt sich sowieso immer. Irgendwann wenn der Boss View zu fett wird, baut man eine neue Tabelle daraus und biegt den Boss View darauf um, z.B.

JSON oder JSONB ist natürlich an Flexibilität unschlagbar, zumindest in der Abfrage, nicht unbedingt in den Formularen zur Datenpflege. (Außer man hat dafür wieder dynamische Klassen)
Ich persönlich würde JSON eher für Nutzdaten einsetzen, die nicht so viel mit Businesslogik zu tun haben. Also irgendwas, das den Kunden interessiert, nicht aber die Anwendung.
Ländercodes usw. sehe ich da zwiespältig, kommt auf den Fall an.

[Forumsgast]

Irgendwie war mir klar, das dieses Thema nicht leicht ist.
Kann ich nicht mal einfache Fragen haben?

[Forumsgast]

Views: Das ist kein Hexenwerk, probier mal aus:
derzeitige Nutzung
Select <Felder> from <mein fürchterlich langes und ätzendes, komplexes Statement>

Viewdefinition

CREATE View <ViewName> as <Select <Felder> from <mein fürchterlich langes und ätzendes, komplexes Statement mit unglaublicher where clause>>

anschließende Nutzung:
Select <Felder> from <ViewName>

easy

[Forumsgast]

Wenn du das Speichern im JSON-Format in Betracht ziehst, könntest du dir auch mal NoSQL-Datenbanken anschauen.

Grüße.

[Forumsgast]

Wenn du das Speichern im JSON-Format in Betracht ziehst, könntest du dir auch mal NoSQL-Datenbanken anschauen.

Ich schätze mal Alpha schaut sich das eh nicht mehr an, aber JSON ist natürlich super flexibel.
Eine NoSQL DB würde ich aber deswegen nicht gleich nehmen, wahrscheinlich will er ja auch nicht gleich alles umstellen.

JSON und PostgreSQL ist viel naheliegender, man hat beide Welten und kann sie problemlos verknüpfen.

[Forumsgast]

Um wollen gehts nicht. Das ist kein Hobbyvorhaben. Unser Chef ist der Boss, der sagt wo es langzugehen hat. Ich muss dann sehen, dass ich alles ausschöpfen kann, was denkbar ist. Im Grunde klingt das hart, aber es führt auch dazu, sich mehr mit dem System auseinander zu setzen und nicht die Lösung immer im "Suchen anderer Datenbanken" zu suchen. In der produktiven Umgebung ständig alles über den Haufen zu werfen, ist der sichere Weg seine Firma in den Rui zu treiben. Gute Entwicklungen brauchen Zeit. Ich nehme mir diese Zeit erstmal um ein System richtig kennen zu lernen. Privat bin ich experimentierfreudiger, aber da hängen auch nicht Millionen Kundendaten davon ab und die Existenz mehrerer Mitarbeiter.

[Forumsgast]

Du musst ja nicht *alles* über den Haufen werfen. Man. kann diese Technologien durchaus kombinieren, wenn der Nutzen es rechtfertigt. Da wir aber kaum etwas über deinen Anwendungsfall wissen, können wir auch nichts dazu sagen und lediglich mögliche Ansätze & Vorgehensweisen, für das was du geschildert hast, aufzählen.

[Forumsgast]

Wie sieht denn jetzt das Feedback zu den Vorschlägen aus? Konntest du mit denen etwas anfange, geht es in die richtige Richtung, probierst du da was aus?
Ansonsten gibt es auch noch das EAV-Modell um Entitäten willkürlich Attribute zuordnen zu können.

[Forumsgast]

Wieso so kompliziert? Was spricht dagegen, das in einer Tabelle zu haben?

Falls es zwei Tabellen sein müssen, hätte ich eine Materialized View vorgeschlagen. Länderdaten werden sich wohl kaum so oft ändern, dass eine echte View (und somit eine "Echtzeitabfrage") gerechtfertigt ist. Das sind ja mehrheitlich statische Daten.

[Forumsgast]

Wieso so kompliziert?

Welche von den Ideen ist denn kompliziert?

Was spricht dagegen, das in einer Tabelle zu haben?

Bestimmt nicht viel, aber wir stochern hier halt im Dunklen.

[Forumsgast]

Um wollen gehts nicht. ..
nicht die Lösung immer im "Suchen anderer Datenbanken" zu suchen. ..

Deine (fehlende bzw. missmutige) Reaktion sah nicht nach Enthusiasmus aus.

"Alles umkrempeln" ist wirtschaftlich gesehen sicher problematisch, aber Stück für Stück umkrempeln ist sicher nicht verkehrt. Die Datenbank oder sogar die Datenbank Methodik zu wechseln hat niemand verlangt. (Du hast noch nicht mal verraten, welche es derzeit ist). Views sind im Übrigen ein Standard, den man in allen gängigen RDBMS zur Verfügung hat. Die sind einfach da und man kann sie nutzen.

[Forumsgast]

Um wollen gehts nicht. Das ist kein Hobbyvorhaben. Unser Chef ist der Boss, der sagt wo es langzugehen hat. Ich muss dann sehen, dass ich alles ausschöpfen kann, was denkbar ist. Im Grunde klingt das hart, aber es führt auch dazu, sich mehr mit dem System auseinander zu setzen und nicht die Lösung immer im "Suchen anderer Datenbanken" zu suchen. In der produktiven Umgebung ständig alles über den Haufen zu werfen, ist der sichere Weg seine Firma in den Rui zu treiben. Gute Entwicklungen brauchen Zeit. Ich nehme mir diese Zeit erstmal um ein System richtig kennen zu lernen. Privat bin ich experimentierfreudiger, aber da hängen auch nicht Millionen Kundendaten davon ab und die Existenz mehrerer Mitarbeiter.

Im Eingangsposting hast Du gefragt, welche Möglichkeiten es gibt. Dir wurden einige genannt. Nun stellt sich raus, daß eure derzeitige Lösung, die offensichtlich Murks ist, aber so bestehen bleiben soll. Irgendwie paßt das nicht.

[Forumsgast]

Das liegt wohl daran, dass Du den Text Inhaltlich nicht erfassen konntest.
Es ist eben kein Quellcode sondern menschliche Sprache.
Ich glaubte eben, dass es noch Methodisch andere Lösungen gibt, die mir natürlich am Ende auch gefallen sollte. Weniger ging es darum, die Datenbank zu wechseln. Mir tut das leid, dass solch einfaches Fragen manche Menschen total überfordert. Aber diese Frage ins Fortgeschritten-Forum zu schreiben schien mir übertrieben.