große anzahl mysql-db zu fairem preis

[makaio]

n'abend!

ich bin gerade dabei eine db-struktur für ein kleineres projekt zu entwerfen. da ich mit regionalen inhalten zu tun habe, halte ich es für am sinnvollsten die gleiche tabellenstruktur auf mehrere datenbanken zu verteilen, um so ganz streng nach region zu unterteilen und so zum bsp. auch sie rechenzeiten bei suchen (die regelmäßig durchgeführt werden sollen) einzuschränken.

insgesamt kämen anfänglich wohl so an die 20 db zusammen, es könnten auch noch mehr werden. mein provider verlangt allerdings  0,50/Monat pro zusätzlicher db (und damit scheine ich im vergleich zu manch anderem auch noch recht gut dran zu sein).

kann jemand einen (möglichst günstigen) provider empehlen, bei dem diese variablen kosten nicht anfallen?

bei der gelegenheit kann mir vielleicht auch mal jemand erklären, worin solche zusatzentgelte für extra-db begründet sein sollen. ich sehe das nämlich nicht ganz gerechtfertigt, dürfte doch nicht mehr als ein standard-skript zum anlegen sein.

tia,

matthias

[Alex]

Hallo,

villeicht wäre es eine gute Lösung wenn du dir einen eigenen Server anschaffst die gibst schon ab 10/monat und da kannst du drauftun was du willst.

Alex

[Philipp Hasenfratz]

Halihallo makaio

ich bin gerade dabei eine db-struktur für ein kleineres projekt zu entwerfen. da ich mit regionalen inhalten zu tun habe, halte ich es für am sinnvollsten die gleiche tabellenstruktur auf mehrere datenbanken zu verteilen, um so ganz streng nach region zu unterteilen und so zum bsp. auch sie rechenzeiten bei suchen (die regelmäßig durchgeführt werden sollen) einzuschränken.

Nein! Du verfolgst den falschen Ansatz. Wenn jede Tabelle "regionabhängig" ist, dann
setze in jeder Tabelle ein Attribut für die Region und setze einen INDEX darauf, sodass
die Datensätze schnell gefiltert werden können. Eine Trennung auf mehrere Datenbanken
macht _nie_ Sinn, weil jede Datenbank ein "kleines Weltbild" abbildet. Nicht die Region
ist so ein Weltbild, sondern dein ganzes Projekt.
Verwende für dein Projekt _eine_ Datenbank (können unter ganz wenigen Umständen auch
mehrere sein, aber das ist in deinem Fall IMHO nicht der Fall).

Die regionalen Daten auf mehrere Datenbanken/Tabellen zu verteilen bringt dir keinen
wesentlichen Performancevorteil; es bringt dir eine unglückliches Datenkonzept, welches
oftmals das Scheitern des Projektes nach sich zieht.

Ganz nebenbei: Wenn du schon mehrere Tabellen für _denselben_ Datentyp verwendest, so
könntest du auch mit Prä- oder Suffixen arbeiten. (eg. region_badenwuertemberg_user).

Viele Grüsse

Philipp

[makaio]

Wenn jede Tabelle "regionabhängig" ist, dann
setze in jeder Tabelle ein Attribut für die Region und setze einen INDEX darauf, sodass
die Datensätze schnell gefiltert werden können.

das attribut für die region ist schon vorhanden, aber an das indexing daran hatte ich noch nicht gedacht...

Die regionalen Daten auf mehrere Datenbanken/Tabellen zu verteilen bringt dir keinen
wesentlichen Performancevorteil; es bringt dir eine unglückliches Datenkonzept, welches
oftmals das Scheitern des Projektes nach sich zieht.

so drastisch würde ich es nicht sehen, insbesondere wenn die tabellenstrukturen exakt gleich sind sollten sich alle datenbanken bei bedarf zusammenfügen lassen.

Ganz nebenbei: Wenn du schon mehrere Tabellen für _denselben_ Datentyp verwendest, so
könntest du auch mit Prä- oder Suffixen arbeiten. (eg. region_badenwuertemberg_user).

das wäre auch mein alternativer ansatz gewesen. aber ich denke mal das indexing macht mehr sinn.

matthias

[Alex]

Hallo,

was bedeutet denn dieses INDEX (und Primary und Volltext) ich finde da irgendwie nicht die richtige seite im Internet wo das steht.

mfg
Alex

[Philipp Hasenfratz]

Halihallo Alex

was bedeutet denn dieses INDEX (und Primary und Volltext) ich finde da irgendwie nicht die richtige seite im Internet wo das steht.

http://forum.de.selfhtml.org/archiv/2003/2/37129/#m203533 (kurz über google
gefunden)
google: http://www.google.ch/search?hl=de&ie=UTF-8&oe=UTF-8&q=Datenbank+Index+Performance&meta=
http://www.mysql.com/doc/en/MySQL_indexes.html
http://www.mysql.com/information/presentations/presentation-oscon2000-20000719/index.html
(s. Topic: "Optimizing disks". Für Speicherverbrauch und Seek-Requests [je mehr, desto
schlechter die Performance])

Eine anschauliche, gute und einführende Beschreibung kenne ich z.Z. leider nicht.

Viele Grüsse

Philipp

[Alex]

Hallo,
danke erstmal, schade das es keine Anleitung für dumme gibt ;-)
Also ich habe ein Board gemacht in der einen Tabele stehen die Überschriften .... und in der andern die Beiträge.
In beiträge gibt es ID = die auto_increment id
haup_t die id aus der überschriften Tabele
Autor
und beitrag
..
.

Wäre es da auch gut irgendwo ein INDEX zu machen.
Villeicht kappiere ich es ja mit so einem beispiel besser.

mfg

Alex

[Philipp Hasenfratz]

Halihallo Alex

Also ich habe ein Board gemacht in der einen Tabele stehen die Überschriften .... und in der andern die Beiträge.

Da diese Tabellen oft gejoined ("verbunden") werden, empfiehlt sich ein Index/Unique auf
die Attribute ("Spalten") über die verbunden wird (Primary Key und Foreign Key,
namentlich haupt_t (in der Tabelle Beitrag) und id (in der Tabelle Ueberschriften)).
Da bei einer MySQL-Datenbank (du verwendest diese?) der Unique-Index auf dem
Primary Key automatisch gesetzt ist, brauchst du nur noch einen Index auf den Foreign Key
zu legen (das wäre das Attribut haupt_t aus der Tabelle "Beitrag").

Wäre es da auch gut irgendwo ein INDEX zu machen.

Zu dem, was ich aus deiner höchst unvollständigen Angabe einer Tabellenstruktur entnehmen
konnte, habe ich dir oben den Tipp gegeben. Für weitere Optimierungen _musst_ du uns
mehr sagen, denn raten wollen wir nicht und wissen können wir nicht.

Villeicht kappiere ich es ja mit so einem beispiel besser.

Glaube ich weniger, aber was verstehst du noch nicht? - Hast du das verlinkte Posting
von Sven gelesen?

Viele Grüsse

Philipp