Dynamische zuweisung von Spalten

[jobo]

Also wie man da ohne KI auskommt, ist mir schleierhaft.

Solange alle Daten/Spalten, die durch irgendein CSV eintrudeln in der DB vorhanden sind, kann man alles zuordnen. Schon hier ist klar. In der DB wird dann die ein oder andere Spalte mal leer bleiben. Es ist offenbar ja nicht so vorgesehen, dass die Dateien sich nur durch andere Header -mit gleichem Inhalt- unterscheiden.

Spätestens, wenn dann ein Spalteninhalt gar nicht zuzuordnen ist, bleibt er entweder auf der Strecke oder man ermöglicht es, wirklich dynamisch, in der DB eine neue Spalte anzulegen.

Selbst ohne das tolle Feature, Spalten in der DB anlegen zu können, wird es in der Praxis so sein, dass der Anwender ab und zu 2 Augen zudrückt und die CSV Inhalte irgendwelchen DB Spalten zuordnet, die eigentlich nicht passen.
Erfahrungsgemäß sind schon CSV Dateien oft so gestaltet, dass es mindestens eine Vielzweckspalte gibt.

Eine DB, deren Inhalte nicht zu den Feldern passen kann man sich aber auch gleich sparen.

[freak4fun]

So in etwa würde ich mir das vorstellen.

[Dejan Vu]

Darf ich noch einmal meckern? Das ist kein 'Wizard' oder 'Assistent', sondern ein ziemlich überladenes Formular. Oder ist das gar nicht als Formular gedacht, sondern als kompakte Darstellung deiner Idee?

Mal sehen, vielleicht verstehe ich es ja:
1. Eine CSV-Datei besteht aus Zeilen und Spalten (C1...Cm)
2. Du hast eine Tabelle in einer Datenbank mit allen Spalten (S1...Sn).
3. Für jede Datei möchtest Du ein Mapping, sodaß Ci => Sj abgebildet wird.
4. Dein Programm weiß einfach so, welchem Feld in der Benutzeransicht die Tabellenspalte 'Nachname' zugewiesen ist.

Aufgaben:
I. Die Menge von Spalten, also das Layout der DB-Tabelle (S1...Sn) soll veränderbar sein.
II. Beim Import einer CSV-Datei lädst Du ein vordefiniertes Mapping und importierst die Datei.

Ist das korrekt so?

Die Handhabung ist mehr als holperig, denn um eine Übersicht über das Mapping zu bekommen, musst Du auf die einzelne CSV-Spalte klicken, um dann im Dropdown das aktuell eingestellte Mapping zu sehen. Zeige das lieber als Grid mit drei Spalten an (Nr, CSV-Spalte, DB-Spalte). Entweder du blendest dann in der dritten Spalte deine Dropdownliste ein (dann kann man das Mapping direkt im Grid machen), oder Du machst das -wie bisher- über ein separates Dropdown.

Für die Pflege der Zieltabelle würde ich einfaches DDL nehmen, also:
Spalte hinzufügen: "ALTER TABLE ZielTabelle ADD NeueSpalte <Typ>"
Spalte wegnehmen: "ALTER TABLE ZielTabelle DROP AlteSpalte"
usw.
Das Mapping erschlägst Du mit einer Stringliste 'CSV-Spalte=DB-Spalte'. Der Dateiname der Stringliste ist der Name der Vorlage.

Die DB-Tabellendefinition und die Datentypen liest Du per Metainformation aus der Datenbank.

[freak4fun]

Zitat von Dejan Vu:

Darf ich noch einmal meckern? Das ist kein 'Wizard' oder 'Assistent', sondern ein ziemlich überladenes Formular. Oder ist das gar nicht als Formular gedacht, sondern als kompakte Darstellung deiner Idee?

Eine kompakte Darstellung.

"export_partial" ist die erste CSV-Datei mit Format1
"Export (Neu)" ist die zweite CSV-Datei mit Format2
Die beiden Dateiimport-Felder stellen den aufeinander folgenden Import der Dateien dar.
Erstellen/ Bearbeiten stellt die Möglichkeit zur Benennung der Spalten dar.
Die Benutzeranzeige stellt das Menu zur Konfiguration der Datensatzansicht dar.
Die Datennsicht ist die Benutzeransicht der Datenbank.

Zitat von Dejan Vu:

Mal sehen, vielleicht verstehe ich es ja:
1. Eine CSV-Datei besteht aus Zeilen und Spalten (C1...Cm)
2. Du hast eine Tabelle in einer Datenbank mit allen Spalten (S1...Sn).
3. Für jede Datei möchtest Du ein Mapping, sodaß Ci => Sj abgebildet wird.
4. Dein Programm weiß einfach so, welchem Feld in der Benutzeransicht die Tabellenspalte 'Nachname' zugewiesen ist.

1. ja
2. ja- am Anfang 0 spalten, dann die aus er den CSV-Dateien
3. ja - Spalten aus der neuen CSV werden auf bestehende Spalten gemapt. Wenn das nicht passiert wird die spalte erstellt.
4. Das soll eigentlich der Benutzer machen. Wenn das CSV-Format bekannt ist (Vorlage) muss der Benutzer nichts machen.
(Problem hierbei: Der Benutzer weist aus Desinteresse oder Unwissenheit irgendwas zu)

Zitat von Dejan Vu:

Aufgaben:
I. Die Menge von Spalten, also das Layout der DB-Tabelle (S1...Sn) soll veränderbar sein.
II. Beim Import einer CSV-Datei lädst Du ein vordefiniertes Mapping und importierst die Datei.

I. ja
II. Bekanntes Format -> einfacher Import, unbekanntes Format -> Mapping + Spaltenerstellung

Zitat von Dejan Vu:

Ist das korrekt so?

Du bist nah dran.

Zitat von Dejan Vu:

Die Handhabung ist mehr als holperig, denn um eine Übersicht über das Mapping zu bekommen, musst Du auf die einzelne CSV-Spalte klicken, um dann im Dropdown das aktuell eingestellte Mapping zu sehen. Zeige das lieber als Grid mit drei Spalten an (Nr, CSV-Spalte, DB-Spalte). Entweder du blendest dann in der dritten Spalte deine Dropdownliste ein (dann kann man das Mapping direkt im Grid machen), oder Du machst das -wie bisher- über ein separates Dropdown.

Im <Idealfall bekommt der Benutzer die ganze Konfiguration nur einmal beim ersten Import zu Gesicht.
Alle Spalten werden für die DB neu erstellt, der Benutzer definiert die Anzeigenamen und die Vorlage wird gespeichert. Beim zweiten Import (gleiches Format). Werden die neuen Daten ohne Änderungen hinzugefügt.

Zitat von Dejan Vu:

Für die Pflege der Zieltabelle würde ich einfaches DDL nehmen, also:
Spalte hinzufügen: "ALTER TABLE ZielTabelle ADD NeueSpalte <Typ>"
Spalte wegnehmen: "ALTER TABLE ZielTabelle DROP AlteSpalte"
usw.
Das Mapping erschlägst Du mit einer Stringliste 'CSV-Spalte=DB-Spalte'. Der Dateiname der Stringliste ist der Name der Vorlage.
Die DB-Tabellendefinition und die Datentypen liest Du per Metainformation aus der Datenbank.

Genau.

Ich überlege ob das auch einfacher geht. Ich habe da freie Hand. Die einzige Vorgabe sind die verschiedenen CSV-Formate.

PS: Danke für die Antworten!

[Dejan Vu]

Welches RDBMS wenn man fragen darf?

Aber ansonsten ist das ja kein großes Ding. Hapert es an der Umsetzung oder eher an der GUI? Oder nur, wie man das am einfachsten löst?

Ich würde mir da keinen großen Kopf drum machen. Das ist ein relativ einfaches Programm. Kümmer dich doch erst einmal um die Klassen und schreib ein Konsolenprogramm, was die Klassen testet.

[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.

Zitat von Dejan Vu:

Aber ansonsten ist das ja kein großes Ding. Hapert es an der Umsetzung oder eher an der GUI? Oder nur, wie man das am einfachsten löst?

Im Moment schreibe ich noch das Lastenheft. Ich wollte halt mal sehen ob ich meine Idee überhaupt umsetzen kann. Mit der GUI habe ich kein Problem. 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).

Zitat von Dejan Vu:

Ich würde mir da keinen großen Kopf drum machen. Das ist ein relativ einfaches Programm. Kümmer dich doch erst einmal um die Klassen und schreib ein Konsolenprogramm, was die Klassen testet.

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.

Danke für deine Meinung und Hilfe.

[Dejan Vu]

Zitat von freak4fun:

Ich denke im Moment liegt es an der DB-Struktur und an einem guten Konzept,

Wenn Du die Pflege der Import-Tabelle so machst, wie ich das vorgeschlagen habe, hast Du keine "DB-Struktur" sondern nur eine einzige Tabelle.
Woran Du vielleicht denkst, ist ein EAV-Model. Mach es nicht. Lohnt nicht, zu langsam, zu aufwändig. Dein mySQL hat alles, was Du brauchst (SQLite auch).

Wenn dieser Import nur 10% ausmacht, wie sehen denn dann die anderen 90% aus?

[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