Komplexe MySql Datenbank in Excel exportieren

[Datenbankler]

Guten Morgen
Ich habe eine MySQL Datenbank mit ca 15000 Einträgen, die Hauptdatabelle ist mit vielen kleinen Tabellen verknüpft und enthält oft nur einstellige id-Zahlen der verknüpften Tabellen.

Jetzt möchte ich eine Excel Datei der Haupttabelle exportieren die lesbar ist, also die id-Zahlen gleich durch den lesbaren Text ersetzt.
Ich habe das immer mit als CSV Datei schreiben lassen aber durch die vielen Joins bin ich recht schnell an der maximalen Laufzeit des Skripts.

Wie kann ich das geschickt machen, vielleícht die Tabellen ganz normal exportieren und hinterher mit VBA die Datei generieren lassen?
Für Anregungen wäre ich dankbar.
Grüße
Datenbankler

[Steel]

Hi!

Wenn Du Excel hast, dann doch sicher auch Access. Du kannst Deine Tabellen also in CSV Dateien exportieren, diese in Access einbinden und dort das gleiche machen wie mit mySQL. Den letzten Query schreibst Du dann einfach in eine Exceldatei.

Aber wenn deine vielen Joins die Abfrage so langwierig machen, hast Du eventuell ein Problem mit dem Design deiner Datenbank?

[Datenbankler]

Hi!

Wenn Du Excel hast, dann doch sicher auch Access. Du kannst Deine Tabellen also in CSV Dateien exportieren, diese in Access einbinden und dort das gleiche machen wie mit mySQL. Den letzten Query schreibst Du dann einfach in eine Exceldatei.

Aber wenn deine vielen Joins die Abfrage so langwierig machen, hast Du eventuell ein Problem mit dem Design deiner Datenbank?

»

Das kann ich leider nicht machen, derjenige der nachher mit den Daten arbeiten soll hat und kann nur Excel.
Ich glaub nicht das ich ein Problem mit dem Design der Datenbank habe.
In der Haupttabelle sind 16 Felder die nur eine id einer anderen Tabelle enthalten und bei Bedarf abgefragt werden. Ich bin der Meinung das es so sinnvoll ist die Datenbank "klein" zu halten. Es war eigentlich nie gedacht alle Datensätze mit allen lesbaren Daten auf einmal abzufragen.
Pro Zeile sind das 16 zusätzliche Abfragen, mache ich das schon seit Jahren falsch?

[Sven Rautenberg]

Moin!

Ich glaub nicht das ich ein Problem mit dem Design der Datenbank habe.
In der Haupttabelle sind 16 Felder die nur eine id einer anderen Tabelle enthalten und bei Bedarf abgefragt werden. Ich bin der Meinung das es so sinnvoll ist die Datenbank "klein" zu halten. Es war eigentlich nie gedacht alle Datensätze mit allen lesbaren Daten auf einmal abzufragen.
Pro Zeile sind das 16 zusätzliche Abfragen, mache ich das schon seit Jahren falsch?

Naja, die Frage ist doch: Wenn du 16 Spalten hast, und zu jeder dieser Spalte nochmal eine weitere Translation-Tabelle, die die ID der Spalte in einen sinnvollen Wert übersetzt, dann mag das aus Sicht der Normalisierungsfetischisten vermutlich gute Arbeit sein - aber man kann es auch übertreiben.

Und der zweite prüfenswerte Punkt: Hast du Indices gesetzt? Was sagt EXPLAIN zu deinem Gesamtquery mit allen JOINs? 15.000 Einträge sind nämlich eigentlich winzig wenig, da sollte es eigentlich keinen wirklichen Grund geben, warum ein Skript in irgendeine Laufzeitbegrenzung rennen sollte.

- Sven Rautenberg

[Ilja]

yo,

Wenn du 16 Spalten hast, und zu jeder dieser Spalte nochmal eine weitere Translation-Tabelle, die die ID der Spalte in einen sinnvollen Wert übersetzt, dann mag das aus Sicht der Normalisierungsfetischisten vermutlich gute Arbeit sein - aber man kann es auch übertreiben.

es klingt schief, aber selbt dann muss man genauer nachfragen. es gibt kein daten-design dass universell gültig ist, es ist immer von der jeweiligen umgebung abhängig. und es geht auch nicht um normalisierungsfetischisten, die frage ist immer, welche pros und kontras ich abwäge.

Hast du Indices gesetzt?

indices sind wie gesagt kein allheilmittel. sie können helfen und nützlich sein, sind es oftmals auch. aber der hinweis auf den explain plan ist schon besser, bzw. wenn wir mal die abfrage sehen könnten inklusive der kardinalität der daten in den tabellen.

Ilja

[Datenbankler]

Hast du Indices gesetzt?

indices sind wie gesagt kein allheilmittel. sie können helfen und nützlich sein, sind es oftmals auch. aber der hinweis auf den explain plan ist schon besser, bzw. wenn wir mal die abfrage sehen könnten inklusive der kardinalität der daten in den tabellen.

Ilja

Indices? Was ist das?
Die Datenbankstruktur möchte ich hier nicht zeigen. Ich möchte einfach Anregungen wie ich den Query nicht so extrem aufblasen muss so, dass ich die Daten korrekt erhalte.

Das ist die Abfrage wie es jetzt ist:
select r.id, r.apfel, r.birne,r.banane,r.kiwi,r.kartoffel,s.status,z.zustand, r.obst, r.gemuese from obstkorb r,status s,zustand z where s.id = r.statusid and z.id = r.zustandid

Das ist ja noch überschaubar und bezieht ja auch nur 2 externe Tabellen mit ein. Aber wenn ich versuche alle Datensätze mit dem bisherigen Skript abrufe bricht der Server das Skript ab.
Das kann ja mit 16 externen Tabellen dann ja nicht besser werden,oder?

Die csv Datei lasse ich so erstellen, vielleicht ist ja auch hier der Hund begraben:

while ($row = mysql_fetch_array($resOL))
{
$export = $export.$row["birne"].";".$row["banane"].";".$row["obst"].";".$row["gemuese"].";".$row["zustand"]."\n";

}
$datei = fopen("tmp/export.csv", "w");
fwrite($datei, $export);
fclose($datei);

[Sven Rautenberg]

Moin!

Indices? Was ist das?

Ist die Frage ernst gemeint? Wenn ja: Ein Index beschleunigt Datenbankabfragen dann enorm, wenn er korrekt gesetzt ist. Welchen Index man setzen sollte, ermittelt einem eine Abfrage mit vorangestelltem EXPLAIN, die den Ausführungsplan der SQL-Abfrage zurückgibt.

Das ist die Abfrage wie es jetzt ist:
select r.id, r.apfel, r.birne,r.banane,r.kiwi,r.kartoffel,s.status,z.zustand, r.obst, r.gemuese from obstkorb r,status s,zustand z where s.id = r.statusid and z.id = r.zustandid

Die Abfrage gefällt mir nicht. Explizite JOINs sind immer deutlich selbsterklärender, als implizite, erst recht bei 16 Tabellen.

Ich glaube auch immer noch nicht, dass eine Komplettabfrage über alle 16 Tabellen und alle Datensätze "zu lange" dauern sollte.

Unumgehbar ist allerdings, dass ein JOIN mit 16 Tabellen zwangsweise eine entsprechend lange Query-Formulierung zur Folge hat. Das kann man schlecht finden, aber verändern kann man es nicht.

Die csv Datei lasse ich so erstellen, vielleicht ist ja auch hier der Hund begraben:

while ($row = mysql_fetch_array($resOL))
{
$export = $export.$row["birne"].";".$row["banane"].";".$row["obst"].";".$row["gemuese"].";".$row["zustand"]."\n";

}
$datei = fopen("tmp/export.csv", "w");
fwrite($datei, $export);
fclose($datei);

Auf jeden Fall ist festzustellen, dass du von den speziellen CSV-Dateifunktionen, die PHP bietet, noch nichts gehört hast, und es dir anscheinend auch lieber ist, erstmal den Speicher ordentlich mit Daten vollzumüllen, anstatt die DB-Ergebnisse schon direkt in eine Datei zu schreiben.

http://de3.php.net/fgetcsv
http://de3.php.net/fputcsv

- Sven Rautenberg

[Ilja]

moin,

Ist die Frage ernst gemeint? Wenn ja: Ein Index beschleunigt Datenbankabfragen dann enorm, wenn er korrekt gesetzt ist.

es bringt wenig immer wieder auf einen index zu verweisen. dies kann ein geeigntes mittel sein, muss es aber nicht. wenn die 16 tabellen nur wenige datensätze enthalten, bringt ein index gar nichts. deswegen ist zusätzlich zu der abfrage auch immer nützlich zu wissen, wieviele datensätze enthalten die tabelle und wieviele davon will ich auswählen. leider fehlt noch diese information.

Die Abfrage gefällt mir nicht. Explizite JOINs sind immer deutlich selbsterklärender, als implizite, erst recht bei 16 Tabellen.

dies kann ich nur unterstützen, die explizite schreibweise ist immer vorzuziehen.

Ich glaube auch immer noch nicht, dass eine Komplettabfrage über alle 16 Tabellen und alle Datensätze "zu lange" dauern sollte.

auch ich habe da meine zweifel, ob es überhaupt an der abfrage liegt. deswegen mein vorschlag, die abfrage mal ganz ohne php umgebung ausführen, eben nur als reine datenbankabfrage. dann ist mal schnell einem schritt näher, wo die ursache liegt.

Ilja

[Datenbankler]

Auf jeden Fall ist festzustellen, dass du von den speziellen CSV-Dateifunktionen, die PHP bietet, noch nichts gehört hast, und es dir anscheinend auch lieber ist, erstmal den Speicher ordentlich mit Daten vollzumüllen, anstatt die DB-Ergebnisse schon direkt in eine Datei zu schreiben.

@Sven Rautenberg
Eine sachlichere Ausdrucksweise wäre angebrachter gewesen. Schade!
Schließlich bin ich hier um mich zu informieren, dieser Code den ich gepostet habe hatte nie den Anspruch riesen Datenmengen zu generieren und ist ohne große Sorgfallt gemacht worden.
Von einem ersten Vorsitzenden hätte ich mehr Sozialkompetenz erwartet.
Sorry, aber ich habe mich über dein Posting einfach geärgert.

@Ilja
Vielen Dank für die Hinweise. Es ist übrigens die PHP Seite die, die Sache begrenzt. Ich werde mich schlau machen und mich bei evtl. Problemen nochmal melden.
Grüße
Datenbankler

[Vinzenz Mai]

Hallo,

Wenn Du Excel hast, dann doch sicher auch Access. Du kannst Deine Tabellen also in CSV Dateien exportieren, diese in Access einbinden und dort das gleiche machen wie mit mySQL. Den letzten Query schreibst Du dann einfach in eine Exceldatei.

Ziel laut Steels Vorschlag: Excel.
Allerdings über einen kleinen Umweg, der Dir Deine PHP-Laufzeitprobleme beseitigt.

Das kann ich leider nicht machen, derjenige der nachher mit den Daten arbeiten soll hat und kann nur Excel.

Wo ist das Problem, wenn das Zielformat die von Dir angestrebte Excel-Liste ist? Die Zwischenstufe kann der anderen Person gleichgültig sein.

Freundliche Grüße

Vinzenz