ugrás a tartalomhoz

Táblák száma egy adatbázisban

Ronyn · 2007. Júl. 19. (Cs), 12.50
Üdv))
Azt szeretném kérdezni,hogy van-e valami(akár elméleti) maximum a táblák számára vonatkozóan,egy adott adatbázisban,illetve hogy használhatóság,teljesitmény szempontjábol melyik a jobb megoldás:kevesebb,nagyobb méretű tábla,vagy több,de kisebb tábla,illetve hogy mennyi táblát érdemes emiatt egy adatbázisban létrehozni?
Jelenleg nálam kevés,nagyobb tábla van(persze,ezek sem igazán nagyok))),és különféle "jelzőértékek" (cim,PHP_SELF,etc) szerint kérem le az adatokat,(Az adatok nem tartoznak össze...
Például egy vendégkönyv,ami több példányban futtathato)
Viszont, ha teljesen szétszedem az adatokat,külön táblákba,akkor,-adott esetben-nagyon sok tábla kelhet...
Köszi a válaszokat)
‹ saját php session engine Baromi nagy segítség kellen! Adatbázis költöztetés. ›
 ■
1

Szvsz

tiny · 2007. Júl. 19. (Cs), 13.18
Bár még sosem próbáltam ki, de szerintem a legtöbb időt két tábla csatolásával veszítesz. Szóval ha lehet, egy lekérdezéshez egy tábla tartozzon. Legalábbis érzésre. Szerintem csinálj egy progit, ami kiírja a lekérdezések idejét és kisérletezgess...
2

Uhhh

janoszen · 2007. Júl. 19. (Cs), 13.35
Na ez így nagyon rossz filozófia. Tény és való hogy két tábla csatolásából időt veszítesz, de erre valók a view-k. Ha viszont már csak néhány mező kellene a táblából akkor a gigászi oszlopszámodat végig kell lapozni. Ráadásul az adatbázisod kaotikus lesz nem is olyan sok idő után.

Elméleti maximum nincs, gyakorlati van és olyat nem érdemes csinálni, hogy egy PHP program dinamikusan csinál táblákat, mert az halál, akkor valami nagyon nagy tervezési gubanc van.
3

Nincs osszekapcsolás

Ronyn · 2007. Júl. 19. (Cs), 14.18
Nem lenne összekapcsolás(join vagy ilyesmi),szoval mint irtam,az adatok(táblák) függetlenek egymástol,és egy adott lekérés mindig csak egy táblâra irányul.
Olyanra gondolok,hogy pl.egy tobb helyre beillesztett vendégkönyv(include),ahol eddig egy táblában volt az összes hsz,és a php_self alapján lettek lekérdezve az adott vk.-hoz tartozo hsz.-ok.
Vagy például egy forumnál,hogy érdemes,minden topic külon táblába,vagy,forumonként(témánként) egy táblába rakni a topicokat?
Előbbi esetben,persze a rendszer hozná létre a táblákat...
Utobbi esetben viszont egy tábla tul nagyra nőhet...
4

Nem

janoszen · 2007. Júl. 19. (Cs), 14.32
Egyértelműen hibás döntés lenne a topiconként külön táblába tenni a hozzászólásokat, mert pl. nem tudsz topicokat átfogó keresést csinálni. Ezek az adatbázisok pont arra lettek kitalálva, hogy ilyen jellegű dolgokat megcsináljanak.
5

Tábla mérete?

Ronyn · 2007. Júl. 19. (Cs), 14.50
Értem,de igy viszont idő után elég nagyra nőhet a tábla...
Szoval meddig(mekkora táblaméretig) éri meg egy táblában tárolni?
10

Felhasználás módjától függ

zila · 2007. Júl. 19. (Cs), 16.58
Hogy belassul-e egy lekérdezés pusztán attól, hogy sok rekord közül kell kiválasztania keveset? Ha jól van indexelve akkor jópár milló rekord is lehet benne, nyilván lehet optimalizálni, kérdés mit tud a db? Particionálhatod a tábláidat mondjuk dátum szerint (évente, havonta), használhatsz cache-t, optimalizálhatod a lekérdezéseidet, normalizálással/denormalizálással is lehet játszani, statisztikai adatokat lehet külön táblában aggregálni, nem kurrens tétel rekordokat meg átpakolni egy másik táblába (archiválás céljából), ez mehet lassabb diszkre stb. Tehát a lehetőségek és választott megoldások az alkalmazás módjától, a használt adatbázis kezelőtől, hardware képességeitől stb. függnek. Vagyis kérdésedre nincs egyértelmű válasz :)
6

Gigászi oszlopszám :)

tiny · 2007. Júl. 19. (Cs), 15.28
Eddig nem láttam kárát, de természetesen én sem "gigászi oszlopszámra" gondoltam.
7

Indexelés csodákra képes

thekingr · 2007. Júl. 19. (Cs), 15.40
A gigászi bejegyzések igen időigényesek tudnak lenni bár erre találták fel az indexelést. Nemrégiben volt egy olyan projectem ahol több ezer felhasználó több ezer rendeléseivel kellett megbírkóznom. Na ekkor jutottam el arra a szintre hogy kicsit belemerülünk az indexelés csodáiba és utánaolvastam. Csodák csodájára az eddig több másodpercet igénybe vevő lekérdezés 1 másodperc alá szorult. Bár végeztem benne egy kis szédszedést is és JOINal kapcsoltam össze a dolgokat. Szóval ha ésszel indexelünk akkor amit keresünk gigászi bejegyzések után is még egy optimálisnak mondható 1 másodpercen belül hozzá tudunk férni a kivánt sorokhoz.
9

index

Ronyn · 2007. Júl. 19. (Cs), 15.55
Hmm,az indexelés valoban sokat segithet ilyen esetekben is,pl. a példa szerinti forumban a topicneveket indexelve...
8

Gigászi?

Ronyn · 2007. Júl. 19. (Cs), 15.45
De kérdés ,mennyi az a gigászi számszerüen, tapasztalatok szerint?
Gondolom a nagyobb projectek(phpbb,drupal) sem használnak sok kulon táblát,de mikortol tapasztalhato lassulás stb...
50ezer? 100ezer? 500ezer?
11

Sok...

tolmi · 2007. Júl. 19. (Cs), 18.01
4Gb RAM-mal egy kereskedelmi RDBMS elbírt 400 milliárd(400.000.000.000) rekorddal. Ennek környékén ment az 1mp-es lélektani kiszolgálási idő fölé egy bonyolultabb SELECT-tel. 400 milliárd rekord az már a sok rekord alsó határa(OLTP) - szóval a gigászi valahol arrébb van ;).
12

Meggyőző))

Ronyn · 2007. Júl. 19. (Cs), 19.38
Értem,ez elég meggyőző a táblaméretre nézve)))
13

OLTP?

Ronyn · 2007. Júl. 19. (Cs), 20.02
Hmm,ez mi is lenne?
20

Re: OLTP

tolmi · 2007. Júl. 20. (P), 17.46
On-Line Transaction Processing felhasználásra optimalizált RDBMS
16

nem minden esetben gubanc!

virág · 2007. Júl. 20. (P), 07.05
Szia, tévedés az, hogy minden esetben gubanc ha az alkalmazás táblákat hoz létre! Abban igazad van, hogy ez tervezés kérdése - ez maximálisan kiemelendő! A legtöbb nagyvállalati rendszer teljesen egyedül építi fel az adatbázisait a telepítéstől és egyéb beállításoktól függően és táblákat úgy hoznak létre saját maguktól mint a pinty. :) Persze ezeket a szoftvereket nagyon sok ember tervezi és írja, nagy költségvetéssel (ennek ellenére mindegyik tele van hibákkal :D). Sejtem, hogy te mire gondoltál, pl. amikor valaki egy fórumnál minden topichoz létrehoz egy táblát PHP-ból :) Igen, ez valóban kerülendő és egyáltalán nincs értelme, de ez kimeríti a tervezéshez nem értés fogalmát. :)

A kérdező gondolom MySQL-re gondolt, ott semmi korlát nincs a táblák számára egy adatbázison belül csak a fájlrendszer és a merevlemez korlátoz, úgyhogy nyugodtan írhatsz egy ciklust ami elkezd táblákat létrehozni véletlenszerűen :))
17

Benchmark?

janoszen · 2007. Júl. 20. (P), 09.32
Benchmark create table? :D:D
18

Igazábol csak elméleti

Ronyn · 2007. Júl. 20. (P), 09.50
Valoban csak a mysql részre voltam kiváncsi,ezért a kérdést inkább csak elméletinek szántam.
A példákat azért emlitettem,hogy érzékeltessem az adatok kapcsolatát.
Bár egy adott forumnál Nekem is megfordult a fejemben - átalakitom,oly módon hogy egy topic-egy tábla,mert igy néhány dolgot egyszerűbb lett volna megoldani.
De mivel én is idegenkedtem ettől a megoldástól,ezért is tettem fel a kérdést))
Amit végülis -ugytünik,sikerult is tisztázni))
21

view és join

Hodicska Gergely · 2007. Júl. 21. (Szo), 14.54
Tény és való hogy két tábla csatolásából időt veszítesz, de erre valók a view-k.
Miért is? ;) A viewnak alap esetben ehhez nem sok köze van. Van olyan DB, ami támogat materialized view, ott lehet ennek jelentősége, de itt alapvetően MySQL-ről szoktak szólni a kérdések (sőt ha a kérdező nem nevezi meg, akkor szinte biztosan ;)), ahol nincs ilyesmi. Itt a view az egy szimpla rövidítés, ráadásul a MySQL esetén van ezen a téren egy kis para, van amikor view használatával rosszabb végrehajtási tervet kapunk, mint anélkül.


Üdv,
Felhő
14

Szerintem is tervezési hiba

Nagy Gusztáv · 2007. Júl. 19. (Cs), 23.51
Szerintem egy (logikailag és fizikailag) jól megtervezett adatbázissal nincs nagy gond. Itt inkább az látszik, hogy alapvető tervezési tudáshiány van.
Ha a konkrét feladatot elmondanád, talán konkrét választ is kapnál.

vendégkönyv,ami több példányban futtathato

Mit értesz ez alatt? Egyáltalán mit jelent futtatni egy vendégkönyvet?

ha teljesen szétszedem az adatokat

Ha van köztük összefüggés, akkor lehet értelme a közös táblának, de akár több tábla is indokolt lehet. Tudsz normalizálni legalább 3NF-ig?
Ha nincs összefüggés, akkor meg mit is keresnének közös táblában?

Én ezt nagyon nem értem :-(

táblák száma


Láttam már 500 táblás adatbázist, de az kicsit brutális rendszer volt. Nehéz elképzelni, hogy százas nagyságrendnél több kelljen.
15

Szerintem

janoszen · 2007. Júl. 20. (P), 06.11
Szerintem a kérdező azon gondolkodott, hogy a táblákat ugyanolyan dinamikusan hozza létre mint a sorokat a táblákban, ami egyértelmű hiba.
19

Vk

Ronyn · 2007. Júl. 20. (P), 10.12
A vendégkönyv az konkrétan ugy müködik hogy a minden lekérés tartalmaz egy $user változót,amit levehet az url-ből,ha tartamazza,ha nem akkor a PHP_SELF-ből nyeri ki.
Szoval van egy mag/motor,mondjuk gb.php,és ezt include-al beillesztem mondjuk a vk1.php ill. vk2.php-ba,akkor két különállo vendégkönyvként futnak,ugyanez van ha az url-ben talál egy user változot.(hasonloan a regisztrálhato vendégkönyvekhez)))
Itt közösek a táblák,és a lekérés történik az $user szerint...
Bár aztán,itt is szükség volt rá,hogy "példányonként" külön táblába keruljenek a hozzászolások...