bessere Performance durch denormalisierung??? (joins vermeiden)

[Animal21]

Hallo leute,
wir importieren unsere Kundendaten hier aus einer excel-tabelle (csv) in unsere datenbank.

Darin sind die kunden-, address-, anbieterdaten... gespeichert.
Da es ziemlich viele Kunden werden können (sind), haben wir überlegt auf eine Normierung, der tabelle zu verzichten und alles in eine zu packen und damit bei späteren Abfragen auf unzählige joins (wheres) zu verzichten, da der Faktor geschwindigkeit sehr wichtig ist.

Die frage ist, ob die anfallende redundanz durch die nicht normierte tabelle zu groß wird, oder ob es akzeptabel ist.

Habt ihr vll erfahrungen/empfelungen... zu diesem thema?
Bringt das ganze überhaupt mehr geschwindigkeit?
...

PS: Wir denken, dass wir mögliche anomalien durch einen zusmmengesetzten primärschlüssel umgehen können, soll heißen dass wir mehrere schlüsselkandidaten haben, welche wir prüfen.
Alle Updates und Inserts werden über eine EINDEUTIGE kunden ID bzw. rufnummer iniziiert.

mfg
Ani

[tinof]

Naja, da müßt ihr bitte etwas konkreter werden:

Was sind bei Euch "Kundendaten" ?
- Adressen
- Ansprechpartner (vielleicht mehrere) ?
- Kontakte (vielleicht mehrere) ?
usw.

In der Regel ist Redundanz im Stammdatenbereich längerfristig keine gute Idee, zumindest ist das meine Erfahrung.

Für irgendwelche speziellen Auswertungen (--> DataWareHouse) ok, aber ein "Kundenstamm" sollte 3.NF sein. Wenn man dabei Integer - Primär-/Fremdschlüssel einführt, ist das alles auch hinreichend schnell.

Aber das ist ein Allgemeinplatz, man müßte schon etwas mehr über die Daten wissen.

Tino

[Bernhard Geyer]

Von wieviel Hundert Mio. Kundendatensätzen sprechen wir? Ansonsten würde ich eher sagen das das jede 0815 DB bei korrekter Programmierung und Dimensionierung locker schaft.

[dbwizard]

[QUOTE=Animal21;198950]Hallo leute,
wir importieren unsere Kundendaten hier aus einer excel-tabelle (csv) in unsere datenbank.


PS: Wir denken, dass wir mögliche anomalien durch einen zusmmengesetzten primärschlüssel umgehen können, soll heißen dass wir mehrere schlüsselkandidaten haben, welche wir prüfen.
Alle Updates und Inserts werden über eine EINDEUTIGE kunden ID bzw. rufnummer iniziiert.

/QUOTE]

- Nein. Ein sauberes Datenmodell ist essentiel. Im übrigen , wenn es in ein Excel passt, sollte es für eine Datenbank eher kein Problem in Bezug auf Datenmenge

[Animal21]

danke erstmal für eure antworten

Wir haben bei einem vorhergehenden Projekt bis zur 3. nf normalisiert, einfache abfragen sind keine problem, super schnell, nur beim exportieren sieht das anders aus.

Wir haben ungefähr 10 tabellen, die excel-Tabellen werden importiert und über unsere (web)anwendung bearbeitet, danach wieder exportiert (in excel-Tabellen)...

Die abfrage zum exportieren hat über 10 joins und daurt bei nur einigen hundert datensätzen schon mehrere Sekunden.

mfg
ani

[Bernhard Geyer]

[QUOTE=Animal21;199051Die abfrage zum exportieren hat über 10 joins und daurt bei nur einigen hundert datensätzen schon mehrere Sekunden.[/QUOTE]
Hast du schon mal mit den Profiler-Mitteln der DB untersucht was so lange dauert? Unter Umständen Fehlt ein Index oder du mußt der DB noch ein paar "Hinweise" auf zu verwendente Indizes geben. Bei mehrern Jpins kann es schon vorkommen das sich der Query Analyzer "verguckt" und einen ungünstigen Queryplan verwendet.

[Animal21]

Hab ich noch nichts von gehört.

Wir verwenden Xampp, (also phpmyadmin zum verwalten), is der db-profiler ein programm oder waS?

Hier mal eine export-abfrage:

select
...
...
...
from (((((`kundenliste` `k` join `rechnung` `rech` on((`k`.`kunden_id` = `rech`.`kunden_id`)))join `ansprechpartner` `ans` on((`k`.`kunden_id` = `ans`.`kunden_id`))) join `anschluss` `an` on((`k`.`kunden_id` = `an`.`kunden_id`))) join `adresse` `adr` on((`k`.`kunden_id` = `adr`.`kunden_id`))) left join `konto` `ko` on((`k`.`kunden_id` = `ko`.`kunden_id`)))left join `abw_id_anschluss` `abw_a` on((`abw_a`.`kunden_id` = `k`.`kunden_id`)) left join `abw_id_rechnung` `abw_r` on((`abw_r`.`kunden_id` = `k`.`kunden_id`)) WHERE k.bestelldatum >='2009-02-01' AND k.bestelldatum <= '2009-02-03' and k.project_id='0'

mfg
ani

edit:
bei phpmyadmin gibts eine funktion "messen" die man bei nach der sqlabfrage machen kann, hier das ergebniss:

Status Dauer
(initialization) 0.0000255
Opening tables 0.0001892
System lock 0.000002
Table lock 0.0000047
init 0.0000065
optimizing 0.0000025
statistics 0.0000077
preparing 0.0000057
executing 0.0000282
Sending data 0.00004
end 0.0000022
query end 0.0000035
freeing items 0.0000045
closing tables 0.0000015
removing tmp table 0.0000582
closing tables 0.0000025
logging slow query 0.0000027

sieht eigentlcih alles schnell aus nur:
Zeige Datensätze 0 - 29 (105 insgesamt, die Abfrage dauerte 3.4128 sek.)
3,5 sekunden is ganz schön viel, oder? (für 105 datensätze)

edit2:
unsere kundentabelle hab zz ungefähr 20.000 einträge.
(ändert sich oft, nach oben)

[tinof]

3,5 Sekunden auch im MySQL - Abfragefenster oder beim kompletten Excel - Export?

Ich meine, ist die DB - Abfrage so langsam oder der angeschlossene Export.

Ich frage so dumm, weil ich bei Excel - Zugriffen auch hin und wieder mit Performanceproblemen kämpfe.

Tino

[Animal21]

beim exportieren in excel ca 15 sekunden und die reine sql abfrage in phpmyadmin ca 3.5090 sekunden

mfg
ani

[Bernhard Geyer]

beim exportieren in excel ca 15 sekunden und die reine sql abfrage in phpmyadmin ca 3.5090 sekunden

Dann ist es wohl klar wo man versuchen sollte zu optimieren. Eher wohl bei den 75% Zeitverbrauch als bei den 25%.

[Animal21]

danke erstmal

wir wollten noch wissen, ob die 3,5 sekunden für die abfrage angemessen sind, oder viel zu viel ist?...

mfg
ani

[tinof]

Hallo,

ich vermute mal - wirklich nur eine Vermutung - dass die 3.5 Sekunden nicht proportional zur Menge an Datensätzen steigen werden.
Ich beobachte bei solchen Abfragen öfters eine gewisse 'Latenz' , so als muss der Server erstmal darüber nachdenken. Wenn er dann weiß, was er machen soll, dann ist es auch ziemlich egal ob es um 100 oder 1000 Datensätze geht.

Ja, das ist eine ziemlich unprofesionelle Aussage, aber testets' halt einfach mal mit ein paar mehr Sätzen.

Tino

[dbwizard]

....so als muss der Server erstmal darüber nachdenken. Wenn er dann weiß, was er machen soll, dann ist es auch ziemlich egal ob es um 100 oder 1000 Datensätze geht.

Ja, das ist eine ziemlich unprofesionelle Aussage, aber testets' halt einfach mal mit ein paar mehr Sätzen.

Tino

Ja, dass muss er tatsächlich :-) Er parst dein SQL, evtl Hard- und Soft Parse und berechnet den (aus seiner Sicht) optimalen Zugriffsplan. Nur können wir mit den Angaben des OP dazu keine Aussagen machen, ob die 3.5 sec gut / schlecht / schnell / langsam sind. Ist das SQL schlecht geschrieben oder das Datenmodel "unperformant" ? Bei solchen Fragen wäre es hilfreich, wenn ein lauffähiges Beispiel dazu gepostet werden würde, mit Create Scripts, Beispieldaten etc, dann könnten wir hier eine besser Aussage machen...


Gruss