9
Excel (CSV) Datei auswerten
Hi,
wie kann ich am einfachsten eine Excel (CSV) Datei auswerten.
Ich habe 16 Spalten mit unterschiedlichen Daten (z.B. Datum, Uhrzeiten, User IDs usw.).
Es sind Zugriffzeiten von Usern auf ein Server, ausgewertet sollen werden wann, wieviele, wielange, durchschnittszeit usw.
Vorschlag ist bisher die Daten in MySQL Tabellen zu schreiben und mit PHP und HTML auf ein Frontend dar zu stellen.
Da ich in all diesen Themen ein absoluter Neuling bin wollte ich gern wissen ob es noch andere Möglcihkeiten gibt.
wie kann ich am einfachsten eine Excel (CSV) Datei auswerten.
Ich habe 16 Spalten mit unterschiedlichen Daten (z.B. Datum, Uhrzeiten, User IDs usw.).
Es sind Zugriffzeiten von Usern auf ein Server, ausgewertet sollen werden wann, wieviele, wielange, durchschnittszeit usw.
Vorschlag ist bisher die Daten in MySQL Tabellen zu schreiben und mit PHP und HTML auf ein Frontend dar zu stellen.
Da ich in all diesen Themen ein absoluter Neuling bin wollte ich gern wissen ob es noch andere Möglcihkeiten gibt.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 22885
Url: https://administrator.de/forum/excel-csv-datei-auswerten-22885.html
Ausgedruckt am: 16.02.2025 um 18:02 Uhr
9 Kommentare
Neuester Kommentar
Also rein theoretisch lassen sich EXCEL-Tabellen auch mit EXCEL auswerten....
Und im Grunde halte ich ein Tabellenkalkulationsprogramm sogar für Auswertungen geeignet....
Ich glaube ich verstehe etwas nicht....
Und im Grunde halte ich ein Tabellenkalkulationsprogramm sogar für Auswertungen geeignet....
Ich glaube ich verstehe etwas nicht....
Mh, wenn ich mit den Makros auswerten kann wann sich wer, wielange oder durchschnittlich eingeloggt hat, dann ja.
Aber ich denke bei z.Zt. 14000 Zeilen ist das vielleciht zu viel.
Aber ich denke bei z.Zt. 14000 Zeilen ist das vielleciht zu viel.
Moin chris,
geht mir (und wahrscheinlich allen anderen) genauso wie verkehrsberuhigt.. die Strategie ist nicht ganz klar..
Ich versuchs mal mit Rückfragen:
- warum um Himmels willen liegen denn die Daten jetzt als Excel-CSV vor? Ist das irgendein AD/ADSI-Export?
- wenn denn diese Daten viel zu detailliert sind, um damit etwas anzufangen, warum denn dann den ganzen Müll noch mal in MySQL überführen?
- wenn ihr nur die verdichteten Daten braucht, dann lass da einen kleinen Batch/ein kleines VBSkript drüberschrapeln, am besten als Dienst morgens um 02h oder so, der aus den 14000 "Datensätzen" die 300 "verdichteten" macht
- und DANN können wir über das Anzeige-Thema meditieren - wo die Daten am Besten abgerufen/abgefragt werden können.
Bitte um Erläuterung
Biber
geht mir (und wahrscheinlich allen anderen) genauso wie verkehrsberuhigt.. die Strategie ist nicht ganz klar..
Ich versuchs mal mit Rückfragen:
- warum um Himmels willen liegen denn die Daten jetzt als Excel-CSV vor? Ist das irgendein AD/ADSI-Export?
- wenn denn diese Daten viel zu detailliert sind, um damit etwas anzufangen, warum denn dann den ganzen Müll noch mal in MySQL überführen?
- wenn ihr nur die verdichteten Daten braucht, dann lass da einen kleinen Batch/ein kleines VBSkript drüberschrapeln, am besten als Dienst morgens um 02h oder so, der aus den 14000 "Datensätzen" die 300 "verdichteten" macht
- und DANN können wir über das Anzeige-Thema meditieren - wo die Daten am Besten abgerufen/abgefragt werden können.
Bitte um Erläuterung
Biber
14000 Zeilen sollten für excel eigentlich kein problem darstellen.
eventuell lässt sich dies sogar mit formeln realisieren.
eventuell lässt sich dies sogar mit formeln realisieren.
Moin chris,
- warum um Himmels willen liegen denn die
Daten jetzt als Excel-CSV vor? Ist das
irgendein AD/ADSI-Export?
- warum um Himmels willen liegen denn die
Daten jetzt als Excel-CSV vor? Ist das
irgendein AD/ADSI-Export?
Also die die Excel geht aus einer Binären Datei hervor die der Server erstellt, jeden Tag.
- wenn denn diese Daten viel zu detailliert
sind, um damit etwas anzufangen, warum denn
dann den ganzen Müll noch mal in MySQL
überführen?
sind, um damit etwas anzufangen, warum denn
dann den ganzen Müll noch mal in MySQL
überführen?
In SQL nur weil man daraus besser die Abfragen erstellen kann, wurde mir berichtet.
- wenn ihr nur die
verdichteten Daten
braucht, dann lass da einen kleinen
Batch/ein kleines VBSkript
drüberschrapeln, am besten als Dienst
morgens um 02h oder so, der aus den 14000
"Datensätzen" die 300
"verdichteten" macht
verdichteten Daten
braucht, dann lass da einen kleinen
Batch/ein kleines VBSkript
drüberschrapeln, am besten als Dienst
morgens um 02h oder so, der aus den 14000
"Datensätzen" die 300
"verdichteten" macht
Alle Daten sind wichtig außer natürlich die Datensätze die Null beinhalten.
Wie die Daten bearbeitet werden ist egal, Ziel ist das ich eine HTML Seite habe wo man die verschiedenensten Statistiken ansehen kann.
Wenn das mit einem VBSkript geht cool dann gib mal bitte ein Tipp wo ich mir dazu was ansehen kann.
Hier mal ein Beispiel der Daten:
AP Nr Date Time Calling ID Duration Incoming Board Incoming Port
10 12/26/2005 23:28:55 123455 50 15 55
10 12/26/2005 23:28:55 123455 77 15 55
10 12/27/2005 00:23:05 123455 0 15 56
Daraus möchte ich anzeigen wer, wann, wie lange usw. ein geloggt war.
- und DANN können wir über das
Anzeige-Thema meditieren - wo die Daten am
Besten
abgerufen/abgefragt
werden können.
Bitte um Erläuterung
Biber
Anzeige-Thema meditieren - wo die Daten am
Besten
abgerufen/abgefragt
werden können.
Bitte um Erläuterung
Biber
in dem fall, biste doch besser mit php + csv-file unterwegs.
sorry, zu sehr auf eine einfache auswertung konzentriert.
sorry, zu sehr auf eine einfache auswertung konzentriert.
Moin chris,
danke für die Antwort, bin schon schlauer jetzt, aber einmal will ich noch nachhaken:
Hmmm ja... aber: Wenn sich später die Granularität (also die Detailliertheit der Abfragen, die "Detailtiefe") auf der Ebene "Monatliche Anmeldezeiten je Account" erschöpft, dann brauchst Su eben nur die aggregierten Daten.
Oder andersherum, Du brauchst nur alle "Datensätze", wenn auch jemals die Frage kommt "Wie oft und zu welchen Zeiten hat sich Account xyz am vorletzten Dienstag im April eingeloggt?".
Denn der Nachteil, wenn Du alle Infos mitschleppst, ist ja: es müssten auch jedesmal, wenn Du die Monatssicht auf dem Monitor haben willst, alle 14000 Datensätze aufaddiert werden. Wenn das nicht nötig ist, würde ich das nicht machen.
Aber egal welcher Weg: Du kannst auch in MySql
a) eine CSV-Datei mit obigem Aufbau direkt importieren (einmalig alles, manuell); not recommended
b) per Skript/Batch/Makro das ganze per SQL-Statements updaten (immer nur die "neuen" Sätze)
c) das per PHP machen
Aber dazu müsstest Du trotz alledem erstmal meditieren,
- wie die Datenbanktabelle(n) aussehen sollen
- welche Auswertungs-Anforderungen dann tatsächlich da sind
(das, was ich oben als "Granularität der Daten" umschrieben habe).
Eine Eins-zu-Eins-Übernahme einer gesamten Logdatei/Protokolldatei hatte ich in der Praxis noch nie, glaube ich.
Grüße
Biber
danke für die Antwort, bin schon schlauer jetzt, aber einmal will ich noch nachhaken:
In SQL nur weil man daraus besser die Abfragen erstellen kann, wurde mir berichtet.
Hmmm ja... aber: Wenn sich später die Granularität (also die Detailliertheit der Abfragen, die "Detailtiefe") auf der Ebene "Monatliche Anmeldezeiten je Account" erschöpft, dann brauchst Su eben nur die aggregierten Daten.
Oder andersherum, Du brauchst nur alle "Datensätze", wenn auch jemals die Frage kommt "Wie oft und zu welchen Zeiten hat sich Account xyz am vorletzten Dienstag im April eingeloggt?".
Denn der Nachteil, wenn Du alle Infos mitschleppst, ist ja: es müssten auch jedesmal, wenn Du die Monatssicht auf dem Monitor haben willst, alle 14000 Datensätze aufaddiert werden. Wenn das nicht nötig ist, würde ich das nicht machen.
Aber egal welcher Weg: Du kannst auch in MySql
a) eine CSV-Datei mit obigem Aufbau direkt importieren (einmalig alles, manuell); not recommended
b) per Skript/Batch/Makro das ganze per SQL-Statements updaten (immer nur die "neuen" Sätze)
c) das per PHP machen
Aber dazu müsstest Du trotz alledem erstmal meditieren,
- wie die Datenbanktabelle(n) aussehen sollen
- welche Auswertungs-Anforderungen dann tatsächlich da sind
(das, was ich oben als "Granularität der Daten" umschrieben habe).
Eine Eins-zu-Eins-Übernahme einer gesamten Logdatei/Protokolldatei hatte ich in der Praxis noch nie, glaube ich.
Grüße
Biber
Mh wie geschrieben, MySQL wurde mir empfohlen, ob das sinnvoll ist weiß ich nicht.
Die Daten sollen alle archieviert werden, es kommen jeden Tag neue dazu, von verschiedenen Servern.
Als Endprodukt soll eine HTML Seite raus kommen wo zum Beispiel ein Kalender ist mit Links.
D.h. ich klicke auf das Jahr 2005 dann sehe ich die Stats mit einem Diagramm vielleich und das für jeden Monat und Tag.
Die Daten sollen alle archieviert werden, es kommen jeden Tag neue dazu, von verschiedenen Servern.
Als Endprodukt soll eine HTML Seite raus kommen wo zum Beispiel ein Kalender ist mit Links.
D.h. ich klicke auf das Jahr 2005 dann sehe ich die Stats mit einem Diagramm vielleich und das für jeden Monat und Tag.
Moin chris,
danke für die Antwort, bin schon
schlauer jetzt, aber einmal will ich noch
nachhaken:
>> In SQL nur weil man daraus besser
die Abfragen erstellen kann, wurde mir
berichtet.
Hmmm ja... aber: Wenn später die
Granularität (also die Detailliertheit
der Abfragen, die "Detailtiefe")
auf der Ebene "Monatliche Anmeldezeiten
je Account" erschöpft, dann
brauchst Su eben nur die aggregierten
Daten.
Oder andersherum, Du brauchst nur
alle
"Datensätze", wenn auch
jemals die Frage kommt "Wie oft und zu
welchen Zeiten hat sich Account xyz am
vorletzten Dienstag im April
eingeloggt?".
Denn der Nachteil, wenn Du alle Infos
mitschleppst, ist ja: es müssten auch
<u>jedesmal</b>, wenn Du die
Monatssicht auf dem Monitor haben willst,
alle 14000 Datensätze aufaddiert
werden. Wenn das nicht nötig ist,
würde ich das nicht machen.
Aber egal welcher Weg: Du kannst auch in
MySql
a) eine CSV-Datei mit obigem Aufbau direkt
importieren (einmalig alles, manuell); not
recommended
b) per Skript/Batch/Makro das ganze per
SQL-Statements updaten (immer nur die
"neuen" Sätze)
c) das per PHP machen
Aber dazu müsstest Du trotz alledem
erstmal meditieren,
- wie die Datenbanktabelle(n) aussehen
sollen
- welche Auswertungs-Anforderungen dann
tatsächlich da sind (das, was ich oben
als "Granularität der Daten"
umschrieben habe.
Eine Eins-zu-Eins-Übernahme einer
gesamten Logdatei/Protokolldatei hatte ich
in der Praxis noch nie, glaube ich.
Grüße
Biber
danke für die Antwort, bin schon
schlauer jetzt, aber einmal will ich noch
nachhaken:
>> In SQL nur weil man daraus besser
die Abfragen erstellen kann, wurde mir
berichtet.
Hmmm ja... aber: Wenn später die
Granularität (also die Detailliertheit
der Abfragen, die "Detailtiefe")
auf der Ebene "Monatliche Anmeldezeiten
je Account" erschöpft, dann
brauchst Su eben nur die aggregierten
Daten.
Oder andersherum, Du brauchst nur
alle
"Datensätze", wenn auch
jemals die Frage kommt "Wie oft und zu
welchen Zeiten hat sich Account xyz am
vorletzten Dienstag im April
eingeloggt?".
Denn der Nachteil, wenn Du alle Infos
mitschleppst, ist ja: es müssten auch
<u>jedesmal</b>, wenn Du die
Monatssicht auf dem Monitor haben willst,
alle 14000 Datensätze aufaddiert
werden. Wenn das nicht nötig ist,
würde ich das nicht machen.
Aber egal welcher Weg: Du kannst auch in
MySql
a) eine CSV-Datei mit obigem Aufbau direkt
importieren (einmalig alles, manuell); not
recommended
b) per Skript/Batch/Makro das ganze per
SQL-Statements updaten (immer nur die
"neuen" Sätze)
c) das per PHP machen
Aber dazu müsstest Du trotz alledem
erstmal meditieren,
- wie die Datenbanktabelle(n) aussehen
sollen
- welche Auswertungs-Anforderungen dann
tatsächlich da sind (das, was ich oben
als "Granularität der Daten"
umschrieben habe.
Eine Eins-zu-Eins-Übernahme einer
gesamten Logdatei/Protokolldatei hatte ich
in der Praxis noch nie, glaube ich.
Grüße
Biber
Danke, chris,
MySQL ist ja auch brauchbar.. machen Hunderttausend andere auch.
Und sorry für die blöde Formatierung eben, sooooooo viel wollte ich gar nicht betonen
Noch mal das Wichtigere:
Aber dazu müsstest Du trotz alledem erstmal meditieren,
- wie die Datenbanktabelle(n) aussehen sollen
- welche Auswertungs-Anforderungen dann tatsächlich da sind (das, was ich oben als "Granularität der Daten" umschrieben habe.
Denke Dir ein Fragezeichen dazu. Dann wäre jetzt das, was wir vor irgendwelchen handwerklichen Schritten bräuchten.
Grüße
Biber
MySQL ist ja auch brauchbar.. machen Hunderttausend andere auch.
Und sorry für die blöde Formatierung eben, sooooooo viel wollte ich gar nicht betonen
Noch mal das Wichtigere:
Aber dazu müsstest Du trotz alledem erstmal meditieren,
- wie die Datenbanktabelle(n) aussehen sollen
- welche Auswertungs-Anforderungen dann tatsächlich da sind (das, was ich oben als "Granularität der Daten" umschrieben habe.
Denke Dir ein Fragezeichen dazu. Dann wäre jetzt das, was wir vor irgendwelchen handwerklichen Schritten bräuchten.
Grüße
Biber
