Tool um Excel Daten in Db einzufügen

[theoneand]

Hallo,

suche gerade eine Idee für mein Abschlussprojekt in meiner Ausbildung zum Anwendungsentwickler.
Der zeitliche Rahmen sollte 70 Stunden nicht überschreiben (inklusive Dokumentation, Lastenheft, Pflichtenheft usw.)

Jetzt zu meiner Frage, was haltet ihr von einem Tool welches Excel Daten in eine SQL Datenbank einlesen kann.
Aber nicht nur simpel einlesen, sprich 1 zu 1 übernehmen, es sollen verschiedene Möglichkeiten bestehen.

Ich hatte daran gedacht im Programm zwei Grids zu setzten, das eine simuliert die DB und das andere die Excel Datei.
User hat die Möglichkeit eine Excel Datei zu laden, als Vorschau werden dann im unteren Grid 5 Zeilen der Excel Datei angezeigt.
Dann hat er die Möglichkeit sich mit der gewünschten DB zu verbinden.
In einer Comobobox werden dann sämtliche Tabellen der DB aufgelistet.
Wird eine Tabelle ausgewählt, erscheint eine zweite Comobox, welche alle Spalten der Tabelle auflistet.
Wenn der Anwender nun eine Spalte auswählt wird der Spaltennamen in das obere Db-Grid eingetragen, so kann der user die Spalten festlegen in welche die Excel-Datei eingelesen
werden soll. (Natürlich soll auch möglich sein, in mehrere SQL Tabellen einzulesen)
Dann wird per Drag and Drop vom Excel-Grid die Spalte dem DB-Grid zugeordnet und farbig markiert.
Außerdem sollen auch Modifikationen der Spalten möglich sein(also veränderung der Excel-Daten):
1. Spalten Verbinden: Bspw. aus Strasse und Hausnummer ein Feld in der Db machen
2. Rechnungen: Bspw. Rabatte von Preisen ausrechnen
3. Kürzel voranstellen oder anhängen: Bspw. Bei Arikelnummer einen Zusatz B-xxxxx


gibt es Sowas in der Art schon?? Hab jetzt nichts vergleichbares gefunden....
Vielleicht könntet ihr mir ein kleines Feedback von meiner Idee geben, was ihr davon haltet, oder evtl. Verbesserungen, Anregungen

Grüße

[Mschmidt]

Hi, sofern du von einer MS-SQL Datenbank ausgehst, gibt's das schon - MS liefert das mit.

Tipps zur Umsetzung:
- achte auf leere Felder im Excel
- achte auf Formeln im Excel
- achte auf Datentypen (Zeichen, Zahlen, Gleitkomma)
- achte auf Contraints/Indizes/Primaries auf der Datenbanktabelle
- achte auf die verschiedenen Excel-Formate (XLS vs. XLSX)

:-) Mathias

[Dejan Vu]

So ein Tool bringt nicht viel, denn die meisten RDBMS bringen ihre eigenes Werkzeug mit, um EXCEL-Dateien einzulesen. Des Weiteren gibt es wesentlich mehr Szenarion, die Daten einzulesen, als die Du angegeben hast. Du willst eigentlich nur eine Tabelle aus EXCEL auf eine Tabelle in der DB Mappen, also
(EXCEL-Spalte --> Feldname). Das ist banal.

Speziell der Passus 'Natürlich soll auch möglich sein, in mehrere SQL Tabellen einzulesen' bedarf einen näheren Erläuterung. Wie soll das gehen? Pro Sheet eine Tabelle oder wie?

Es ist 1000x einfacher, die EXCEL-Datei 'irgendwie' in die DB zu saugen und von da aus die Daten zu konvertieren, aggregieren und zu verteilen. Da es sich im Anwendungsfall häufig um ein und die selbe EXCEL-Struktur handelt, schreibt man sich ein Skript, welches die Daten dann verteilt.

Edit: Ich lese gerade

Zitat:

suche gerade eine Idee für mein Abschlussprojekt in meiner Ausbildung zum Anwendungsentwickler.

Das ist natürlich etwas anderes.

Wie gesagt, in der Praxis vielleicht nur bedingt zu gebrauchen, aber als Abschlussprojekt sehr gut.

Ich denke, mit 70 Stunden bist Du knapp dabei. Nimm Dir nicht zu viel vor. Lieber beschränkter Funktionsumfang (EXCEL-Datei, DB, Tabelle aussuchen, dann das mapping) aber gut dokumentiert, als zu viel, halb fertig, buggy und Schrott-Doku.

Die Basisfunktionalität ist schon ausreichend vom Zeitumfang her. Schließlich willst Du ja auch eine schöne Softwarearchitektur, und die fällt nicht vom Himmel.

Los!

[arnof]

Exceltabellen kannst Du öffnen wie eine normale Datenbank (TDataSet). Dann kannst Du alles auslesen und in die andere Datenbank übertragen:

Das geht via ADO

TADOConnection, dort den Connectionsstring rein:

http://www.connectionstrings.com/excel/

dann ist jede Karteikarte der Execldatei als eigenständige Tabelle da

[mkinzler]

Zitat:

Speziell der Passus 'Natürlich soll auch möglich sein, in mehrere SQL Tabellen einzulesen' bedarf einen näheren Erläuterung. Wie soll das gehen? Pro Sheet eine Tabelle oder wie?

Dafür bräuchte man dann kein extra Tool. Ich vermute mal, die Daten müssen auf verscheidene Tabellen verteilt werden.

Zitat:

Es ist 1000x einfacher, die EXCEL-Datei 'irgendwie' in die DB zu saugen und von da aus die Daten zu konvertieren, aggregieren und zu verteilen. Da es sich im Anwendungsfall häufig um ein und die selbe EXCEL-Struktur handelt, schreibt man sich ein Skript, welches die Daten dann verteilt.

Kommt auf den Fall an, natürlich kann man das erst temporär in eine (Temp-)Tabelle schaufeln und dann umbuchen. Wenn sich das Format in der einzulesenden Exceltabelle ändert, bzw. es verschiedene Formate gibt, scheint es mir sinnvoller die Daten gleich in die "richtige" Tabelle einzulesen.

[theoneand]

danke erst mal für die teilweise hilfreichen Antworten.

Vielleicht ist es nicht deutlich hervogetreten aus der Fragestellung:

Das Ganze ist als Abschlussprojekt für meine Ausbildung gedacht.


Mir ist bis jetzt bewusst, dass es nur möglich ist, die Daten von Excel 1 zu 1 in die DB zu übertragen,
um sie dort dann anzupassen, bzw zu verändern.

Mein tool soll ja diese Aufgaben schon übernehmen.

[theoneand]

ich bin auch gerne offen für andere Vorschläge, muss auch nicht zwinged was mit Datenbanken sein,
falls jemandem etwas einfaällt.

[Dejan Vu]

Zitat:

Zitat von mkinzler (Beitrag 1268639)

Dafür bräuchte man dann kein extra Tool. Ich vermute mal, die Daten müssen auf verscheidene Tabellen verteilt werden.

Da Du das vermutest, vermutest Du auch nur, das man dafür kein extra Tool benötigt. Ich wollte nachfragen, bevor ich nicht vermute, sondern weiß.

Zitat:

Kommt auf den Fall an,

Sehr selten passt das alles 1:1 (meine Erfahrung). Und daher ist der 'normale' (weil schnellste) Fall imho der, erst einmal alles mit quasi Default-Einstellungen in die DB zu saugen um anschließend (weil viel schneller) mit entsprechenden SQL-Befehlen ein Skript zu bauen.

Es ist unterm Strich wirklich schneller, das so zu machen, als (ich habe die SSAS vom SQL-Server vor Augen) sich durch irgendwelche Wizards zu klicken oder tolle Einstellungen per Combo vorzunehmen.

in TSQL wäre das

Code:

select * into #tempExecl from Openrowset(.....)
merge from #tempExcel
  into myDestination
...

Zitat:

Zitat von theoneand (Beitrag 1268649)

Mein tool soll ja diese Aufgaben schon übernehmen.

Also ich würde an deiner Stelle die Aufgabe und den Funktionsumfang klar definieren und zum Prof/Ausbildungsleiter gehen und ihm das vorstellen. Wenn Du das gut hinbekommst, wäre das -auch vom Umfang- ein Beleg für dein Können.

[DSP]

Wie wäre es mit einer Währungsumrechnung? Holst grundsätzlich die Daten mal bei der EZB ab, berechnest und hinterlegst die Wechselkurse in einer Tabelle. Stellst einen Funktionsbaustein für die Währungsumrechnung in eine andere Währung zur Verfügung. Als Beispiel dann noch eine Testoberfläche und am schluss dann hier in die Code Libary :)

Kannst so komplex machen wie du willst, mit Mengen-/Preisnotierung, Kehrwerte, Multiplier, Basiswährung, unterschiedliche Kurstypen, Euro Konvertierung ... Ne nach Lust und Zeitbudget :)

[Jumpy]

Hallo,

afaik sollen das sinnvolle Projekte sein, oder Teile/Module eines größeren Projektes. Entweder für einen Kunden oder für etwas internes. In der Realität sieht das wahrscheinlich oft anders aus, aber es sollte mMn schon etwas sein, was es nicht haufenweise gibt und was in der eigenen Firma tatsächlich gebraucht werden könnte. Daher vielleicht wirklich mal beim Ausbilder nachfragen, ob es nicht in der (für die) Firma irgendetwas gibt, dass man machen könnte.

Just my 2 cents.

[theoneand]

@Dejan Vu
Das mag ja alles schön und recht sein, wenn man Ahnung von SQL hat...
Es kam nur mal eine Anfrage von einem unserer Kunden, ob sowas nicht umsetzbar ist, und für den Fall, finde
ich das Tool sehr nützlich.

Mir ist auch klar, dass jemand der sich gut mit SQL auskennt, anderer, schnellere und effektivere Wege parat hat um
das Ganze umzusetzten.

Und in der Hinsicht hab ich durch einige Recherchen noch nichts vergleichbares auf dem Markt entdeckt


@DSP
Das mit dem Währungsrechner hört sich nicht schlecht an, muss mich da mal bisschen informieren

[Dejan Vu]

Komisch, meine Kernaussage habe ich wohl nicht abgeschickt: Es ist ein tolles Projekt für eine Abschlussprüfung, die auch einen Mehrwert hat. Wenn du das hinbekommst, ist das ein Beleg für dein Können.

Ich würde die Aufgabe skizzieren, die Grundfunktionen definieren und das Thema dann absegnen lassen. Dann gehst Du ans Werk

[p80286]

[OT]

Zitat:

Zitat von Dejan Vu (Beitrag 1268664)

Komisch, meine Kernaussage habe ich wohl nicht abgeschickt:

Die ist wohl eher in den anderen Bemerkungen untergegangen:duck:
[/OT]

Ich finde die Idee übrigens ganz gut, z.B. eine Funktion zur Entfernung von Prüfziffern, oder zur Formatierung von Zifferngräbern (DE123456789012 -> DE 123 456 789 012) oder das Gegenteil (DE 123 456 789 012 ->DE123456789012) (statt blanks sind Kommata oder Punkte auch beliebt) wäre für die Datenaufbereitung ganz nett.

Gruß
K-H

[Jumpy]

Zitat:

Zitat von p80286 (Beitrag 1268680)

Ich finde die Idee übrigens ganz gut, z.B. eine Funktion zur Entfernung von Prüfziffern, oder zur Formatierung von Zifferngräbern (DE123456789012 -> DE 123 456 789 012) oder das Gegenteil (DE 123 456 789 012 ->DE123456789012) (statt blanks sind Kommata oder Punkte auch beliebt) wäre für die Datenaufbereitung ganz nett.

Gruß
K-H

Da man sich an so "Datenmanipulaions"-Funktionen totoptimieren (bzw. verzetteln) kann, wäre es cool einen Mechanismus zu entwickeln, wie man so Funktionen nachträglich leicht einbauen kann, so dass dieser Mechanismus (wie auch immer sowas aussehen könnte) zum Rahmen der Arbeit gehört, die tatsächlichen Funktionen, die man da so machen könnten, bis vllt. auf ein einfaches Beispiel, aber nachträglich (nicht im Rahmen der Arbeit) gemacht würden.

[p80286]

Zitat:

Zitat von Jumpy (Beitrag 1268682)

Zitat:

Zitat von p80286 (Beitrag 1268680)

Ich finde die Idee übrigens ganz gut, z.B. eine Funktion zur Entfernung von Prüfziffern, oder zur Formatierung von Zifferngräbern (DE123456789012 -> DE 123 456 789 012) oder das Gegenteil (DE 123 456 789 012 ->DE123456789012) (statt blanks sind Kommata oder Punkte auch beliebt) wäre für die Datenaufbereitung ganz nett.

Gruß
K-H

Da man sich an so "Datenmanipulaions"-Funktionen totoptimieren (bzw. verzetteln) kann, wäre es cool einen Mechanismus zu entwickeln, wie man so Funktionen nachträglich leicht einbauen kann, so dass dieser Mechanismus (wie auch immer sowas aussehen könnte) zum Rahmen der Arbeit gehört, die tatsächlichen Funktionen, die man da so machen könnten, bis vllt. auf ein einfaches Beispiel, aber nachträglich (nicht im Rahmen der Arbeit) gemacht würden.

Und das wäre gleichzeitig flexibler
Gruß
K-H

[jobo]

Ich find, das ist eine schöne Aufgabe. Nur nicht unbedingt für Delphi.
Was Datenoptimierung und Transformation(!) angeht, bietet Excel eigentlich mehr, als man mal eben in 70h bauen kann.

Cool fänd ich ein Excelplugin, das in der Lage ist, markierte Spalten (Mehrfachauswahl) sowie gefilterte Zeilen (nur die aktuell angezeigt sind) unabhängig ob Formel oder Wert in eine DB.NeueTabelle oder DB.BestehendeTabelle zu blasen.
Das würde erlauben, ein beliebiges Excelsheet aufbereiten zu können, mittels Formeln zu bereinigen, etc. pp. und dann eine geprüfte, bewertete Menge filtern und in die DB schieben zu können.

Zum Thema SQL und "geht alles viel schneller":
Neben den recht intuitiven Möglichkeiten, Daten per Formel zu bearbeiten, ist eine große Stärke von SpreadSheet Systemen der wahlfreie Zugriff auf Vorgänger/Nachfolger "Datensätze", wie er in vielen RDBMS gar nicht möglich ist, oder wenn doch, dann eben ist das eher etwas für SQL Experten.

Den Umweg über Delphi finde ich dabei nicht wirklich notwendig. Wär ein nettes Werkzeug für adhoc Geschichten.

[Dejan Vu]

Zitat:

Zitat von jobo (Beitrag 1268691)

Zum Thema SQL und "geht alles viel schneller"...

Es geht doch nicht um Spreadsheetfunktionen, sondern um den Import in bestehende Tabellen. Ich behaupte mal, das Typkonvertierungen ('May 27 Wed 15:23:56 GMT 2004' als DateTime), erstellen von FK-Beziehungen und sonstige Transformationen i.A. in SQL besser und vor allen Dingen schneller von statten gehen, als in EXCEL.

Ich habe das gerade die letzten Tage gemacht. So ein Import dauert schon ein paar Minuten und wenn ich die Millionen von Datensätzen in EXCEL erst konvertiert und dann über mehrere Versuche ins RDBMS importiert hätte, wäre ich jetzt noch nicht fertig.

Also erst -wupps- als Tabelle mit lauter 'varchar(max)' Spalten importiert, ein paar Indexe gesetzt, neue Spalten hinzugefügt, konvertiert und dann in die Zieltabellen transformiert. Und zwar jeweils in Transaktionen gekapselt:

Code:

begin transaction
-- do some stuff
select <stuff> into results from importedTable
update otherREsults set foo = bar from importedTable...
-- verify the results
select * from results
select * from otherResults
rollback transaction

Und dann, wenn die Verifizierung erfolgreich ist, aus dem 'rollback' ein 'commit', Skript nochmal laufen lassen, fertig.
Ich verwende jedes Werkzeug genau da, wo es am sinnvollsten/effektivsten ist. Wenn die Daten aufbereitet werden sollen, oder wenn ich Berechnungen vor dem Import vornehmen muss, würde ich vielleicht EXCEL einsetzen, das käme drauf an. Andererseits kann man mit SQL auch rechnen und Datensätze durchnummerieren, also wozu großartig mit EXCEL arbeiten? Ich bin auch nicht so versiert mit dem Teil, und wüsste jetzt gar nicht, wie ich eine Formal auf 2.5 Mio Zeilen anwenden soll, außer mit der Maus runterziehen (ächtz)

Aber bloß weil ich auf Vorschlaghammer stehe, heißt das ja nicht, das ich damit auch einen Nagel aus dem Holz ziehe. Also, kommt auf den Nagel an.

[jobo]

Zitat:

Zitat von Dejan Vu (Beitrag 1268723)

Zitat:

Zitat von jobo (Beitrag 1268691)

Zum Thema SQL und "geht alles viel schneller"...

Es geht doch nicht um Spreadsheetfunktionen, sondern um den Import in bestehende Tabellen.
Ich verwende jedes Werkzeug genau da, wo es am sinnvollsten/effektivsten ist.

Es geht nicht um Spreasheetfunktionen, aber die Verwendung von Werkzeugen soll da erfolgen, wo sie sinnvoll und effektiv ist?
Dann geht es vielleicht doch um Spreadsheetfunktionen?

Wie gesagt, Analytic Functions / Window Functions stehen nicht in allen RDBMS zur Verfügung. Insofern kann man Excel da sehr gut einsetzen, bevor es zur DB geht.

Aber das kann ja der TE prima selber entscheiden. Er hat nach Vorschlägen gefragt.

Was Du ansonsten beschreibst, ist kein klassisches ETL sondern LTE oder LET. Das ist genau mein Ding, ich mache es auch nicht anders.

[Dejan Vu]

Zitat:

Zitat von jobo (Beitrag 1268728)

Dann geht es vielleicht doch um Spreadsheetfunktionen?

Das Thema dieses Threads lautet? Genau.

Ansonsten gilt immer vorneweg: Werkzeuge dort einsetzen, wo sie sinnvoll sind. Da muss man keine Erbsenzählerei betreiben, Sätze zusammenziehen und einen neuen scheinbar streibaren Zusammenhang herstellen usw. Ist doch wohl logisch, das ich mir in SQL keinen abbreche, was in EXCEL (oder mit Bleistift) besser geht.

Ich gebe es zu, es ist frustrierend (das Wetter), aber hey! Es ist Freitag, also. 8-)

[theoneand]

ich mach mich jetzt einfach mal ans werk und werde die kommenden Wochen mal was von meinen
Ergebnissen posten.

Bin jetzt erst mal 2 Wochen in urlaub, danach wird angegriffen

[Dejan Vu]

Mach das. Bei Fragen einfach fragen!