Wie gross kann eine Tabelle (sql) werden? welche Auswirkung?

[Karstadt]

Hallo. Ich speichere pro Datensatz ein Bild 100x100 in JPEG format ab. Nun habe ich 404 Datensätzen die Tabelle ist ca. 1,4 mb Groß.

Mit Select werden nur maximal 40 Datensätze angezeigt, nun ist die Frage was würde passieren, wenn ich 10.000 Datensätze mit Bildern haben werden. Arbeitet mein Programm langsamer oder genau so "schnell" wie jetzt, da durch die Select Abfrage nur maximal 40 Datensätze "übertragen" werden?

[Tubos]

Wenn du mit deiner Abfrage nur 40 Datensätze auswählst, werden auch nur die 40 übertragen.

[Angel4585]

ich denke er meint ob es länger dauert 40 Datensatze zu laden wenn 10.000 Datensaätze da sind, als wenn nur 100 da sind... :roll:

[mkinzler]

Für dein Programm düften sich keine Änderungen ergeben. Es ist eher die Frage wie der MySQL-Server regiert. Aber eigentlich sollten sich dann auch keine größeren Probleme ergeben.

[Karstadt]

Danke für die schnelle Antwort! ;)

[alcaeus]

Ich hab eine mySQL-Tabelle, die ca. 1507 MB an Daten enthaelt, davon gehn ca. 693 MB fuer den Index drauf, der Rest sind die Daten an sich (das ist keine Tabelle im Produktiveinsatz, nicht dass mir jetzt jemand da dummes DB-Design vorwirft, das ist mehr ein Feldversuch).
In der Tabelle stehn Log-Daten vom Apachen, die ich schon in die einzelnen Felder aufgeteilt hab.
Folgendes Query:

SQL-Code:

SELECT DISTINCT log_useragent FROM log_data ORDER BY log_useragent

braucht auf meiner Maschine (Celeron mit 1.8 GHz, 512 MB Ram) ca. 7 Minuten zum Durchlaufen, was kein Wunder ist, bei den 3.6 Millionen Datensaetzen die da drin liegen. Das Feld ist momentan noch nicht normalisiert, deswegen sind da auch so viele Daten drin. Wie gesagt, war eigentlich ein dummer Feldversuch, dessen Reste zufaellig noch rumliegen :stupid:

Ab wann du eine deutliche Verlangsamung feststellst, ist natuerlich fraglich, aber irgendwann wird die Tabelle merlich langsam, vor allem wenn du die Indizes nicht richtig erstellst.
Mein Tipp: speicher das Bild im Dateisystem, und speicher nur den Pfad dazu. Das Auslesen der Daten, und auch das Anzeigen des Bildes werden viel weniger Speicher und weniger Rechenaufwand benoetigen :)

Greetz
alcaeus

[Karstadt]

Zitat:

Mein Tipp: speicher das Bild im Dateisystem, und speicher nur den Pfad dazu. Das Auslesen der Daten, und auch das Anzeigen des Bildes werden viel weniger Speicher und weniger Rechenaufwand benoetigen

..der Kunde möchtet.. alle Bilder und dazugehörige Daten in eine Tabelle habe. (40 Datensätze)
..Die Daten später in Report anschauen / ausdrucken.. (in diesen Fall kann ich nicht alle Bilder > 2MB auf 100x100 verkleinen das kann dauen, wennd die Bilder auf dem Server liegen...)
..Fall ein bild auf der Platte verloren geht, kann man (auch wenn das bild klein ist) nachvolziehen was das für ein bild ist.


es sprechen viele Gründe dagegen, warum ich in meinen Fall das nicht machen kann. :(

[mkinzler]

Muß es MySQL sein? Andere DBMS haben weniger Probleme mit vielen DS.

[Karstadt]

..ich habe momentan keine Probleme... wollte aber nur in voraus wissen.. aber so wie das aussieht würde es ja keine Probleme geben :) oder?

[alcaeus]

Zitat:

Zitat von mkinzler

Muß es MySQL sein? Andere DBMS haben weniger Probleme mit vielen DS.

Auch mySQL hat keine Probleme bei vielen DS. 10k Datensaetze ist weit unter dem, was mySQL schafft. Wichtig ist nur, die Queries daran anzupassen. ;)

Greetz
alcaeus

[alzaimar]

Zitat:

Zitat von alcaeus

Zitat:

Zitat von mkinzler

Muß es MySQL sein? Andere DBMS haben weniger Probleme mit vielen DS.

Auch mySQL hat keine Probleme bei vielen DS. 10k Datensaetze ist weit unter dem, was mySQL schafft. Wichtig ist nur, die Queries daran anzupassen. ;)

'Queries' muss man nicht anpassen, aber Indexe (oder Indizes, je nach sprachlicher Vorliebe). Und eventuell 'On demand fetching': Bilder werden nicht grundsätzlich geladen, sondern z.B. nur auf Aufforderung. Man sieht die normalen Daten, aber die relativ großen Bilder erst nach Button-Klick. Es wäre auch denkbar, ein Thumbnail, eine verkleinerte Version (2-10k) mit abzuspeichern, und beim Browsen zunächst die Mini-Version anzuzeigen.

Ach ja, und 10.000 Records ist wirklich 'Pille-Palle'. Sagen wir, bei 100.000.000 wird es interessant, obwohl auch das mit jedem mittelmäßgen DBMS zu handeln ist. Wichtig ist wirklich nur, das man die Spalten, nach denen man suchen will, mit einem Index versieht.

Aber eins bleibt: mySQL is nix, nimm lieber Firebird oder MSDE (MSSQL 2005 Express). Kostnix und ist schneller und sicherer. Aber das ist ein anderes Thema.

[alcaeus]

Ja, das meinte ich eigentlich - gute Index-Vergabe und auch das Auswaehlen von gewuenschten Spalten gehoeren fuer mich dazu ;)

Ob mySQL ein "gutes" DBMS ist oder nicht will ich jetzt nicht diskutieren ;)

Greetz
alcaeus

[Bernhard Geyer]

Zitat:

Zitat von alzaimar

Aber eins bleibt: mySQL is nix, nimm lieber Firebird oder MSDE (MSSQL 2005 Express). Kostnix und ist schneller und sicherer. Aber das ist ein anderes Thema.

Beweise das FireBird oder MSDE schneller oder sicherer sind?
Was ich sagen kann ist das der MS SQL-Server sich dynamischer an die DB-Größe anpasst wo man bei MySQL schon mal an den Ini-Dateien herumfummeln muss (Buffergrößen etc. um eine gute Performance bei großen DB's zu bekommen). Dafür ist es die zurückhaltenstes DB die ich kenne. Oracle schnappt sich in der Default-Installation soft allen verfügbaren speicher, MS SQL erst wenn es ein muß aber behält ihn dann und MySQL kann man schon bei der Installation angeben ob es sparsam mit Ram sein soll da der Rechner noch für was anderes gebraucht wird.

[alzaimar]

Zitat:

Zitat von Bernhard Geyer

Beweise das FireBird oder MSDE schneller oder sicherer sind?

MySQL im schnellen Modus fahren, Daten einfügen, Stecker ziehen. Dann die "Crashrecovery" genießen. Ist wie Lotto.