CSV-Datei als Datenbank benutzen - Bitte um Meinungen

[Saipan]

Hallo,

wir betreiben einen Shop für unseren festen Kundenstamm (Großhandel), indem es Brutto- und kundenspezifische Nettopreise gibt. Die Bruttopreise sind in der Artikeldatenbank eingepflegt. Dieses auch für die Nettopreise zu tun, erscheint mir zunächst nicht praktikabel (alleine schon die Aktualisierung der Preise), da wirklich jeder Kunde bei jeder Artikelgruppe einen anderen Rabatt erhält und bei einzelnen Artikeln, die er besonders oft abnimmt, wiederum einen vom Rabatt unabhängigen Preis hat.
Um die Dimension etwas vorstellbar zu machen, es sind zur Zeit über 22000 Artikel und etwa 1000 Kunden, die den Shop wirklich nutzen.

Momentan habe ich eine Lösung gefunden, ich glaube sogar hier im Forum, bei der der Preis aus einer CSV-Datei ausgelesen wird. Die CSV-Datei hat eine Größe von unter 380 KB. Das entsprechende Script sieht wie folgt aus:

if(!empty($this->preisliste)){
//Abgefragt wird, ob für den User eine Preisdatei aufgespielt ist
require_once('common.php');
$preisliste = trim($this->preisliste);
//Der Name der Preisliste (User-Datenbank) ist gleich der Dateiname
$artnr = $productTpl->article;
$datei = "preise/".$preisliste.".csv";
//hier kommt der name der .csv-Datei rein
if(file_exists($datei)){
if($artnr > 0){
$inhalt = file($datei);
//hier wird die .csv-Datei ausgelesen
for($i=0;!empty($inhalt[$i]);$i++){
$t = explode(";",$inhalt[$i]);
if($t[0]==$artnr){
//hier wird verglichen ob die übergebene Artikelnummer mit der in der aktuellen Zeile übereinstimmt
$preis = $t[1];
//hier wird dann der preis der variablen $preis zugewiesen
break;
//beendet die for()-Schleife
}
}
}
$inzahl = strtr($preis, array(',' => '.'));
$productTpl->nettopreis = number_format($inzahl, 2, ',', '.');
$productTpl->rabatt = round(100*(1-($inzahl/$product->price)));
//Formatierung der Preisangabe und berechnen des Rabattes
}
}

Auf diese Weise brauchen wir den Kunden in der Kunden-Datenbank für die Nettopreise freigeben und die entsprechende CSV-Datei auf den Server aufspielen.

Ich hätte gerne eure Meinung darüber, ob ich den Server bei, sagen wir mal 100 gleichzeitigen Anfragen verschiedener Kunden auf verschiedene CSV-Dateien, in die Knie zwinge bzw. ob es eine elegantere Lösung für mich gibt.

[DominikJ]

Warum nicht einfach eine normale MySQL Datenbakn o.ä.?

[Saipan]

Zitat von DominikJ

Warum nicht einfach eine normale MySQL Datenbakn o.ä.?

Hallo,

na ja, das würde bedeuten eine Datenbank mit einer Größe von 1000 Spalten (für jeden Kunden) und über 22000 Zeilen zu erstellen. Dort immer die Aktualisierungen durchzuführen wäre doch sehr zeitaufwändig - wir brauchen jetzt schon sehr viel Geduld, um die Artikeldatenbank mit den Bruttopreisen und dem Lagerbestand täglich aktuell zu halten. Letzteres geht über ein Script.

Natürlich wäre eine MySQL-Datenbank der "Beste" Weg, aber leider nicht praktikabel, auch weil dies jemand pflegen muss, der von PHP etc. keine Ahnung hat. "Nur" die richtige Datei auf den Server hochzuladen ist da nicht so Fehleranfällig.

[diver-network]

Hi "Saipan",

ich glaub', Du hast in Bezug auf Datenbanken im Allgemeinen etwas falsch verstanden.
Wenn Du die Datenbank korrekt entwirfst benötigst Du mit ziemlicher Sicherheit keine 1000 Spalten pro Kunden. Das haben selbst riesige Datenbanken in Großunternehmen nicht.

Kauf' Dir mal ein Buch über Datenbanken im Allgemeinen bzw. frag' einfach nach, wenn Du hier was wissen willst (Forum MySQL).

Zur Beantwortung von Fragen nach dem "besten" Datenbankdesign solltest Du nach Möglichkeit folgende Informationen liefern (wichtigste sind oben):
- Art der abzulegenden Information (Kundendaten, Artikeldaten) sowie eventuell Beispieldaten (fiktive!!)
- Welche der Informationen müssen immer gefüllt sein und welche können gefüllt sein
- Gibt es Informationen, die mehrfach für einen Datentypen gespeichert werden müssen. Z.B.: Kann es sein, daß der Kunde bei der Artikelgruppe Lebensmittel 10% Rabatt bekommt, bei Non-Food 15% und bei Getränken 12%, aber nur bei nicht alkoholischen?
- Erwartete Belastung der Datenbank (Abfragen pro Tag, davon wieviel Schreib- oder Leseoperationen)

HTH,

Andy

[Damir]

Also bei der Menge an Artikel etc. halte ich nichts von CSV. Auch das Argument das die Preise nicht konfortable eingepflegt werden koennen ist ein Irrtum. Wenn die MySQL-Datenbank (Artikel, Preise etc.) logisch aufgebaut wird, so ist es nachher auch kein Problem eine CSV-Datei direkt in die Datenbank einzulesen!!!!! Der Vorteil von MySQL liegt hier klar auf der Hand!!!!! Bei der Groesse, die du hier beschreibst kann ich nur, alleine de Sicherheit wegen, nur eine richtige Datenbank empfehlen!!!!!!!

Damir

[Saipan]

Hallo,

ich Danke euch für die bisherigen Meinungen. Würde ich diesen Weg als das nonplusultra sehen, hätte ich diesen Beitrag nicht eröffnet.

Zunächst einmal zur (erforderlichen) Datenbankgröße.

Es ist leider so, dass es über 22000 Artikel gibt und es so ist, dass jeder Kunde, von den über 6000 Kunden die wir haben gehe ich von aus, dass sich gut 1000 kurzfristig für diesen Shop anmelden, eigene Preise hat. Es gibt da leider keine "Logik", da habe ich mich natürlich vorher bei unseren Vertriebsmenschen durchgefragt.
Ihr müsst euch das so vorstellen, dass jeder Kunde für jede Artikelgruppe in eine Rabattgruppe eingeteilt wird, und dazu noch innerhalb dieser Artikelgruppen seine eigenen Sonderpreise hat. Letzteres erscheint ziemlich willkürlich und fern jedes logischen Zusammenhangs.
Dieses System ist in über 100 Jahren Firmengeschichte gewachsen und es sind viele, wirklich viele Vertriebsleiter daran gescheitert, dass System zu ändern/ zu vereinfachen. Es ist wie beim Subventionsabbau in Deutschland, die Lobbygruppen sind einfach zu stark.
Zurück zur Datenbankgröße. Jedem Kunden seinen Preis aufzuspielen bedeutet also 22000 (Artikel = Zeilen) * 1000 (Kunden = Spalten).

Natürlich kann ich ein entsprechendes Script schreiben, um die CSV-Datei entsprehend in eine MySQL-Tabelle zu schreiben - so etwas mache ich bereits, da wir auch täglich den im Shop angezeigten Lagerbestand aktualisieren.
Mir erschien als bekennender PHP-Anfänger und nichtsahnender, was die Möglichkeit von Datenbanken angeht, die Lösung über die CSV-Datei einfacher.

[Damir]

OK,

ich habe mal einen Kunden gehabt bei dem ich soetwas aehnliches vorfand - 300.000 Datensaetze, in 40 Jahren gesammelt;-) Es hat lange gedauert aber wir haben es hinbekommen. Nun gut, du wirst es erst einmal besser wissen.

Aber dennoch, MySQL kann ohne Probleme mit mehreren Millionen Datensaetzen spielend umgehen - denke auch daran, wie du dir damit die Arbeit erleichtern koenntest....

Damir

[diver-network]

Hi,

Zurück zur Datenbankgröße. Jedem Kunden seinen Preis aufzuspielen bedeutet also 22000 (Artikel = Zeilen) * 1000 (Kunden = Spalten).

hier hast Du was falsch verstanden: 22000 Artikel = 22000 Zeilen stimmt, 1000 Kunden = 1000 Spalten stimmt nicht!!!

Hier nimmst Du stark vereinfacht!! gesagt 3 Tabellen; in einer davon speicherst Du die Daten zu den Artikeln, in der zweiten die Daten zu den Kunden und in der dritten Tabelle speicherst Du die Beziehung zwischen Kunde und Artikel.
Bsp.:
[Tabelle artikel]
id artikel
1 Eis
2 Kakao
3 Kaffee

[Tabelle kunden]
id name
1 saipan
2 damir
3 diver-network

[Tabelle artikel-kunden]
id artikel-id kunden-id
1 1 1
2 2 1
3 1 2
4 3 3

Über die Tabelle artikel-kunden bekommst Du jetzt raus, welcher Kunde Eis (saipan und damir) gekauft hat und welcher Kaffee (diver-network).

Bei jeder Bestellung gibt es nur noch einen weiteren Eintrag in der Tabelle artikel-kunden, die anderen Tabellen werden nur noch dann angepackt, wenn sich dort etwas ändert.
Die Anzahl der Spalten, die Du pro Tabelle benötigst, sowie die Anzahl der Tabellen hängt natürlich davon ab, wie gut Du die Datenbank normalisieren willst und wieviele Daten pro Artikel / Kunde Du ablegen musst.

Für eine Datenbank ist die Anzahl der Zeilen normalerweise kein Problem.

Versuch' einfach mal, Deine Kunden zu überzeugen, daß es sich auf Dauer lohnt, jetzt Geld in ein neues System zu investieren, als hinterher im absoluten Chaos zu landen, aus dem es keinen (billigen und schnellen) Weg mehr raus gibt.

Viel Glück,

Andy

[Saipan]

Zitat von diver-network

Hi,
Hier nimmst Du stark vereinfacht!! gesagt 3 Tabellen; in einer davon speicherst Du die Daten zu den Artikeln, in der zweiten die Daten zu den Kunden und in der dritten Tabelle speicherst Du die Beziehung zwischen Kunde und Artikel.
Bsp.:
[Tabelle artikel]
id artikel
1 Eis
2 Kakao
3 Kaffee

[Tabelle kunden]
id name
1 saipan
2 damir
3 diver-network

[Tabelle artikel-kunden]
id artikel-id kunden-id
1 1 1
2 2 1
3 1 2
4 3 3

Hallo,

ehrlich gesagt, so ganz verstehe ich es nicht.
So wie ich dein Beispiel verstehe, müsste ich jedem Kunden die entsprechende Preis-ID zuordnen.

Ich habe bereits zwei Tabellen:
[Tabelle artikel]
id artikel
1 Eis
2 Kakao
3 Kaffee

[Tabelle kunden]
id name
1 saipan
2 damir
3 diver-network

Deshalb müsste die 3. Tabelle so aussehen:

[Tabelle preis]
id | artikel | saipan | damir | diver-network
1 | Eis | 1,99 | 1,99 | 0,99
2 | Kakao | 2,99 | 4,99 | 1,56
3 | Kaffee | 3,99 | 3,66 | 2,99


Jedem Kunden ist für jeden Artikel ein Preis zugewiesen, ob er den Artikel jemals bekommen hat oder nicht. Ich kann die Tabelle Preis doch nur so anlegen, also ergibt sich die Tabelle 22000 Artikel * 1000 Kunden.

Es ist übrigens keine Frage der Datenbankkosten.

Es scheint also von den Profis niemand auch nur annähernd meinen Gedankengängen zuzustimmen, also werde ich die Anzeige mittels MySQL-Datenbank lösen. Kommt dann also die Frage, wie diese Datenbank aufgebaut wird, so wie mein obiges Beispiel oder nach einer "richtigen" Logik, bei der man wahrscheinlich viel Resource sparen kann..

[diver-network]

Hi,

die Verknüpfung von Kunde zu Artikel bekommst Du in meinem Beispiel über die dritte Tabelle artikel-kunden.
Wenn Du in dieser noch eine weitere Spalte "preis" aufnimmst kannst Du dort den kundenspezifischen Produktpreis für jede Kombination von Kunde/Artikel abspeichern.

[Tabelle artikel-kunden (neue Version)]
id artikel-id kunden-id  preis
1     1           1            1,99
2     2           1            2,00
3     1           2            1,00
4     3           3           10,00

Bitte beachte aber, daß mein Beispiel extrem vereinfacht ist und Du damit auf Dauer nicht weit kommen wirst!!

Ich rate Dir dringend zu folgenden Dingen:
- Kauf' Dir ein Buch über Datenbankdesign und SQL bzw. google mal nach entsprechenden Seiten im Internet. Möglicherweise findest Du sogar in der Wikipedia bzw. bei den Wikipedia Büchern schon Grundlagenartikel zum Datenbankdesign.

Nachdem Du Dir einen Überblick über die ""Technik"" des Datenbankdesigns verschafft hast solltest Du Dir die momentan bei Euch abgelegten Daten anschauen und grob in Gruppen zusammenfassen.
Sprich: Was gehört als Grunddaten zu einem Artikel (z.B. Name, Hersteller), was sind erweiterte Grunddaten (z.B. Verpackungsgröße, Lieferant) und wie oft kommen diese Daten pro Artikel vor (es wird nur einen Hersteller pro Artikel geben, aber sicherlich mehrere Verpackungsgrößen).
Du wirst dann relativ schnell feststellen, daß Du z.B. die Hersteller in eine separate Tabelle auslagern solltest, um diese Daten nur einmal pflegen zu müssen.

- Datenbankentwürfe von Dir solltest Du unbedingt (von Profis) kontrollieren lassen, bevor!! Du Dich an die Programmierung machst. Hierbei ist dann auch wichtig, daß Du Dir vorher Gedanken gemacht hast, welche Informationen Du aus der Datenbank wieder auslesen willst bzw. was eventuell noch als Nachforderung an die Datenbank kommen wird.
Erfahrungsgemäß wollen die Leute, wenn sie erst mal gesehen haben, was man mit einer Datenbank anstellen kann, sofort nach dem ersten Programm gleich noch mehr. Wenn dann die Datenbank nicht korrekt entworfen ist hat man als Programmierer dann ein Problem.

- Ist der DB Entwurf qualitätsgesichert solltest Du noch einmal in Bezug auf Performance drüber schauen lassen. Es macht nämlich manchmal Sinn, manche Daten über mehrere Tabellen per 1:1 Verknüpfung aufzuteilen, um bei Standardoperationen eine deutlich verbesserte Performance zu bekommen.

Also nochmal ganz deutlich die Bitte, vor einer Programmierung das DB Design kontrollieren zu lassen und nötigenfalls auch einen Profi einzustellen, der dies für Dich erledigt!!
Eine schlecht entworfene Datenbank kann fast genauso unpflegbar werden wie Deine bisherige Lösung mit *.csv Dateien.

Viel Glück,

Andy
(Edit: Tabelle hoffentlich deutlicher dargestellt)