Moin,
ich war selbst auf der Suche nach einem Konverter, habe allerdings nur kostenpflichtiges gefunden und daher selbst mal was gebastelt.

http://www.4webmaster.net/service_tools/csv_zu_mysql_konverter.htm

Mit dem CSV zu MySQL Konverter könnt ihr ganz einfach Daten aus einer CSV Datei in MySQL Statements konvertieren. Das Script erstellt auf Wunsch aus den Feldnamen in der CSV auch ein SQL Statement zum Erstellen der MySQL Tabelle, in die dann die CSV Daten eingetragen werden.

Einfach mal testen und sagen, was ihr davon haltet :)

Ich weiß gerade nicht wofür das gut sein soll. Datenbankimporte funktioneren bei z.B. MySQL auch direkt aus CSV.

Interessant. Man kann auch PDFs zu SQL Statements wandeln. ;)

INSERT INTO `csv_table` VALUES ('x
�‘OOÃ0ÅïýïÈËâüm�P�¸ ØÑóVµRÛ´– íÛãvL•ÄlÿÞ³sÄGHG ');

Es ist deshalb nützlich, weil es dir auch die MySQL Tabelle erzeugt. Das macht das normale nicht und phpMyAdmin auch nicht.

Original geschrieben von Benny-one
Es ist deshalb nützlich, weil es dir auch die MySQL Tabelle erzeugt. Das macht das normale nicht und phpMyAdmin auch nicht.

Ich glaube vorher die Tabelle zu erzeugen geht schneller als auf dein Tool zu surfen.

Achja? Ich hatte hier ne CSV mit ein 38 Spalten und 1700 Einträgen. Das ist garantiert nicht schneller, per Hand zu erzeugen.

Original geschrieben von Benny-one
Ich hatte hier ne CSV mit ein 38 Spalten und 1700 Einträgen. Das ist garantiert nicht schneller, per Hand zu erzeugen.

Naja muss halt jeder selbst Wissen. Aber in der Regel hat man bei einem CSV Import die Struktur ja schon.

Hatte ich noch nie. Ich hab eine Exceldatei, daraus mache ich eine CSV und die muss ich in MySQL bekommen. Und mein Tool macht das.

Höre nicht auf Leute, die dir das schlecht reden. Zwar gibt es in MySQL direkte Einfügemechanismen für CSV, aber wer soll da die Tabelle erzeugen? Ich hatte schon mal ein CSV-File mit über 90 Spalten!!! :teach: Da würde dein Tool eine grosse Abhilfe sein. :)

@E.T: Danke :)

Original geschrieben von E.T.
Höre nicht auf Leute, die dir das schlecht reden. Zwar gibt es in MySQL direkte Einfügemechanismen für CSV, aber wer soll da die Tabelle erzeugen? Ich hatte schon mal ein CSV-File mit über 90 Spalten!!! :teach: Da würde dein Tool eine grosse Abhilfe sein. :)

Eine Datenbanktabelle mit 90 Spalten? Das ist selten sinnvoll.

@h3ll

Warum? Kann ein Datensatz nicht unendlich viele atomare Attribute aufweisen? Was spricht dagegen? Zwar ist es richtig, dass so etwas nicht oft vorkommen mag, aber manchmal ist es nicht nur sinnvoll, sondern auch nicht anders lösbar.

Original geschrieben von E.T.
@h3ll

Warum? Kann ein Datensatz nicht unendlich viele atomare Attribute aufweisen? Was spricht dagegen? Zwar ist es richtig, dass so etwas nicht oft vorkommen mag, aber manchmal ist es nicht nur sinnvoll, sondern auch nicht anders lösbar.

Ähm... Datenbanknormalisierung?

@TroX: Was willst du normalisieren, wenn ein Objekt nun mal 90 Attribute hat?

Ein Beispiel für so viele Spalten sind Patientendaten. 30 Spalten füllt schon ein vollständiger Anamnesebogen und jeder Medizinstudent kann 60 Werte nennen, die man am Menschen messen kann.

Original geschrieben von onemorenerd
@TroX: Was willst du normalisieren, wenn ein Objekt nun mal 90 Attribute hat?

Ein Beispiel für so viele Spalten sind Patientendaten. 30 Spalten füllt schon ein vollständiger Anamnesebogen und jeder Medizinstudent kann 60 Werte nennen, die man am Menschen messen kann.

Tabelle `patient`

id, vorname, nachname, usw.
1, Karl, Mustermann, usw.
2, Franz, Huber, usw.


Tabelle `wert`

id, name
1, Anamnesewert1
2, Anamnesewert2
(kein mich mit dem medizinischen Zeug nicht aus)


Tabelle `patient_wert`

patient_id, wert_id, daten
1, 1, Daten1
1, 2, Daten2
2, 1, Daten3
2, 2, Daten4

Und was gewinnst du dadurch?

Ich kenne mich mit Patientensystemen auch nicht aus. Ist vielleicht kein gutes Beispiel.
Hier mal ein paar Limits für die Spaltenzahl gängiger DBS: MySQL 2599, PostgreSQL 1600, Oracle 1000, DB2 750. Das ist kein Schwanzvergleich, sondern wird wirklich auch benutzt. Ich habe schon OLAPS mit weit über 100 Spalten gesehen (nicht gezählt, nur drüber gescrollt).

Normalisierung sollte nur sinnvoll angewandt werden und nicht bei jedem Sch**ß und auch nicht unbedingt bis zur 5. Form runter brechen. Die Anzahl der Spalten einer Tabelle sagt auch nicht aus, ob die Datenbank sauber entworfen ist.

Original geschrieben von onemorenerd
Und was gewinnst du dadurch?

Performance und Flexibilität. Datenbanken können mit großen Zeilenmengen besser umgehen als mit vielen Spalten.

Und die Werte lassen sich leichter erweitern, bzw. benutzerdefiniert gestalten, ohne dass man irgendwas an der Tabellenstruktur herumschrauben muss.

Original geschrieben von onemorenerd
Ich kenne mich mit Patientensystemen auch nicht aus. Ist vielleicht kein gutes Beispiel.
Hier mal ein paar Limits für die Spaltenzahl gängiger DBS: MySQL 2599, PostgreSQL 1600, Oracle 1000, DB2 750. Das ist kein Schwanzvergleich, sondern wird wirklich auch benutzt. Ich habe schon OLAPS mit weit über 100 Spalten gesehen (nicht gezählt, nur drüber gescrollt).

Mein Auto fährt maximal 190 km/h, das heißt aber noch lange nicht, dass ich deshalb mit 190 km/h fahren soll. Dagegen sprechen Wirtschaftlichkeit und Sicherheit.

Original geschrieben von h3ll
Performance und Flexibilität. Datenbanken können mit großen Zeilenmengen viel besser umgehen als mit vielen Spalten.
http://www.intelligententerprise.com/showArticle.jhtml?articleID=206800851

Original geschrieben von Benny-one
http://www.intelligententerprise.com/showArticle.jhtml?articleID=206800851

Langfristige Archivierung ist halt ein Sonderfall. Aber gewöhnlich will man mit seinen Daten auch arbeiten und sie verändern.

Original geschrieben von h3ll
Performance und Flexibilität. Datenbanken können mit großen Zeilenmengen besser umgehen als mit vielen Spalten.
Das kannst du so pauschal nicht sagen. Deine Struktur da oben kackt ab, wenn ich zu einem Patienten alle Daten haben will. Du brauchst einen JOIN über 3 Tabellen (mindestens eine davon ist riesig!) und mußt über ein Resultset von 90 Datensätzen iterieren. Ohne deine sogenannte Normalisierung wäre es ein Datensatz, ein Griff, und bestenfalls ein Cache-Hit.

Und die Werte lassen sich leichter erweitern, bzw. benutzerdefiniert gestalten, ohne dass man irgendwas an der Tabellenstruktur herumschrauben muss.Normalisierung soll Redundanz und Inkonsistenz verhindern. Es soll nicht für Flexibilität sorgen. Das ist Sache der Anwendung.
Davon abgesehen ist es doch kein Problem, an 90 Spalten eine 91. anzuhängen.

Mein Auto fährt maximal 190 km/h, das heißt aber noch lange nicht, dass ich deshalb mit 190 km/h fahren soll. Dagegen sprechen Wirtschaftlichkeit und Sicherheit.Das ist kein Vergleich, denn Wirtschaftlichkeit und Sicherheit haben mit Normalisierung nichts zu tun.

Ich halte es in dem Beispielfall mit den Patientendaten auch für sinnvoller mit einer "großen" Tabelle mit vielen Spalten zu arbeiten. Das ist genau so ein Fall wie mit OOP. Flexibilität ist zwar toll, aber einige Sachen auf viel zu viele Tabellen/Klassen zu abstrahieren ist oft zu viel des Guten und wird nur gemacht weil man denkt es sei dann automatisch besser.

@nerd, doch schon mit Wirtschaftlichkeit ... denn wenn du mit Normalisierung übertreibst, explodieren deine Abfrage-String und auch die entsprechenden Matrixenoperationen, somit leidet die Anwendung an Performanceverlust ... dein Programm arbeitet somit unwirtschaftlich ;)

Original geschrieben von asp2php
@nerd, doch schon mit Wirtschaftlichkeit ... denn wenn du mit Normalisierung übertreibst, explodieren deine Abfrage-String und auch die entsprechenden Matrixenoperationen, somit leidet die Anwendung an Performanceverlust ... dein Programm arbeitet somit unwirtschaftlich ;)

Wenn du bei jeder kleinen Änderungen einen Programmierer brauchst, der Code und Datenbankstruktur anpassen muss, ist das auch nicht wirklich wirtschaftlich.

Original geschrieben von h3ll
Wenn du bei jeder kleinen Änderungen einen Programmierer brauchst, der Code und Datenbankstruktur anpassen muss, ist das auch nicht wirklich wirtschaftlich.

Als ob man ein Programm täglich ändert :rolleyes: ... die Abfragen aber werden aber schon täglich abgesetzt :rolleyes: ... kleine Rechnung:

1000 MA à 50 EUR/Std. ... sagen wir mal max. 1 Stunde/Monat für das Warten auf die Abfragergebnisse => 50000 EUR ... und das gegen eine Änderung mit einem Tagessatz/Mann(Frau) von ca. 2000 EUR ... nun, was ist teurer?

Original geschrieben von asp2php
Als ob man ein Programm täglich ändert :rolleyes:

Du kennst anscheinend unsere Kunden nicht :)

Original geschrieben von TroX
Ähm... Datenbanknormalisierung? Was hat die Anzahl der atomaren Attribute mit der Normalisierung zu tun?

Original geschrieben von h3ll
Performance und Flexibilität. Datenbanken können mit großen Zeilenmengen besser umgehen als mit vielen Spalten.

Und die Werte lassen sich leichter erweitern, bzw. benutzerdefiniert gestalten, ohne dass man irgendwas an der Tabellenstruktur herumschrauben muss.



Mein Auto fährt maximal 190 km/h, das heißt aber noch lange nicht, dass ich deshalb mit 190 km/h fahren soll. Dagegen sprechen Wirtschaftlichkeit und Sicherheit. Also das höre ich zum ersten Mal.... warum ist den ein unnötiger Join schneller ein ein einfaches Select über viele Spalten?

Original geschrieben von asp2php
1000 MA à 50 EUR/Std. ... sagen wir mal max. 1 Stunde/Monat für das Warten auf die Abfragergebnisse => 50000 EUR
Dieser Rechnung liegt die Annahme zugrunde, dass der Join von patient und patient_wert schneller läuft als ein einfaches Select. Hinzu kommt, dass bei der Join-Variante ein Resultset mit 90 Datensätzen entsteht, dass man in einer Schleife abholen und in ein Array flachklopfen muß.
Gewagte Annahme.

Ich habs so verstanden, das asp2php schon für mehrere Spalten ist, also genau das gleiche Argument wie deins.

Original geschrieben von onemorenerd
[B]Das ist Sache der Anwendung.
Davon abgesehen ist es doch kein Problem, an 90 Spalten eine 91. anzuhängen./B]
Naja, die Tabellenstruktur ändern ist immer böse.

Beispiel: Ein Alter Table an eine Tabelle mit ~1.000.000 Datensätzen braucht bei durchschnittlicher Hardware gute 3 Sekunden. Ein Join über mehere Tabellen mit ~1.000.000 Datensätzen rast irgendwo bei wenigen hunderstel Sekunden rum.

Wenn ich dir auch generell recht gebe, dass es durchaus große Zeilen geben kann. Prinzipiell vertrete ich die Meinung, dass die paar Millisekunden Performance, die man heraufbeschwören will, in den meisten Fällen eh nichts bringen, da man sich viel größere Böcke leistet, an den falschen Stellen verwendet werden oder ohnehin Mythos sind.

Original geschrieben von PHP-Desaster
Ich habs so verstanden, das asp2php schon für mehrere Spalten ist, also genau das gleiche Argument wie deins.

Das ist korrekt :)

Ich habe nicht den Standpunkt von asp2php kritisieren wollen, sondern nur darauf hingewiesen, dass sein Argument, diese Rechnung, ziemlich gewagt ist.
Ich bleibe bei der Ansicht, dass dieser Autovergleich von h3ll hinkt. Das hat mit der Diskussion um Dekomposition allerdings nichts zu tun.

Sollten wir diesen Thread splitten, alles ab dem 1. Post von h3ll (no offense) in OT verschieben?

Beispiel: Ein Alter Table an eine Tabelle mit ~1.000.000 Datensätzen braucht bei durchschnittlicher Hardware gute 3 Sekunden. Ein Join über mehere Tabellen mit ~1.000.000 Datensätzen rast irgendwo bei wenigen hunderstel Sekunden rum.Ja, aber die Spalte brauchst du doch nur ein einziges mal anfügen. Der Join läuft bei jedem Select.

Es besteht kein signifikanter Unterschied zwischen einem SELECT oder einem SELECT über mehrere Tabellen. Die Differenz bewegt sich in einem Bereich, bei dem man schon über tausend täglich Queries absetzen muss, um auf eine Stunde pro Mitarbeiter im Monat zu kommen. Und es geht hier immer noch um Queries, nicht um gelieferte Datensätze. Diese Anwendung will ich dann mal sehen. Werte, die in ihrer Summe nach oben nicht oder sehr hoch limitiert sind, würde ich dahingehend nicht als Spalten hinzufügen.

Prinzipiell ist es mir egal, aber man muss auch nicht auf jeden Zug aufspringen, der durch den Entwicklerbahnhof fährt und fancy aussieht.

Original geschrieben von onemorenerd
Ich habe nicht den Standpunkt von asp2php kritisieren wollen, sondern nur darauf hingewiesen, dass sein Argument, diese Rechnung, ziemlich gewagt ist.


Klar ist es übertrieben; letztlich wollte ich nur damit sagen, dass man die DB nicht zu Tode normalisiert, nur weil man gehört hat, dass Normalisierung gut ist. Denn JOIN ist immer langsamer als select auf eine Tabelle. Lieber Index sinnvoll definieren als die Tabelle unnötig zerlegen.


Sollten wir diesen Thread splitten, alles ab dem 1. Post von h3ll (no offense) in OT verschieben?

Mach doch :D ... ich zu faul dazu :D

Original geschrieben von Benny-one
Moin,
ich war selbst auf der Suche nach einem Konverter, habe allerdings nur kostenpflichtiges gefunden und daher selbst mal was gebastelt.

http://www.4webmaster.net/service_tools/csv_zu_mysql_konverter.htm

Mit dem CSV zu MySQL Konverter könnt ihr ganz einfach Daten aus einer CSV Datei in MySQL Statements konvertieren. Das Script erstellt auf Wunsch aus den Feldnamen in der CSV auch ein SQL Statement zum Erstellen der MySQL Tabelle, in die dann die CSV Daten eingetragen werden.

Einfach mal testen und sagen, was ihr davon haltet :)

was nen zeitersprarendes tool !
meine CSV sind nämlich auch vielspaltig, durch erfassung von diverser wetterdaten !!

Warum stoß ich erst jetzt dadrauf? Hab vor kurzem noch ner Bekannten dabei geholfen, weil der direkte Weg aus irgendeinem Grund temporär nicht funktionierte (Hosters Problem) und hab das ganze schnell selbst geschrieben. :mad: