hi, ich soll (habe schon etwas ahnung für normalgebräuchliche Mysql DBs) eine struktur erstellen für folgendes: Unser intranet hat eine tägliche auswertung voon verkauften produkten, die db wird täglich von mehreren usern abgerufen, beinhaltet circa 700 000 datensätze, die täglich mehr werden. wie kann ich eine gute struktur anlegen gleich von vornherein: beinhalten wird sie ID und ARTIKEL
Borlander 
pipolino „Wie erstelle ich eine gute DB Struktur für große Datensätze“
Also ein bisschen konkreter musst Du schon werden...
fnmueller1 pipolino „Wie erstelle ich eine gute DB Struktur für große Datensätze“
also für wirklich grosse DBs ist MYSQL nicht gut geeignet. Dann schon lieber MSSQL oder - wenn die Hardware stimmt - Oracle. Aber wie borlander schon geschrieben hat wären mehr infos echt hilfreich.
xafford fnmueller1 „also für wirklich grosse DBs ist MYSQL nicht gut geeignet. Dann schon lieber...“
Was ist in deinen Augen eine wirklich große DB? Ich kenne MySQL-Installationen mit zig Millionen Einträgen. Wo es bei MySQL wirkich kritisch wird sind BLOB-Felder in Datenbanken, hier geht die leistung rpide runter. Ebenso disqualifiziert sich MySQL bei komplexen Afragen mit Subselects und bei anderen weitergehenden Features wie Trigger und Stored Procedures.
700.000 Datensätze sind für MySQL (besonders wenn man es etwas tunt und nicht in Standardeinstellungen laufen lässt) wirklich ein Klacks (allein die ChatDatenbank hatte schon über 500.000 Einträge).
Zur Originalfrage: Das kann mit den wenigen Angaben in keinster Weise beantworten, dazu braucht man wesentlich mehr Details wie z.B. alle Feldtypen, alle Abhängigkeiten, Funktionalität usw...
Allgemein kann man nur sagen, daß es von Vorteil ist eine Tabelle mit vielen Spalten, von denen nur wenige ständig in Benutzung sind in mehrere Tabellen aufzuteilen und Felder, welche für Abfragen benutzt werden mit Indices zu belegen. Möglichst auch (wenn in der Datenbank wenig gelöscht wird) starre Tabellenlayouts zu nutzen, wo möglich und sinnvoll. Und am Allerichtigsten bei der Arbeit damit: Bei JOINs über mehrere Tabellen nur Indexfelder zur Verknüpfung zu nutzen und die JOINs immer gut testen, falsche JOINs können 1.000 Mal so lange dauern wie ein gut durchdachter.
fnmueller1 xafford „Antwort“
natürlich trifft deine beschreibung auf die aktuelle situation zu, aber was ist wenn die DB in der Geschwindigkeit weiter wächst? Dann ist in 4-5 Jahren schluss mit lustig und dann muss man die ganzen Daten migrieren....
Ferner wird es performant schon heftig wenn man irgendwas dazugebaut wird und dann z.B. ein Tagesendprogramm durchläuft.
xafford fnmueller1 „Antwort“
Das mußt Du mal den Leuten on Wikipedia erklären, die scheinen das noch nicht zu wissen, am Ende kommt deren MySQL nicht mehr mit den Einträgen klar, wenn Wikipedia mal richtig viele Einträge hat.
Vielleicht würde Dir etwas Lektüre zum Thema MySQL und MaxDB guttun, bevor Du solche Urban Legends verbreitest, MySQL ist unter anderem auch Clusterfähig und kann es in Punkto reiner Geschwindigkeit im Bereich Relationaler Datenbanken durchaus mit Oracle oder DB2 aufnehmen, so lange keine großen BLOBs oder zu komplexe JOINs gebraucht werden. Hat man also beim Anwednungsdesign ncht geschlampt muß die Datenbank höchstens innerhalb der Datenbankersionen migrieren, oder wenn ein durchgekanllter BLWer meint, die Firma bräuchte unbedingt Oracle.
fnmueller1 xafford „Antwort“
ok, ich lerne immer gerne dazu.
Ich kann mich nur noch sehr gut an MySQL Probleme in der Firma errinern die mit MSSQL verschwanden. Aber da wir die implementation auch eher Flickwerk, da dort auch alte Daten portiert wurden.
Auf jedenfall war bei und MySQL auch auf unvermurksten Installationen deutlich schlechter bei komplexen Berechnungen und vergleichen als MSSQL.
xafford fnmueller1 „Antwort“
MySQL hat seine Eigenarten, z.B. nutzt eine Standainstallation viel zu wenig Arbeitsspeicher, das ist zwar auf Webservern als Shared Host eher von Vorteil, bei einem reinen Datenbankserver jedoch weniger. MySQL auf Windows ist auch icht unbedingt mittel der Wahl. Weiterhin ist MySQL auch kein Vorbild in Punkto SQL-standardkonf_ormität und hatnoch andere Egenarten, gerade einen JOIN über zwei oder mehr Tabellen kann man sich teuer erkaufen, wenn der JOIN nicht getestet (gebencht) wurde.
Weiterhin ist es auch eine Frage des Tabellenypes den man nutzt, meist kommt nur MyISAM zur Verwendung, was auch nciht immer die beste Wahl ist. Dann noch fehlende Stored Proceures und Trigger...wenn man z.B. auf DB2, MSSQL, Oracle wechselt und die Datenbank umbaut, daß diese Feature genutzt werden können (wenn an sie denn braucht) ann man schon durchaus Probleme beseitigen, dann hat man aber schon bei der Datenbankwahl am Anfang des Projektes einen Fehler gemacht. Auch beim Layout der tabellen muß man aufpassen, da man für Indices vollkommen selbst verantwortlich ist.
Letztendlich gibt es aber noch zig andere Möglichkeiten warum in diesem Fall MSSQL besser lief als MySQL, bei rein flachen Datenbankdesigns ist MySQL in Punkto Geschwindigkeit jedoch durchaus an der Spitze anzusiedeln, man muß nur seine Grenzen kennen und aktzeptieren.
