Mailinglisten-Archive |
Hallo, ich will hier auch mal nock kurz meinen Senf dazu geben: 1. MySQL ist auch auf extrem großen Tabellen extrem schnell. Nur wie in jeder Datenbank gilt hier auch: Je mehr Datensätze in einer Tabelle sind desto länger die Zugriffszeiten. Ich habe hier z.B. eine Datenbank in der einige Tabellen 20-30 Millionen Datensätze haben und die Anwedung rennt wie das böse auf recht moderater Hardware. 2. Wenn wie in dem Fall die Daten vollkommen getrett sind ist auf jeden Fall zu überlegen ob man das je Kunde in eigene Tabellen packt. Ob nun in extra Datenbanken (sprich Verzeichnisse) oder nur in extra Tabellen in der gleichen Datenbank spiel da für MySQL keine Rolle. Über "Sicherheitsproblematiken" kann man streiten - ich sehe hier nicht wo eine Lösung besser ist als die andere. 3. Ein MySQL Server hat eine begrente Anzahl gleichzeitig offener Dateien (wenn es um MyISAM Tabellen geht). Hier könnte ein kleines Performanceproblem entstehen wenn hoch verteilte Zugriffe vieler Kunden erfolgen da dann erst Dateien geflusht und geschlossen werden müssen und andere geöffnet werden müssen. Aber es kommt zu keinen Problemen das nicht mehr geht ... der Server öffnet und schließt halt die Dateien nur ständig. -> Lösung falls das mal Eintritt: "kleine" Tabellen zusammenwerfen d.h. nur eine Tabelle für alle Kunden, große bzw. extrem große einzeln lassen d.h. pro Kunde eine Tabelle. Die JOIN's o.ä. muss man dann eben dynamisch zusammenbauen aber das ist ja in PHP kein Problem. Daher die Empfehlung: 1. Trennen der Daten je Kunde 2. Vorsorglich trotzdem in jede Tabelle ein Feld einbauen mit einer ID des Kunden wie wenn mehrer Kunden in einer Tabelle wären. -> Baut man die Anwendung so auf ist man für alles offen und kann jederzeit reagieren. Großen Mehraufwand macht das auch nicht. Gruß, Andreas
php::bar PHP Wiki - Listenarchive