ugrás a tartalomhoz

Adattáblák mennyisége egy adatbázison belül.

s_volenszki · 2007. Jún. 22. (P), 17.20
Sziasztok!

Szeretném megkérdezni, kinek van tapasztalata ebben a témában (Adattáblák mennyisége egy adatbázison belül.)?
Mennyit lehet létrehozni olyan táblából amiben átlagosan (táblánként) 100 rekord van?

Várom a véleményeiteket, üdv

s_volenszki
‹ Valami bajom van az auto_incrementtel Bejelentkezés és A felhasználó adatainak kiírása ›
 ■
1

Pontosan én sem tudom

Thomas · 2007. Jún. 22. (P), 17.53
Pontosan én sem tudom, de google a barátom. A találatok szerint úgy tudom 65536, de ez OS függő arról nem is beszélve, hogy tárhely is véges.

De azt hiszem, hogy komoly tervezési hibák sorozata vezethet oda, hogy "végtelen számú" táblát kelljen létrehozni úgy, hogy csupán 100 rekord legyen benne.
3

...tervezési hiba...

s_volenszki · 2007. Jún. 22. (P), 19.21
De azt hiszem, hogy komoly tervezési hibák sorozata vezethet oda, hogy "végtelen számú" táblát kelljen létrehozni úgy, hogy csupán 100 rekord legyen benne.


Amikor megnyitottam ezt a topikot, már akkor gondoltam, hogy ez a kérdés szinte mindenkiben az optimalizálatlanság gondolatát fogja felmeríteni.

Nos, ez nem így van. Ez egy automatikusan regisztrálható (zárt közösségen belül) webalkalmazás, amihez a jelenlegi szerveren csak az aldomaint tudom php-ből létrehozni, az adatbázisokat nem. Ezért aztán átalakítottam az alkalmazást, és egy adatbázison belül egy egyedi prefixel lát el minden táblát (az aldomain tábla id-je), így működhet szolgáltató váltás nélkül is.

Már gondoltam arra is, hogy összevonom a táblákat és inkáb átírom az alkalmazás adatbázis műveltetési rutinjait (minden táblába teszek +1 azonosítót, ami távoli kulcs az aldomaines táblából) és akkor elég egy garnitúra tábla, de ha elbírja a táblákat (kb 600-800db) akkor a távolabbi céloknak jobban megfelel (költözés olyan szolgáltatóhoz, ahol php tud adatbázist is létrehozni).

Ettől eltekintve vettem az adást, és szívesen fogadok további ötleteket :)

s_volenszki
4

lehet hogy sügér vagyok ehhez

Thoer · 2007. Jún. 22. (P), 20.07
,de abból amit leírtál, két eset ötlik fel elsőre:
1. szét akarod osztani a tárhelyedet és akik nálad regisztrálnának azok is létrehoznak új szolgáltatásokat és hozzá táblákat, ami minden csak nem épeszű megoldás és feltételezem nincs is így.
2. létrehozol szolgáltatásokat és azokat akarod felhasználóknak szétosztani, de akkor meg csak annyi tábla kell, amennyi kiszolgálja az általad létrehozott szolgáltatások adatbázisigényét, plusz kezeli a felhasználóidat. A felhasználókhoz meg hozzárendeled az aldomaint és nyilván a saját beállításaikat a te szolgáltatásodhoz.
5

Tökéletesen jól látod!

s_volenszki · 2007. Jún. 22. (P), 20.34
Szia!

A második variáció hajaz a legjobban a valóságra, és a soktáblásdi, csak azért játszana, hogy ha megszeretik a szolgáltatást és megfizetik, akkor kapnak mindenből sajátott, és a különálló táblákat egyszerűbb lenne átvinni a privát adatbázisukba.

Ellenben úgy gondolom, hogy valóban az lesz az optimális megoldás, ha egy subdomain tábla id-it hozzáadom az alkalmazás tábláihoz mint távoli kulcs, így egy garnitúra tábla elláthatja az összes aldomain kiszolgálását.

Köszi a véleményt, sokat segített.

s_volenszki
6

Jogosultságilag cink

janoszen · 2007. Jún. 22. (P), 20.57
Jogosultságilag kicsit cink a helyzet, nem tudom mit teszel elé, de problémás.

Különösen akkor van probléma, ha pl MySQL esetén InnoDB-t használsz, ugyanis a MyISAM motorral ellentétben itt az egész adatbázis egy fájlban tárolódik, tehát a filerendszer határokat szab. 2-3-4 giga... ami nem olyan sok... szolgáltatástól függ, de ezzel óvatosan.

Ha egy frontendet is adsz hozzá, akkor a dumb copy módszer helyett érdemes optimalizálni, ha meg saját adatbázist akarnak, akkor inkább copyzni, mint sem hogy állandóan esetleg lassú legyen a szolgáltatás.
7

Az alkalmazás jellege.

s_volenszki · 2007. Jún. 22. (P), 21.11
Olyan alkalmazás fut rajta, ami a látogatókat kizárólag olvasási jogosultsággal látja el, és egy adminisztrátor hetente egyszer módosítgatja a tartalmat. Egy olyan üzenőfal, ahova kizárólag a fal tulajdonosa írhat, a saját csoportjának fontos információkat. De valójában nem is üzenőfal, mert az adatstruktúra konstans, csak bizonyos hozzá tartozó paraméterek változnak. Mint egy étterem heti menüje.

s_volenszki
8

Akkor minek sok tábla?

janoszen · 2007. Jún. 22. (P), 21.31
Akkor minek sok tábla és dumb copy? Ezt egy táblából is meg lehetne oldani, nem kellene hozzá az overhead...
9

Gyanítom, hogy a webszolgáltatók

Thoer · 2007. Jún. 23. (Szo), 00.24
többségével meg lehet dumálni hogy bizonyos összegért újabb adatbázisokat biztosítsanak ha már kezd kritikussá válni az adatbázis mérete...
10

...tudok új adatbázist csinálni...

s_volenszki · 2007. Jún. 23. (Szo), 07.37
Az adatbázis létrehozásával nincs semmi gond. Van 4GB tárhelyem és annyi site-ot és adatbázist hozok létre amennyit csak akarok. A probléma az, hogy az aldomaint létre lehet hozni php-vel, de az adatbázist csak az admin felületről! Ezért kell bekényszeritenem a rendszert egy adatbázisba. Automatikusan leregisztrálható, (létrejön az álltala kiválasztott aldomain) és ha bebizonyosodik a regisztrálónak az alkalmazás használati értéke, akkor megfelelő összegért .hu-s domain alá és saját adatbázisba költöztetem (manuálisan).

De valóban egy garnitúra táblával kell megoldani (így logikus), hiszen ha költözésre kerül a sor, mysql-ben tudok exportálni szűrési feltétel eredményét is.

Köszönöm a hozzászólásokat.

s_volenszki
2

Nekem nincs tapasztalatom

Thoer · 2007. Jún. 22. (P), 17.57
,de csodálkoznék ha akár 1000 tábla gondot okozna egy adatbáziskezelő rendszernek. A fontosabb kérdés, hogy miért lenne ilyen sok táblára szükséged?
11

mindenféle

Hodicska Gergely · 2007. Jún. 23. (Szo), 11.28
Amikor megnyitottam ezt a topikot, már akkor gondoltam, hogy ez a kérdés szinte mindenkiben az optimalizálatlanság gondolatát fogja felmeríteni. Nos, ez nem így van...
De. :) Rossz oldalról fogod meg a problémát. Azért mert azt hiszed, hogy nem tudod PHP-ból megoldani a létrehozást, attól még nem az a jó megoldás, hogy elmész egy rossz kialakítás fele. Legrosszabb esetben is simán le tudod programozni, hogy PHP-ból az admin felületen keresztül hozz létre DB-t (Snoopy, Curl stb.). Mondjuk nem ezt gondolnám a legrobosztusabb megoldásnak, de adott esetben megteszi. Ha a szolgáltatód egy kicsit is nyitott, akkor viszont megbeszélhetnéd velük, hogy futassanak egy CRON scriptet, aminek valamilyen formában jelezni tudod, hogy hozzon létre egy adott nevű DB-t, meg hozzá a megfelelő usert. Ez történhet úgy, hogy leteszed egy meghatározott fájlba az ehhez szükséges adatokat.

Már gondoltam arra is, hogy összevonom a táblákat és inkáb átírom az alkalmazás adatbázis műveltetési rutinjait (minden táblába teszek +1 azonosítót, ami távoli kulcs az aldomaines táblából)
Ha a DB teljesen el van fedve a userek elől, tehát ők sosem tudnak konkrét queryket futtatni, akkor ez jó megoldás lehet, ha igen, akkor gond lehet, hogy hozzáférhetnek egymás adataihoz.

Jogosultságilag kicsit cink a helyzet, nem tudom mit teszel elé, de problémás.
Lásd fenti pont, ha az nem teljesül, akkor nincs jogosultság para.

Különösen akkor van probléma, ha pl MySQL esetén InnoDB-t használsz, ugyanis a MyISAM motorral ellentétben itt az egész adatbázis egy fájlban tárolódik
Vagy nem. ;) http://dev.mysql.com/doc/refman/5.0/en/multiple-tablespaces.html


Üdv,
Felhő