nicht angemeldet
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