MySQL-DB, 100MB frei, wie viele Einträge speichern?

[TheMiller]

Hey,

nochmal eine Frage zu SQL. Ich habe eine DB bei 1&1 mit 100MB. Jetzt wollte ich für jeden Monat eine Tabelle machen, da ich alles nach Datum sortiere. Ist es vielleicht klüger, alle Daten in eine Tabelle einzutragen und dann eine Abfrage nach Monat zu machen?

Ich weiß nicht, ob sich alles stark verlangsamt, wenn sehr viele Einträge in der Tabelle sind. Ich schätze mal, es werden mehr als 2000 Einträge im viertel Jahr. Und wenn ich alles in einer Tabelle habe, ob dann die Zugriffs,- bzw. Abfragezeiten länger werden?

Danke im Vorraus

[alcaeus]

Hi DJ-SPM,

es kommt eigentlich hauptsächlich auf das Query an, mit dem du auf die DB zugreifst. Weiters kannst du z.B. durch Indizes die Geschwindigkeit beim Suchen merklich erhöhen.
Und wenn du dir die Datenbankgröße der DP ansiehst (351,97 MB), dann kommst du mit deinen 100 MB auch lange aus.

Greetz
alcaeus

[TheMiller]

Cool, danke.

Wenn wir gerade dabei sind: Was sind Indizies, bzw. wie erstelle ich die? Ist doch so eine Art Cache oder so. Bei NT kann man doch auch Dateien indizieren, oder?

[clues1]

1. 100 MB sind extrem viel für 2000 einträge. Was für informationen speicherst du sonnst können wir dir nicht helfen. -> Genaue Angabe mit Datentyp <-
Sonnst kann ein Eintrag 1 Byte oder ein eintrag 1 MB verbrauchen.
Wenn due keine Binären Daten (Images/Blobs usw) speicherst, dann kannst du davon ausgehen das erst ab 20000000 Einträgen die Performance langsam ab geht. Siehe das Forum, schätze mal so 500 MB DB und davon rund 100000 Einträge. Aber recht viele Bilder, Dateien und vorallem Viel Viel Text.
Mhhh das waren 1000 Zeichen = 1KB nur mein Beitrag :shock:

[clues1]

Indezies sind Indexe die du auf eine Spalte legen kannst. Das wird extra gespeichert und die Datenbank kann schneller nach den Daten Suchen.

Tipp: Lies dir Dokumentationen und Referate über Datenbanken durch.

[TheMiller]

Naja, ich speichere nur Daten. Ein Datensatz ist ca 220 Zeichen lang und da ist sogar noch viel Luft zum Schreiben drin. Aber dann ist ok.

Ich speichere nur Text. Keine Bilder, kein garnix. Text!

Vielen Dank!

[alcaeus]

Zitat:

Zitat von DJ-SPM

Ein Datensatz ist ca 220 Zeichen lang und da ist sogar noch viel Luft zum Schreiben drin.

Na das sind inkl. overhead ca. 250 Bytes pro Datensatz. Macht 2 MB pro Jahr. Also mach dir mal keine Sorgen ;)

Greetz
alcaeus

[TheMiller]

:lol:

Gut! Danke!

[czapie]

BTW:
Indizes sind künstliche Schlüssel, die dazu dienen, dass du jeden Datensatz in einer Tabelle eindeutig identifzieren kannst.

[clues1]

@czapie
Ist falsch. Primär Schlüssel sind Künnstliche Schlüssel zu eindeutigen Identifizieren. Ein Primärschlüssel kann aber auch ein Indiz (Index) werden, Dadurch können Daten in diesem Feld schneller gefunden werden.

[CenBells]

Also,

jetzt will ich meinen Senf zum Index auch noch zu geben. ;)

Ein Index speichert die Reihenfolge von Datensätzen nach den angegebenen Kriterien. Dabei werden nicht die echten Datensätze sortiert gespeichert, sondern nur eine Referenz auf die Datensätze.
Stell dir vor, du hast 1000000 Datensätze mit jeweils 20 Attributen. Die Daten werden (wie im richtigen Leben) unsortiert eingetragen und nun suchst du ausgerechnet nach dem Datensatz, der als letztes eingetragen wurde. Da kein Index vorhanden ist, muss das DBMS einen sogenannten Tablescan durchführen. D.h. jeder DS wird vom Speichermedium(Festplatte) geholt und gegen deine Suchkriterien verglichen. Das heißt du hast etwa 1000000 lese Operationen, was entsprechend belastend ist.
Bei einem geeigneten Index, wird vorher berechnet, wo der DS liegt und dann kann der Datensatz mit nur wenigen leseoperationen (im besten Fall genau eine) von der Festplatte geholt werden. Das bedeutet, hier findet nur die Berechnung der "Position" und etwa ein gezieltes Auslesen statt => Schneller.
Natürlich muß der Index bei jeder Einfügen-Op aufgebaut werden, daß belastet das System aber in der Regel nicht sehr stark.

Gruß
Ken

[Jelly]

Zitat:

Zitat von CenBells

Bei einem geeigneten Index, wird vorher berechnet, wo der DS liegt und dann kann der Datensatz mit nur wenigen leseoperationen (im besten Fall genau eine) von der Festplatte geholt werden. Das bedeutet, hier findet nur die Berechnung der "Position" und etwa ein gezieltes Auslesen statt

Zur Korektur, weil das so noch nicht ganz stimmt. Indizes werden eben gerade nicht unsortiert gespeichert, sondern eben sortiert. Und dadurch lässt sich ein Datensatz eben schneller finden, was meines Achtens einen Unterschied ist zu "gezielt" finden.

Gruß,
Tom

[clues1]

Genau. Fazit, Alle 3 Posts Zusammen = Indizes ;D.

[CenBells]

Zitat:

Zitat von Jelly

Zur Korektur, weil das so noch nicht ganz stimmt. Indizes werden eben gerade nicht unsortiert gespeichert, sondern eben sortiert. Und dadurch lässt sich ein Datensatz eben schneller finden, was meines Achtens einen Unterschied ist zu "gezielt" finden.

Hi,

die speicherung des index ist sehr wohl sortiert, wie du auch gesagt hast ;)
Ich wollte auch ncihts anderes ausdrücken. Die berechnung der position war missverständlich ausgedrückt. Es wird natürlich nur auf den index zugegriffen. Bei b-bäumen / b*-bäumen wird vom wurzelknoten ausgegangen, der eintrag mittels einer "suche" ermittelt und dann wird mit der referenz der datensatz ausgelesen. Es findet aber weiterhin eine suche statt, weil ja erstmal geschaut werden muss, welcher eintrag nun dem gesuchten ds entspricht.
So oder so ähnlich ;)

Gruß
kEn