Dynamische zuweisung von Spalten

[jobo]

Zitat von freak4fun:

Zitat von Dejan Vu:

Welches RDBMS wenn man fragen darf?

Ich kenne mich nur mit SQLite und mySQL aus und würde hier mySQL nehmen. Es sei denn ist ist absolut ungeeignet.

..
Ich denke im Moment liegt es an der DB-Struktur und an einem guten Konzept, damit ich nicht hinterher alles neu schreiben muss (Das war bisher der Grund fürs scheitern meiner Projekte).

Ja, das ist ja nur der Datenimport. Das wird ca. 10% ausmachen ... Ich werde das dann wohl als ein in sich geschlossenes Modul mit entsprechenden Schnittstellen betrachten müssen. Ich neige dazu alles zu vermischen und mich dann zu verhäddern. Das würde ich diesmal gern vermeiden, deshalb programmier ich diesmal nicht einfach drauf los.

Eine Struktur erhälst Du auf diesem Weg tatsächlich nicht. Die spannende Frage ist doch, was mit den Daten hinterher geschieht.
Wenn Benennung und Inhalt im vollkommen Ermessen des Nutzers liegt, halte ich das für problematisch. Es sei denn, es geht einfach nur um Archivierung im weitesten Sinne oder wahlfreies Datenbrowsen.

Ich habe ähnliche Verfahren entwickelt, wo die Importformate variieren, der finale Import aber in definierte Strukturen geht. Hierbei verwalte ich allerdings die geladenene Datei und den Importvorgang selbst mit. Ein Importvorgang lässt sich später anhand Originaldatei und logischen Transaktionsnummern nachvollziehen oder rückgängig machen.

Falls Deine Import in irgendeiner Form einen Zusammenhang zu den restlichen 90% haben und es da eine bestimmte Semantik in den Importdaten gibt, solltest Du Dir sehr genau überlegen, was Du da baust und verdrahtest. (Ein nachvollziehbarer Importvorgang wäre dann m.E. das Minimum)

Zur DB: Ich habe jüngst wieder erleben dürfen, wie nickelig RDBMS auf Modelländerungen reagieren. Alles unproblematisch, solange meine keine Referenzierung oder Views oder oder verwendet. Sobald man sowas aber definiert, haben die Systeme viel zu meckern, wenn Modelländerungen anstehen- was bei Dir ja systematisch geschieht (im laufenden Betrieb).
Das Niveau, das ich da von Oracle kenne, hab ich woanders noch nicht erlebt. Konkret nicht bei MSSQL und Postgres, mySQL habe ich bis jetzt gemieden, sqLite sehe ich nicht wirklich als RDBMS an, für SingleUser Systeme mag es ok sein.

[Dejan Vu]

Du meinst, wenn man z.B. in MSSQL eine Tabellenstruktur ändert, funktionieren u.U. Views etc. nicht? Das ist richtig, wenn man den Fehler macht, in einer View ein 'Select * ' zu verwenden, was eh ein Anti-pattern ist.

Und wenn man Spaltennamen ändert, geht das natürlich dann nicht. Außer, man würde die Views mit ändern, was irgendwie zwingen wäre. Würde Oracle denn ein Refactoring der Views und SP durchführen, wenn man einen Spaltennamen ändert?

[jobo]

wenn man mit * Antipattern arbeitet, macht oracel das

[-=ZGD=-]

Hi Chris,

ich entnehme mal dem ersten Post, dass die CSV jeweils einen Header hat, in welchem die Spalten stehen?

Die Reihenfolge ist in der Regel fest?
Es gibt zu keinem Zeitpunkt eine wirklich mustergültige Datei, die das Programm intern kennt?

Man könnte hier natürlich das Ganze etwas auf die Spitze treiben und für jede Spalte das Mapping speichern in einer Zuordnungstabelle.
Somit könntest du später einfach schauen: Wurde irgendwann die Spalte "Zuname" schon mal zugeordnet?

CSV-Datei

Code:

Vorname|Zuname|Anrede

Spaltenmapping

Code:

Vorname=firstname
Zuname=surname
Anrede=title

Neue CSV-Datei nach Monaten

Code:

Zuname|Anrede|Rufname

Ergibt dann ein neues Mapping

Code:

Zuname=surname
Anrede=title

Für Rufname gibt es noch kein Mapping, muss zugeordnet werden und ist somit beim nächsten Mal bekannt..
Das ist so die grobe Idee, die ich im Kopf hab.
Hierbei spielt die Struktur der CSV keine Rolle, einzig das Mapping ist entscheidend und du musst nur die Spalten anzeigen/zuordnen lassen, die unklar sind.

Edit: Grad gesehen, dass Dejan-vu so etwas Ähnliches vorgeschlagen hat. Need some coffee

Anmerkung
Ich würde das Hinzufügen/Entfernen der Spalten in der Datenbank nicht umsetzen.

Warum?
Weil das Programm damit dann auch umgehen müsste, sprich sich der Dynamik der Datenbank anpassen. Bei jedem Import könnte man theoretisch Felder entfernen lassen, die für die Funktionsweise der Anwendung relevant sind.

[freak4fun]

Zitat von -=ZGD=-:

CSV-Datei

Code:

Vorname|Zuname|Anrede

Spaltenmapping

Code:

Vorname=firstname
Zuname=surname
Anrede=title

Neue CSV-Datei nach Monaten

Code:

Zuname|Anrede|Rufname

Ergibt dann ein neues Mapping

Code:

Zuname=surname
Anrede=title

Richtig. Interessant wird es wenn ich meine beiden Beispiel CSV-Dateien aus der PDF nehme:

export_partial

Code:

alter = Alter
nam1 = Vorname
summe = Kontostand
name2 = Nachname
ort = Wohnort

Export (Neu)

Code:

alter = Alter
vor_name = Vorname
Anrede = Anrede
nach_name = Nachname
Beruf = Beruf

Neue Spalten mit gleicher Zuweisung. Was wenn "nach_name" nicht zugewiesen wird? Was wenn es später zugewiesen wird?
Wenn Anrede nicht angezeigt werden soll, aber der Benutzer sich entscheidet das erst später anzeigen zu lassen? Es dürfen keine Daten verloren gehen.

Zitat von -=ZGD=-:

Anmerkung
Ich würde das Hinzufügen/Entfernen der Spalten in der Datenbank nicht umsetzen.

Zitat von -=ZGD=-:

Warum?
Weil das Programm damit dann auch umgehen müsste, sprich sich der Dynamik der Datenbank anpassen. Bei jedem Import könnte man theoretisch Felder entfernen lassen, die für die Funktionsweise der Anwendung relevant sind.

Hinzufügen automatisch, Formatabhängig. Löschen ist nicht erlaubt, weder Programm noch Benutzer.

Ich bin nach wie vor offen für Vorschläge:

1. Dynamisch Spaltenerstellung aus CSV
2. Keine Daten löschen
3. Immer alle Daten erfassen
4. Möglichst einfach für den Benutzer

[-=ZGD=-]

Nunja, importieren tust du alles.

In deinen Beispielen ist links die Überschrift aus der CSV und rechts die Spalte in der Datenbank?

Beim Import gibt es kein "später".

Du prüfst vor dem Import ab, ob es für die CSV-Spalte eine Zuordnung zur DB gibt.
Ja: Super, nimm die
Nein: Dann entweder a) vorhanden Spalte entspricht dieser oder b) neue Spalte hinzufügen (evlt. den User fragen, welcher Inhalt dahinter steht [numerisch, Zeichenkette]).

Auf diese Weise bekommst du immer alle Daten mit, allerdings kann es natürlich sein, dass der Benutzer sagt: neue Spalte anlegen, obwohl es für diese Information bereits eine Spalte gibt..

Es wird keinen Weg geben, der zu 100 % sicher und sauber ist...

[freak4fun]

Wer Interesse an der Anzeige hat:

Seite Balsamiq, Import im Anhang.

Zitat von -=ZGD=-:

Nunja, importieren tust du alles.

Du prüfst vor dem Import ab, ob es für die CSV-Spalte eine Zuordnung zur DB gibt.
Ja: Super, nimm die
Nein: Dann entweder a) vorhanden Spalte entspricht dieser oder b) neue Spalte hinzufügen (evlt. den User fragen, welcher Inhalt dahinter steht [numerisch, Zeichenkette]).

Auf diese Weise bekommst du immer alle Daten mit, allerdings kann es natürlich sein, dass der Benutzer sagt: neue Spalte anlegen, obwohl es für diese Information bereits eine Spalte gibt..

Es wird keinen Weg geben, der zu 100 % sicher und sauber ist...

Richtig.