ugrás a tartalomhoz

Sok kicsi vagy egy nagy táblát használjak adatbázisomban?

jeti · 2006. Május. 12. (P), 22.32
Sziasztok!

Hogy lehet a legpraktikusabban egy adatbázis tábláit kezelni?
Ez alatt azt értem, hogy sok kicsi, vagy egy nagy táblát használjak.
(Pl.: regisztrációs adatok, fórumi hozzászólások, cikkek, blogok … tárolására)

A segítségeket előre is köszönöm.
 
1

Sok kicsi

Anonymous · 2006. Május. 13. (Szo), 00.47
Természetesen minden adatfajtához más és más adatstruktúra való. Például egy cikknek nincs login neve és jelszava, egy regisztrált felhasználónak viszont nincs lead-je, vagy alcíme.

A válasz tehát adja magát: ahányféle adatot tárolunk, annyi táblát használjunk.

Gyulus
2

néha meg nem

Táskai Zsolt · 2006. Május. 13. (Szo), 01.44
általában és alapvetően persze igaza van Gyulusnak, de ne egyszerűsítsük le ennyire a kérdést. a hatékony adatbázistervezés külön szakma. javaslom a tárgy irodalmát tanulmányozni. én sokat okultam az Oracle tervezés c. könyvből, de biztos van már újabb is, jobb is.
Tasi
3

Pontosítás

jeti · 2006. Május. 13. (Szo), 10.44
Tehát, akkor elég csak adatstruktúránként mást használni.
Így használom én is, de szerintem túlságosan elkülönítek mindent.
11 fórumom van, ez 11 fórumi hozzászólási táblából és 11 fórumi téma táblából áll. Tehát, akkor simán összevonhatom két táblába az egészet?
Van kb. 12 vicc kategóriám, mindegyik külön táblában van, annak ellenére, hogy ugyan olyan mezőkből állnak. Szinte minden ennyire szét van szórva. Több mint félszáz táblám van…
A következő fejlesztésnél, akkor érdemes lenne összevonom ezeket?
Persze van néhány eset, amikor más honlap használja a táblákat. Ezeket majd ésszerűen vonom össze.
4

Pontosítás

Anonymous · 2006. Május. 13. (Szo), 11.41
A 11 fórumot egy táblában kellene tartanod, és a fórumokat egyedi azonosítóval ellátnod. Így minden fórum témája egy táblába kerül az azonosítójával együtt. Egy másik táblába pedig a hozzászólásokat tárolod, és minden hozzászólás mellett a téma azonosító.
Így még keresni is egyszerűen tudsz például.

Gyulus
5

hozzászólás mindenhez

jeti · 2006. Május. 13. (Szo), 19.31
Először is köszönöm az eddigi segítségedet. Hamarosan áttérek erre az adatbázis szerkezetre.
Eddig meg volt adva a hozzászólásnál a téma- és fórumazonosító is, és minden hozzászólás témánként volt számozva. Tehát több azonosítóra kellett hivatkoznom. pl.: 1-es fórum, 2. téma, 3. hozzászólás. De amit javasolsz, az tényleg sokkal jobb. Azért hoztam létre ezt a témát, mert nem voltak jól kereshetők az adatok és a legfrissebbeket sem tudtam egyszerűen összegyűjteni.
A blog egyelőre még csak terv. Szeretnék mindenhez hozzászólási lehetőséget biztosítani.
Pl.: cikkek, linkek, letöltések, apróhirdetés, képek később a blogon is.
Érdemes itt is egy hozzászólás táblába kategorizálni? Pl.: típus: blog, azonosító: 18; típus: kép, azonosító: 23. Ahol kiszűröm, és időrendi sorrendbe rendezem az elemeket. Vagy szedjem szét típusokra? blog hozzászólás, kép hozzászólás …
Ez így jó, vagy van ennél jobb megoldás is?
6

összetett kérdés

Táskai Zsolt · 2006. Május. 13. (Szo), 23.43
nehéz ilyen kérdéseket megválaszolni, mivel minden döntés mindennel összefügg. ezért is javasoltam az irodalom tanulmányozását. kiemelik, hogy minden ilyen döntésed előtt azon gondolkozz el erősen, hogy milyen műveleteid lesznek, és azokból mennyi. nyilván esetedben a lekérdezések nagyságrendileg többen lesznek, mint a hozzáadások, pláne meg a törlések. tehát optimalizálj a lekérdezésre, és abból is arra, amiből sok van. a kérdésed értelmesen feltett kérdés, szerintem mégsem igazán lehet rá felelős választ adni. mondjuk én igyekeznék egy táblába terelni a hozzászólásokat, de csak akkor, ha a témák is összevonhatók (blogbejegyzés és kép közös részének kiemelése egy "kommentezhető_egység" táblába mondjuk). egy cikk majdnem ide vág: http://tecfa.unige.ch/guides/mysql/man/manuel_Table_cache.html#Table_cache
jó munkát,
Tasi
7

Példa

janoszen · 2006. Május. 14. (V), 08.47
Most ez egy példa. Szóval, nem biztos, hogy jó lesz neked:

CREATE TABLE resources (
 id INT PRIMARY KEY AUTO_INCREMENT,
 author INT,
 title VARCHAR(255),

 attachtoresource INT,

 ...stb általános infók, amik mindenhol előfordulnak...

 FOREIGN KEY (author) REFERENCES users(id) ON DELETE SET NULL ON UPDATE CASCADE
 FOREIGN KEY (attachtoresource) REFERENCES resources(id) ON DELETE CASCADE ON UPDATE CASCADE
);

CREATE TABLE valamitartalomtipus (
 id INT PRIMARY KEY AUTO_INCREMENT,
 resource INT NOT NULL,

 ...ált infok ehhez a tartalomtípushoz...

 FOREIGN KEY (resource) REFERENCES resources(id) ON DELETE CASCADE ON UPDATE CASCADE
);
És ha nem szúrtam el semmit, akkor a resourcesben tudsz olyat csinálni az attachtoresoure-ban megadod, hogy melyikhez legyen csatolva. Így pl. tudsz egy hozzászólás-sort csatolni egy cikkhez vagy ilyesmi. Vagy akár hozzászólást hozzászóláshoz (hozzászólás-fa). Csak azt kell biztosítanod, hogy legyen egy "Hozzászólás" gomb, amely a hozzászólást csatolja az eredeti tartalomhoz. Ennek az a legfőbb hátulütője, hogy mivel rekurzív lekérdezést kell csinálnod, sok lesz a lekérdezésed.

Remélem, segített.
9

gyorsaság?

Anonymous · 2006. Május. 15. (H), 22.03
az igaz, hogy a kereség így egyszerübb, de ha van kismillió bejegyzés, akkor az összesnek végig kell nézni az azonosítóját, mig ha külön táblákba tárolnád, akkor csak egy sima select lenne. szóval szertintem sem ennyire egyértelmű a helyzet.
8

Köszönet

jeti · 2006. Május. 15. (H), 17.42
Köszönöm a segítségeket. Valószínűleg úgy készítem el, ahogy említettem (minden témát egy táblába). Mindenhol 3 lekérdezésem lesz; egy vagy kettő hozzáadás; friss adatoknál egy, két lekérdezés, a kereséseknél több lekérdezésem lesz, de ez még így is jobb, mint most. Kezdem lefaragni a 83 táblámat… A rekurzív lekérdezést még nem ismerem, majd később, ha találok egy jó magyar leírást, akkor lehet, hogy visszatérek még ehhez a témához. Jelenlegi SQL tudásom „Tanuljuk meg a PHP4 használatát 24 óra alatt” + személyes tapasztalat. Úgyhogy ezt majd fejlesztenem kell.
Könnyebb lesz egyben kezelni az adatokat, és már tudom, hogy jó felé haladok.