cht: MySQL - Datenbankstruktur und Performance

Hallo zusammen!

Ich arbeite zur Zeit an einem Shop mit LinuxApacheMysqlPhp4. Da die Kunden, die die Site besuchen, die Produkte, welche sie irgendwann mal bestellt haben als Einkaufsliste wiederfinden sollen, muss ich diese Informationen in MySQL speichern. Nun habe ich eine Kundentabelle und eine Produktetabelle. Für die Einkaufsliste habe ich mir eine Kombination aus Kd.Nr. und Art.Nr. gedacht. Rein theoretisch kann dies in dieser Tabelle aber zu 20 - 30 Millionen Kombinationen führen (Viele Produkte). Kriegt MySQL das hin? Wie schnell geht das? Gibt es evtl. andere Möglichkeiten?

Für eure Hilfe bin ich sehr Dankbar

Gruss cht

  1. Hi,

    Für eure Hilfe bin ich sehr Dankbar

    abhaengig von der eingeseten Hardware kann MySQL mit belibigen Datenmengen umgehen, je mehr RAM und je mehr CPU's desto performanter. Schau mal bei http://www.mysql.com/ nach Benchmarks.

    Jan

  2. Hallo,

    [...] Rein theoretisch kann dies in dieser Tabelle aber zu 20 - 30 Millionen Kombinationen führen (Viele Produkte).

    Wie Du schon sagst, 'rein theoretisch'. Das würde ja nur passieren, wenn jeder Kunde jedes Produkt kaufen würde. Wenn das passiert, dann wäre glaub' ich genug Geld da, um sich richtig viele Maschinen für einen Riesen-cluster zu kaufen ;-)

    Grundsätzlich ist es richtig, sich Überlegungen zum Thema Datenaufkommen zu machen. Aber nicht das theoretisch mögliche, sondern realistische Vorgaben sind gefragt.
    Stell Dir folgende Fragen:
    Wie viele Kunden wird es geben?
    Wie viele Produkte wird ein Kunde im Schnitt kaufen?

    Daraus ergibt sich das durchschnitttliche Datenaufkommen : Kunden x GekaufteProdukte
    Du kannst Dir natürlich Beispieldaten erzeugen, um die Peroformance zu testen (lokal).
    Das würde ich Dir in jedem Falle empfehlen, da Du nur so die Performance der Datenbank und der Abfragen optimieren kannst.

    Du kannst Dir natürlich auch gleich Überlegungen machen, wie Du eine Datenarchivierung implementierst, falls es zu Performance-schwierigkeiten kommt.
    Bei vielen DB-basierenden Projekten ist es üblich zwsichen laufenden Nutzdaten und Archiv-Daten zu unterscheiden, um die Performance zu verbessern.
    (Auch in diesem Forum wird so etwas ähnliches gemacht)

    Wie schnell geht das?

    Das hängt von der Hardware, dem Datenbankdesign und dem Design Deiner Abfraegn ab, ist also aus der Ferne nicht seriös zu beantworten.

    Gibt es evtl. andere Möglichkeiten?

    Schau mal, grundsätzlich ist Dein Ansatz der richtige, da viele Kunden viele Produkte kaufen werden, Du dadurch eine sogenannte 'm:n'-Beziehung zwischen Kunden- und Produkt-Stammdaten aufbauen mußt.
    Dein Ansatz ist da sicherlich der einfachste und offensichtlichste.
    Ander Möglichkeiten gibt es viele, je nachdem,  _wie_ Du Deine Daten strukturieren willst.
    Du solltest Darüber nachdenken, ob Du nicht mehr Informationen sammlen willst, als nru 'welcher Kunde hat irgendwann welches Produkt gekauft'.
    z.B ist es interessant, wann wieviel Produkte von welchem Kunden gekauft wurden.
    Ich habe es immer als sinnvoll erachtet, gleich einmal alle möglichen Fragen an die Datenbank aufzuschreiben, weil es einem immer wieder hilft, wenn man die Datenbank erstellt, zu wissen, was man eigentlich für Abfragen an die Datenbank stellen will.

    Du solltest Dir unbedingt Literatur zum Thema Datenbank-Design kaufen, bzw./und jemanden suchen der Dir beim Design der datenbank hilft, weil ein schlechtes Design der Datenbank ist später oft nur schwer, und wenn überhaupt, nur mit großem Aufwand zu reparieren.
    Das Problem ist, daß Du so aus der Ferne max. Allgemeinplätze alà 'Normalisieren' usw. zu hören bekommst, welche Dir wahrscheinlich nicht wirklich weiterhelfen werden.

    Grüße
       Klaus

    1. Vielen Dank an euch beide

      Das Buch MySQL & mSQL ist gekauft. Ausserdem hab ich da noch einiges über Access.
      Ich werde bezüglich der Besucherzahl mal mit einer zwar üppigen aber doch realistischen Zahl rechnen. Wenn's dann mehr sind, ist das mit dem Cluster sicher die Rettung. :)))

      Gruss cht

    2. Hallo Klaus,
      ...

      Du solltest Dir unbedingt Literatur zum Thema Datenbank-Design kaufen, bzw./und jemanden suchen der Dir beim Design der datenbank hilft, weil ein schlechtes Design der Datenbank ist später oft nur schwer, und wenn überhaupt, nur mit großem Aufwand zu reparieren.
      Das Problem ist, daß Du so aus der Ferne max. Allgemeinplätze alà 'Normalisieren' usw. zu hören bekommst, welche Dir wahrscheinlich nicht wirklich weiterhelfen werden.

      Ich habe bisher nur extrem langweilige und schlechte Literatur zum DB-Design in der Hand gehabt. Kannst du mir hier gute, ausfuehrliche, komplette und verstaendliche (fuer einen Anfaaenger) Buecher empfehlen?

      Viele Gruesse

      Johannes

      1. Hallo,

        Ich habe bisher nur extrem langweilige und schlechte Literatur zum DB-Design in der Hand gehabt. Kannst du mir hier gute, ausfuehrliche, komplette und verstaendliche (fuer einen Anfaaenger) Buecher empfehlen?

        Naja, ist wirklich schwierig, ich hab' mich selber halt so durch alle möglichen Wälzer durchgequält, das meiste habe ich aus Zeitschriften, Dokumentationen und Bücher rund um Oracle (dort braucht man ein gutes Design mehr als anderswo). Ich hab halt viel gelesen, viel probiert, oft auf die Schnauze gefallen, aber nie aufgegeben ;-)

        Grundbegriffe werden eigentlich in vielen Büchern zu speziellen Datenbanken angeboten, z.B.: 'MySQL & mSQL' von O'Reilly. Ich finde, daß dieses Buch für Leute, die mit Web, CGI und Datenbanken zu tun haben, eigentlich eine gute Wahl ist, weil neben der Datenbank-Beschreibung und einer EInführung in SQL auch gleich die Programmierung über diverse im Web verwendeten Sprachen mit dabei ist.

        Einige gute Ansätze werden auch mit dem Buch 'Oracle Performance tuning' vom gleichen Verlag vermittelt, allerdings gehts da zum Teil schon sehr ins EIngemachte, und es ist nur in englisch verfügbar.

        Aber vielleicht weiß jemand anders gute Literatur.

        Grüße
           Klaus