Server für nicht normalisierte DB

Guten Tag,

wie geht man prinzipiell vor, wenn der Kunde eine nicht normalisierte Datenbank nutzt?

In meinem Fall steht so ziemlich alles in einer Tabelle. Einige Sachen stehen auch in einer zweiten oder dritten Tabelle, aber ohne Sinn und ohne Fremdschlüssel. Also das Fremdschlüsselattribut existiert zwar, aber ist DB intern nicht als Fremdschlüssel deklariert.
Dadurch gibt es dann auch keine Konsistenzüberprüfung seitens der DB.
Aber die Konsistenz ist bei dieser DB eh verloren.

Geht man da mit JDBC ran und braut sich eigene Querys?

Der Server soll in Java geschrieben werden und die DB ist eine MySQL.

Ich verstehe ehrlich gesagt deine Frage nicht so ganz.

Du hast ein DBMS mit einer Datenbank, die aus mehreren Tabellen besteht, in denen sich Daten befinden? Und jetzt möchtest du ein Stück Software entwickeln, dass diese Daten in irgendeiner Art und Weise nutzt (Und das Stück Software bezeichnest du als "Server")?

Was hat jetzt JDBC mit eigenen Abfragen zu tun? JDBC ist doch nur ein Treiber zum Ansprechen der Datenbank, oder? Den brauchst du doch sowieso, wenn du mit Java drangehen willst. Und Abfragen musst du dir doch ebenfalls definitiv selber bauen, es sei denn, es gibt Stored Procedures und/oder Views, die dir alles aufbereitet überlassen.

Das Problem mit den nicht unbedingt sinnvoll sturkturierten Daten ist da wieder ein anderes. Wenn möglich, sollte gleich die Chance genutzt werden, um das Gebilde neu zu strukturieren. Falls es nicht zu viele Daten sind, könnte man den Kram auch komplett auslesen und von deiner Anwendung im Speicher verwalten lassen (für die Dauer der Laufzeit... Änderungen müssen natürlich auch wieder weggeschrieben werden).

Falls Umstrukturierung und "im Speicher verwalten" nicht machbar ist, dann bleibt wohl nur der unschöne Weg, mit der vorhandenen Struktur zu leben und das Beste draus zu machen.

Tersus schrieb:

Also das Fremdschlüsselattribut existiert zwar, aber ist DB intern nicht als Fremdschlüssel deklariert.
Dadurch gibt es dann auch keine Konsistenzüberprüfung seitens der DB.

Zum Vergrößern anklicken....

...was vollkommen normal ist, wenn man mit MyISAM arbeitet. Warum MyISAM? Nun, einerseits ist es stellenweise performanter als InnoDB, andererseits unterstützen ältere MySQL-Versionen keine Fulltext-Indizes auf InnoDB... also bleibts bei MyISAM, was wiederum Foreign Key Constraints auf Datenbank-Level ausschließt.

KillerCow schrieb:

Du hast ein DBMS mit einer Datenbank, die aus mehreren Tabellen besteht, in denen sich Daten befinden? Und jetzt möchtest du ein Stück Software entwickeln, dass diese Daten in irgendeiner Art und Weise nutzt (Und das Stück Software bezeichnest du als "Server")?

Zum Vergrößern anklicken....

Genau, ich möchte über das Stück Software Daten aus der DB auslesen und diese über das HTTP Protokoll bereit stellen. Solch eine Datenbankanwendung nennt man doch Server oder wie sonst?

KillerCow schrieb:

Und Abfragen musst du dir doch ebenfalls definitiv selber bauen, es sei denn, es gibt Stored Procedures und/oder Views, die dir alles aufbereitet überlassen.

Zum Vergrößern anklicken....

Nein, gibt es nicht. Ich muss mir die Abfragen selber bauen. Ich hatte mir irgendein Framework erhofft, dass die Sache erleichtert. Bzw. wollte ich nicht ohne Nachfrage loslegen.

KillerCow schrieb:

Das Problem mit den nicht unbedingt sinnvoll sturkturierten Daten ist da wieder ein anderes. Wenn möglich, sollte gleich die Chance genutzt werden, um das Gebilde neu zu strukturieren. Falls es nicht zu viele Daten sind, könnte man den Kram auch komplett auslesen und von deiner Anwendung im Speicher verwalten lassen (für die Dauer der Laufzeit... Änderungen müssen natürlich auch wieder weggeschrieben werden).

Zum Vergrößern anklicken....

Leider ist dies nicht möglich. Es sind schon recht gewaltige Datensätze.

KillerCow schrieb:

Falls Umstrukturierung und "im Speicher verwalten" nicht machbar ist, dann bleibt wohl nur der unschöne Weg, mit der vorhandenen Struktur zu leben und das Beste draus zu machen.

Zum Vergrößern anklicken....

Genau.

Daaron schrieb:

...was vollkommen normal ist, wenn man mit MyISAM arbeitet. Warum MyISAM? Nun, einerseits ist es stellenweise performanter als InnoDB, andererseits unterstützen ältere MySQL-Versionen keine Fulltext-Indizes auf InnoDB... also bleibts bei MyISAM, was wiederum Foreign Key Constraints auf Datenbank-Level ausschließt.

Zum Vergrößern anklicken....

Woran erkenne ich, dass hier MyISAM verwendet wird? Die Tabellen dieser DB schauen z.B. so aus:

Objekt(O_ID, name1, name2, name3, farbe1, farbe2, farbe3, ...)
Farbe1(F1_ID, name)
Farbe2(F2_ID, name)
Farbe3(F3_ID, name)

Eine Tabelle Farbe 1 hat dann solche Einträge:
{0, rot}; {3, grün}, {5, -}, {10, blau}, ...

Und auf meine Frage, was denn passiert, wenn wir vllt. in Zukunft noch eine 4. Farbe benötigen, kam die Antwort, dass wir dann einfach noch eine Spalte dranhängen.
Dass man das so macht, habe ich nicht gelernt. Entschuldigung.

Tersus schrieb:

Genau, ich möchte über das Stück Software Daten aus der DB auslesen und diese über das HTTP Protokoll bereit stellen. Solch eine Datenbankanwendung nennt man doch Server oder wie sonst?

Zum Vergrößern anklicken....

Nö, nicht zwingend.
WENN diese Anwendung selbst die HTTP(S)-Anforderungen abhandelt, dann isses durchaus ein Server. Häufiger ist aber der Aufbau, dass ein Webserver (vor allem Apache) davor sitzt, der nur gewisse Requests zur Verarbeitung weiter leitet, andere aber selbst erledigt.

Nein, gibt es nicht. Ich muss mir die Abfragen selber bauen. Ich hatte mir irgendein Framework erhofft, dass die Sache erleichtert. Bzw. wollte ich nicht ohne Nachfrage loslegen.

Zum Vergrößern anklicken....

Ab und zu hat man mal Glück und die Daten lassen sich durch einen ORM schicken. In der Regel musst du deine Abfragen aber wirklich selbst aufbauen. Ist im Zweifel eh performanter als irgend welche Query Builder.

Leider ist dies nicht möglich. Es sind schon recht gewaltige Datensätze.

Zum Vergrößern anklicken....

Was hindert dich daran, die Daten automatisiert in eine bessere Struktur zu bringen?

Woran erkenne ich, dass hier MyISAM verwendet wird? Die Tabellen dieser DB schauen z.B. so aus:

Zum Vergrößern anklicken....

Mit einem SHOW CREATE TABLE - Query.
https://dev.mysql.com/doc/refman/5.0/en/show-create-table.html

Und auf meine Frage, was denn passiert, wenn wir vllt. in Zukunft noch eine 4. Farbe benötigen, kam die Antwort, dass wir dann einfach noch eine Spalte dranhängen.
Dass man das so macht, habe ich nicht gelernt. Entschuldigung.

Zum Vergrößern anklicken....

Doch, das funktioniert wunderbar. Kann man durchaus so machen. Man kann natürlich auch mit ner Kreuztabelle arbeiten. Manchmal lohnt es sich sogar, einfach serialisierte Daten in einen BLOB-Feld zu werfen...

Der Vorteil an "ach, häng ne Spalte dran": Es ist übersichtlich und man macht ORM und Query Buildern das Leben leichter. Außerdem hat man allgemein keine/weniger nervige Joins
Der Nachteil: Eine Änderung an der Farbe invalidiert den Query Cache für das gesamte Objekt, beinahe unabhängig davon, wonach ursprünglich gesucht wurde.

normalisiere die tabellen doch einfach..

OK, danke erstmal.
Die DB darf (und will) ich nicht anfassen.
Die Tabelle hat übrigens min. 50 Spalten.

Dann wirst du die DB irgendwann doch anfassen müssen, denn ewig lässt sich das Spalten-Spiel nicht treiben.
https://dev.mysql.com/doc/refman/5.0/en/column-count-limit.html

Tersus schrieb:

OK, danke erstmal.
Die DB darf (und will) ich nicht anfassen.
Die Tabelle hat übrigens min. 50 Spalten.

Zum Vergrößern anklicken....

dann ist das was du machst.. ein ständiger workaround.. das sollte hoffentlich nicht das ziel sein

Dass ich die DB nicht anfassen darf, ist doch nicht meine Entscheidung. ;-)

Nein, aber du kannst den Verantwortlichen auf die Füße treten und ihnen erklären, wieso dieses Vorgehen früher oder später (wohl eher: früher) zum Kollaps führen wird. Berechne doch mal aus Spaß, wie viele Byte deine Spalten aktuell schon breit sind.

Angenommen, auch nur die Hälfte deiner 50 Spalten wären 255er Varchars, dann wäre schon gut 1/3 des Gesamtplatzes dafür weg.