Dynamische zuweisung von Spalten

[freak4fun]

Hallo Leute,

ich habe mehrere CSV-Dateien mit mehreren verschiedenen Spaltenköpfen, die in einer Datenbank gespeichert werden sollen.

Der Anwender meines Programms soll die Spalten der CSV-Dateien verknüpfen können. Zum Beispiel wenn die erste CSV-Daten eine
Spalte "Nachnamen" und die zweite CSV-Datei eine Spalte "Name" hat, das alle Namen als eine Spalte behandelt werden, die dem
Anwender unter einer selbst gewählten Überschrift zum Beispiel "Freunde" angezeigt werden. Wenn eine dritte CSV-Datei keines dieser
Spalten enthält, sollen die anderen Spalten aber dennoch gespeichert werden, so das keine Daten "verloren" gehen.

Mir fehlt der Ansatz, oder eine alternative zu meiner Idee. Über Anregungen würde ich mich sehr freuen.

[Der schöne Günther]

Aber das "Konvertieren" CSV -> Datenbank ist ein einmaliger Vorgang, oder? Wieviele CSV-Dateien hat der Benutzer denn für gewöhnlich? Ich hätte eine Datei nach der anderen eingelesen und den Benutzer dann gefragt, welche "CSV-Spalte" in welche Tabellenspalte kommen soll.

Oder weißt du im Vorhinein nichts über den CSV-Inhalt und wie deine Tabellen am Schluss aussehen ist anfangs völlig unklar? :o

[freak4fun]

Zitat:

Zitat von Der schöne Günther (Beitrag 1271952)

Aber das "Konvertieren" CSV -> Datenbank ist ein einmaliger Vorgang, oder?

Ich denke schon. Es gibt mehrere CSV-Dateien vom gleichen Typ, also mit identischen Spaltenköpfen, die importiert werden.

Zitat:

Zitat von Der schöne Günther (Beitrag 1271952)

Wieviele CSV-Dateien hat der Benutzer denn für gewöhnlich?

Es ist wahrscheinlich 1 Datei pro Woche, kann aber variieren. Dabei wird aber immer eine CSV-Datei eines Typs verwendet.
Das Problem tritt nur auf, wenn sich das Format ändert.

Zitat:

Zitat von Der schöne Günther (Beitrag 1271952)

Ich hätte eine Datei nach der anderen eingelesen und den Benutzer dann gefragt, welche "CSV-Spalte" in welche Tabellenspalte kommen soll.

Bei jeder Datei? Würde es Sinn machen da eine Vorlage draus zu machen?

Zitat:

Zitat von Der schöne Günther (Beitrag 1271952)

Oder weißt du im Vorhinein nichts über den CSV-Inhalt und wie deine Tabellen am Schluss aussehen ist anfangs völlig unklar? :o

Ja, genau das ist der Fall. Ich würde die Spalten auch gern in drei Typen aufteilen: Zeichenkette, Ganzzahl und Dezimalzahl. Aber das ist denke ich erst später dran.

[Der schöne Günther]

Also von heute auf morgen kommen ganz anders strukturierte CSV-Dateien rein und das Programm soll darauf vorbereitet sein.

Gehört dazu dann auch eine so weit gehende "Verknüpfung" dass du bislang eine Spalte "Name" bekamst und die CSVs nun in "Nachname" und "Vorname" aufgesplittet sind und das Programm erlauben soll, "Vorname + Nachname" in die bereits existierende DB-Spalte "Name" zu schreiben?

Entweder fehlt es mir an Fantasie, oder das ganze ist nicht trivial. Es sei denn, man stellt die Ursache der sich ändernden CSV-Struktur ab ;-)

[freak4fun]

Zitat:

Zitat von Der schöne Günther (Beitrag 1271957)

Also von heute auf morgen kommen ganz anders strukturierte CSV-Dateien rein und das Programm soll darauf vorbereitet sein.

Richtig.

Zitat:

Zitat von Der schöne Günther (Beitrag 1271957)

Gehört dazu dann auch eine so weit gehende "Verknüpfung" dass du bislang eine Spalte "Name" bekamst und die CSVs nun in "Nachname" und "Vorname" aufgesplittet sind und das Programm erlauben soll, "Vorname + Nachname" in die bereits existierende DB-Spalte "Name" zu schreiben?

Nein. Eine Spalte ist eine Spalte und kann auch nur mit einer Spalte aus einer anderen CSV-Datei verknüpft werden.

Zitat:

Zitat von Der schöne Günther (Beitrag 1271957)

Entweder fehlt es mir an Fantasie, oder das ganze ist nicht trivial.

Das beruhigt mich.:thumb:

Zitat:

Zitat von Der schöne Günther (Beitrag 1271957)

Es sei denn, man stellt die Ursache der sich ändernden CSV-Struktur ab ;-)

Darauf habe ich leider keinen Einfluss.

[Der schöne Günther]

Was ich nur noch nicht verstanden habe ist, ob es mehr werden. Soll deine Datenbank auf lange Sicht immer mehr Spalten bekommen können?

[freak4fun]

Zitat:

Zitat von Der schöne Günther (Beitrag 1271965)

Was ich nur noch nicht verstanden habe ist, ob es mehr werden. Soll deine Datenbank auf lange Sicht immer mehr Spalten bekommen können?

Im Idealfall nicht, da gibt es immer nur das eine Datei-Format. Das regelmäßig importiert wird.
Ich möchte aber vorbereitet sein (und finde das Thema selbst spannend). Ich weiß nicht mal wie häufig der Fall eintreten kann.

[Jumpy]

Ich hab mich mal eine Zeitlang mit dem Import-Assistenten von Lexware rumgeschlagen. Ähnlich wie beim CSV-Import von Excel hat man da mehrere Schritte:

1. Zu importierende Datei auswählen
2. "CSV-Art" auswählen, d.h. "Feste Breite" vs. "Trennzeichen getrennt"
3. Trennzeichen festlegen
4. Spalten der CSV den Spalten der DB zuordnen
(da die Datentypen der DB "fix" sind, geben sie vor, wie die einkommenden Daten interpretiert werden.
5. Vorschau der ersten 2-3 Datensätze wie die zugeordnet werden
6. Durchführen des Imports
7. Speichern der Einstellungen (Zuordnungen) als Profil

Später können dann Schritte (1 oder) 2 bis 4 (oder 5) durch Auswählen eines Profils übersprungen werden.

Das Programm muss natürlich erkennen, wenn ein Profil nicht mehr passt (andere Spaltennamen in der CSV, oder diese an anderer Stelle) und entsprechend warnen.

[freak4fun]

Danke Jumpy,

das hilft schon mal weiter.

Zitat:

Zitat von Jumpy (Beitrag 1271972)

4. Spalten der CSV den Spalten der DB zuordnen
(da die Datentypen der DB "fix" sind, geben sie vor, wie die einkommenden Daten interpretiert werden.

Dann muss ich mir an der Stelle Gedanken über die DB-Struktur machen. Und wie ich Spalten die in der einen aber nicht in der anderen Datei sind behandle.:pale:

[Jumpy]

Irgendwo musst du das machen oder anderes ausgedrückt irgendeinen Tod musst du sterben. Wenn du nicht irgendeine KI programmieren willst, die alles erkennt egal was da kommt und es automatisch richtig zuordnet, musst du das den User machen lassen.

Vllt. hab ich mich aber auch falsch ausgedrückt. In so einem Assistenten hast du Links eine Art Listbox mit allen Spalten der CSV (Headernamen) und rechts eine Art zweispaltiger Listbox o. Stringlist mit allen Spalten der Datenbank in der linken Spalte. Dann kannst du aus der linken Listbox einen Spaltennamen der CSV rausziehen und auf der rechten Seite der passenden Datenbankspalte zurordnen. Wie man das genau umgesetzt hat weiß ich jetzt nicht.

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

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:

Zitat von Dejan Vu (Beitrag 1272055)

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:

Zitat von Dejan Vu (Beitrag 1272055)

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. :gruebel:

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:

Zitat von Dejan Vu (Beitrag 1272055)

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:

Zitat von Dejan Vu (Beitrag 1272055)

Ist das korrekt so?

Du bist nah dran. ;)

Zitat:

Zitat von Dejan Vu (Beitrag 1272055)

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:

Zitat von Dejan Vu (Beitrag 1272055)

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! :thumb:

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

Zitat von Dejan Vu (Beitrag 1272079)

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:

Zitat von Dejan Vu (Beitrag 1272079)

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:

Zitat von Dejan Vu (Beitrag 1272079)

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. :oops:

Danke für deine Meinung und Hilfe. :thumb:

[Dejan Vu]

Zitat:

Zitat von freak4fun (Beitrag 1272081)

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:

Zitat von freak4fun (Beitrag 1272081)

Zitat:

Zitat von Dejan Vu (Beitrag 1272079)

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. :oops:

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:

Zitat von -=ZGD=- (Beitrag 1272147)

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:

Zitat von -=ZGD=- (Beitrag 1272147)

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

Zitat:

Zitat von -=ZGD=- (Beitrag 1272147)

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:

Zitat von -=ZGD=- (Beitrag 1272181)

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.

[-=ZGD=-]

Ja, genau, im Prinzip kann man das so aufbauen.
Vielleicht würde ich es einfach kürzer machen und wie eine Art Wizard aufbauen.

Du zeigst pro Schritt immer nur eine CSV-Spalte an, die konfiguriert werden muss, sprich

1. zugeordnet oder
2. angelegt.

.

Was an der Sache blöd ist: Inkonsistenz der Daten, wie ich aus deinem Mockup erkenne, aber das wird schon so seine Richtigkeit haben.

[taveuni]

Ich hab jetzt nicht alles durchgelesen - aber der MSSqlServer (auch die kostenlose Express Version) eigene (eigentlich eher das Managementstudio) Import kann das schon. Erzeugt die Felder nach Namen wenn nicht vorhanden, wahlweise können Spaltennamen in Excel auf Spaltennamen in der Tabelle gemappt werden. Daten können angehängt oder vorher alte gelöscht werden usw. Wenn die Tabelle (Excel Sheetname) nicht existiert wird sogar die Tabelle angelegt.

[-=ZGD=-]

Zitat:

Zitat von taveuni (Beitrag 1272215)

Ich hab jetzt nicht alles durchgelesen - aber der MSSqlServer (auch die kostenlose Express Version) eigene (eigentlich eher das Managementstudio) Import kann das schon. Erzeugt die Felder nach Namen wenn nicht vorhanden, wahlweise können Spaltennamen in Excel auf Spaltennamen in der Tabelle gemappt werden. Daten können angehängt oder vorher alte gelöscht werden usw. Wenn die Tabelle (Excel Sheetname) nicht existiert wird sogar die Tabelle angelegt.

Joa, wobei Chris meinte: SQLite oder MySQL ;-)

[Dejan Vu]

Ja. Nur kann man beim Import-Wizard Quelle *und* Ziel frei wählen. D.h. wäre es eine Anforderung vom Vorgesetzten, wäre man ziemlich schnell fertig. Hier soll das aber ein Hobbyprojekt -idealerweise mit Lerneffekt- werden, also werden wir das hier mal hübsch alles selbst spezifizifizieren.

[freak4fun]

@-=ZGD=-: Der Wizard sieht gut aus. Diese Schritt für Schritt Idee gefällt mir.

Zitat:

Zitat von taveuni (Beitrag 1272215)

... der MSSqlServer ...

Muss man dafür was bezahlen, wenn man das zu einem Projekt beifügt?

Zitat:

Zitat von -=ZGD=- (Beitrag 1272217)

Joa, wobei Chris meinte: SQLite oder MySQL ;-)

:shock: Das ist nicht in Stein gemeißelt. SQL ist SQL.

Zitat:

Zitat von Dejan Vu (Beitrag 1272220)

Hier soll das aber ein Hobbyprojekt -idealerweise mit Lerneffekt- werden, also werden wir das hier mal hübsch alles selbst spezifizifizieren.

MSSQL nutzen hat auch einen Lerneffekt. :stupid: Ich schau mir das mal an, wie das Funktioniert.

[Dejan Vu]

MSSQL Express kosten zwar nichts, aber Ich glaube nicht, das Du das in einem gewerblich vertrieben Projekt als kostenpflichtigen Punkt mit verkaufen kannst. Aber die üblichen Tricks greifen da immer, also z.B. selber installieren lassen, oder im Rahmen der Gesamtinstallation mit installieren und darauf hinweisen, das dieser Punkt vom MS-SSMS Express erschlagen wird. Genaueres wirst Du in den Lizenzbestimmungen von Microsoft lesen.

In jedem Fall hast Du da alles, was Du brauchst, sogar Skripting, um dein Mapping noch besser zu machen.

[freak4fun]

Ist das so verständlich?
Die Auswahl der Spalte würde dann für jede der 8 Spalten angezeigt werden.

[Sir Rufo]

Verständlich ja aber nicht user-friedly :)

Besser wäre es die Spalten mit Zuordnung in einer Liste zu haben und diese Ansicht für das aktuell gewählte Element. Dann behält man die Übersicht ohne Memory spielen zu müssen :)

Ich würde statt CSV und Programm immer von Quelle und Ziel sprechen. Demnächst willst du das auch mit einer beliebigen Quelle machen (geht eigentlich problemlos) aber die Namen sind dann eher verwirrend.

[Jumpy]

Hallo,

ich hatte ja schonmal den Assitenten vom Lexware-Import erwähnt. Nicht das ich den jetzt für das gelbe vom Ei halte (hab mich schon manches mal damit rumgeärgert) aber die Darstellung und vorgehensweise finde ich gut und (z.B. vom Importassistenten von Excel) teilweise vertraut.

Daher hier mal ein Link wo man sich das ansehen kann.
Für dich dürfte Schritt 5 der wichtige sein.

[freak4fun]

Danke euch beiden, passe bzw. schaue ich an.

[-=ZGD=-]

Die Frage ist, wie firm sind die Anwender.
Der Import mag für DAUs doch recht schwierig sein. So eine Art Assistent führt übersichtlicher und fehlerunanfälliger zum Ziel - meine Meinung.

[freak4fun]

Nächster Versuch. :duck:

[Sir Rufo]

Ja das ist doch schon mal ein gute Richtung :)