Datenbank Design

[Alpha]

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.

[akretschmer]

Das liegt wohl daran, dass Du den Text Inhaltlich nicht erfassen konntest.

score adjusted.

[VPh]

Immer noch keine Reaktion auf die genannten Lösungsansätze. Aber groß die Klappe aufreißen, bravo.

[Alpha]

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.

[akretschmer]

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.

[Perry Staltic]

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.

[VPh]

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.

[ChristianK]

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.

[VPh]

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.

[lottikarotti]

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.

[Alpha]

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.

[Perry Staltic]

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.

[php1704]

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

Grüße.

[Perry Staltic]

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

[Alpha]

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