Datenbankarchitektur

Ich überwache derzeit die Implementierung eines Nationalen Informationssystems in Burkina Faso. Ich habe durchgesetzt, dass das Konsortium die Sache auf Postgres aufbaut und sie scheinen auch Erfahrung damit zu haben.
Nun schlagen sie vor, alle Daten im Text-Format zu speichern, da dies angeblich bei der gewählten Systemarchitektur Vorteile bringe. Sie Begründen dies damit, dass alle Parameter in einer Tabelle gespeichert werden sollen: Numerische Parameter ebenso wie String-basierte.

Mir ist diese Vorgehensweise neu und ich kann mich damit nicht anfreunden. Selbst wenn über Stored Procedures die Daten dann im gewünschten Format vorgehalten werden, frage ich mich ob

  • nicht das Datenvolumen dadurch stark aufgebläht wird
  • nicht die Performanz des Systems darunter leidet
  • Dritten, die über ODBC oder andere Treiber auf die Datenbank zugreifen möchten, dann nicht große Nachteile entstehen, da die SQLs dann die Datenformate erst umsetzen müssen

Wer hat genügend Erfahrung, um mir da Klarheit zu verschaffen?


Vielen Dank schon mal!

meld

Eine schlichte Frage, die du stellen kannst: wollen sie die Daten in einer Datenbank oder in einer Textdatei speichern?

Wenn sie eine Datenbank wollen, sollen sie auch die Features einer Datenbank nutzen. Wenn sie eine Textdatei wollen, ist eine SQL-Datenbank nur ein Haufen Overhead.

Dein Punkt 1 ist nicht schlimm. Wenn Daten redundant vorhanden sind, kann man duech Normalisierung Platz sparen, weil doppelte Daten nur einmalig vorgehalten werden. Sind die Daten allerdings schon passend vorhanden, kann das Aufteilen in Datenbankstrukturen sogar etwas mehr Platz kosten. Schliesslich muss die Datenbank die Daten auch irgendwie verwalten.

Punkt 2 und 3 sind allerdings richtig. Wozu eine SQL-Datenbank nehmen, wenn man die nicht nutzt?

Kannst du ein paar mehr Details liefern, z. B. Struktur der Daten, was später damit passieren soll ect?

schlechte Idee.

Sie Begründen dies damit, dass alle Parameter in einer Tabelle gespeichert werden sollen: Numerische Parameter ebenso wie String-basierte.

Auch schlecht. Erstens sollte man seine Daten normalisieren und zweitens gibt es Datentypen für alles mögliche.

Mir ist diese Vorgehensweise neu und ich kann mich damit nicht anfreunden. Selbst wenn über Stored Procedures die Daten dann im gewünschten Format vorgehalten werden, frage ich mich ob

  • nicht das Datenvolumen dadurch stark aufgebläht wird
  • nicht die Performanz des Systems darunter leidet
  • Dritten, die über ODBC oder andere Treiber auf die Datenbank zugreifen möchten, dann nicht große Nachteile entstehen, da die SQLs dann die Datenformate erst umsetzen müssen

Wer hat genügend Erfahrung, um mir da Klarheit zu verschaffen?


Vielen Dank schon mal!

Deine Zweifel sind berechtigt.

Andreas

Vielen Dank schon mal für die Kommentare,

Ich fühle mich nun bestärkt, jener implementierenden Firma die Vorgaben entsprechend zu machen. Zur Frage, was in diese Datenbank hinein soll: Es geht um ein nationales Informationssystem im Wasserbereich. Es wurde ein Jahr lang zwischen allen Partnern hin- und herdiskutiert, was alles berücksichtigt werden soll und das Ergebnis ist: Ungefähr alles soll berücksichtigt werden. Eine katastrophal umfangreiche Tabellenzahl und eigentlich ist jetzt schon klar, daß weder Mittel noch Kompetenz verfügbar ist, diese anschließend entsprechend zu füllen, geschweide denn zu pflegen.

Da bei einem solchen Informationssystem (mit Mapserver, Webportal und allem PiPaPo) aber auch verschiedene existierende Modelle über ODBC, OleDB etc) auf die Daten zugreifen können sollen, ist jene vorgeschlagene TEXT-Struktur nicht applikabel.

Vielen Dank nochmals!

Hallo!

Wie schön, ein Kollege :slight_smile:
Für das was ihr vorhabt, ist PostgreSQL/PostGIS eine excellente Wahl. Wir arbeiten überwiegend im Wasserbau und Hochwasser-/Georisikenbereich und setzen das seit einiger Zeit sehr erfolgreich in fast allen Projektphasen ein. Falls du dazu Fragen hast, kannst du dich gern mit mir in Verbindung setzen.

Gruß Uwe