komentaaru table ieksh db

[ViszinisA]

ello

 

ir komentaari

ir datubaazee tabula, kur glabaaju komentaarus ( id, id_who, name, comment, date )

id_who pashaprotami noraada, kam pieder koments

 

saakumaa bija komentaari tikai bildeem, peec tam pieliku dazaam sadaljaam komentaarus

 

tagad gribu, lai buutu visaam bildeem, visaam sadaljaam (taam kuraam buus sakariigi), visiem jaunumiem u.c ja kas jauns paradiisies

 

id_who saakumaa bija tikai bilzu ID no bilzu tabulas, kur glabaajaas infa par bildeem

 

probleema:

ir 3 tabulas = bildes, jaunumi un sadaljas [kjip linki]

visaam trim ir vienaadi auto_increment ID

 

nevaru ierakstiit komentaru tabulaa vienaadus ID xD

 

Q: kaa to visu apvienot? [3 vienaadi ID ieksh vienas tabulas]

Q: likt kaut ko klaat tam id?

 

gan jau ka saprataat :D sori ka tik daudz pierakstiiju [man vnk jauki taustinji, kas viegli spiezas, un varu rakstiit aatri]

[gurkjis]

es pievienotu vēl vienu lauku, id_type, kas norāditu, kurai tabulai pieder id_who

piemēram, ja id_type=="image" ,tātad id_who ir no image tabulas.

[hackerman]

Nu kā visur visi id ir vienādi. Vienkārši

select comment from comments where id = $id AND where type = gallery

[Grey_Wolf]

ir datubaazee tabula, kur glabaaju komentaarus ( id, id_who, name, comment, date )

maza piebilde:

Ir slikti izmantot tabulas lauka nosaukumiem DB rezervetos vardus...

sajaa gadijumaa: name date...

[rob]

man ar kas sakāms neiesaku izmantot type = gallery bet gan type = 1, jo int strādās ātrāk :D

[NiTrino]

man ar kas sakāms neiesaku izmantot type = gallery bet gan type = 1, jo int strādās ātrāk :D

 

jaa plus

define ('COMMENTS_GALLERY',1);
...
$sql = "select comment from comments id = ".$id." AND type = ".COMMENTS_GALLERY;

 

uzskatāmāk. pēc kāda laika nav jaatceras ko nozīmēja 1,2,3 utt

 

un vēlams noindeksēt to lauku.

Edited August 15, 2007 by NiTrino

[andrisp]

Es gan iesaku katrai lietai (galerijai, sadaļām utt) veidot jaunu komentāru tabulu. Mazāks čakars, mazāk problēmu. Ātrāk strādās. Saprotamāk and so on.

[NiTrino]

jaa, labs risinājums ja komentāri iet tūkstošiem un desmitiem tūkstošu. mazām lapām imho nav jēgas.

[andrisp]

Kā nav jēga ? Rokas nokritīs, ka sadalīs komentārus loģiski pa daļām ? Jūsu piedāvātie risinājumi arī konfliktē ar normālformu likumiem (vai kā nu to varētu nosaukt).

[Aleksejs]

andrisp, ir arī trūkumi sadalīšanai.

Piemēram, ja gribam atlasīt visus lietotāja l komentārus visās sadaļās, vaicājums izskatās aptuveni šādi:

select * from sad1_komentari where lietotaja_id = l

union

select * from sad2_komentari where lietotaja_id = l

union

...//tā katrai sadaļai

Ja vēl galarezultāts ir jāsasortē, tad (manuprāt) datubāzei būs jāizmanto temporary tabula, lai parādītu rezultātu katru reizi.

Un vēl, pievienojot klāt jaunu sadaļu, būs jāpapildina vaicājums.

Bet, protams, jāskatās pēc situācijas. ;)

[bubu]

andrisp: kāpēc konfliktē normālformai? Vai vari pateikt, ar kuru precīzāk konfliktē (1/2/3) ?

[andrisp]

Man tavis nosauktās lietas neliekas trūkumi. :) UNION lietošana ir vienkārša. UNION arī atbalsta ORDER BY.

 

Bet vispār man šķiet tu nesaprati. Nejau katrai sadaļai komentāri jādala pa tabulām, bet loģiskajām daļām: Sadaļas (ar to domāts laikam lapas), Galerijas, Jaunumi.

 

Un visa bāšanai vienā tabulā ir vēl viens ļoti liels trūkums: dodu 99% garantiju, ka ar laiku parādītos vajadzība katrai loģiskajai daļai pievienot jaunus laukus, kas citām loģiskajām daļām nebūtu aktuālas. Tabula beigās būtu "piepūtusies", uzmetot aci nevarētu saprast, kuri lauki attiecīgajam ierakstam vispār ir jāaizpilda, kuri ne utt.

 

Bet nu jā - jāskatās pēc situācijas.

[Aleksejs]

UNION atbalsta gan ORDER BY, bet ņemot vērā, ka pēdējos pāris mēnešus ir nācies daudz strādāt pie SQL pieprasījumu optimizācijas, varu pateikt, ka UNIONs ar ORDER BY būs (using temorary, using filesort), ja to mēģināsi papētīt ar EXPLAIN (MySQLā, protams ;) ). Jā, protams, tās jau ir detaļas un varbūt, ka nav būtiskas šajā gadījumā, taču no optimizācijas viedokļa - tas ir slikts pieprasījums. ;) ja tas izpildās reizi mēnesī, tad, protams, nav nekāda vaina, taču, ja reizi minūtē, tad jau jāsāk aizdomāties ;)

 

Un par normālformām runājot, ne vienmēr normālformas ir jāieto. Klasisks piemērs - glabāt komentāru skaitu pie raksta, nevis katru reizi izsaukt SELECT COUNT(...) pieprasījumu. :) Ja strikti vadītos pēc normālformām, tad komentāru skaits ir lieka informācija, taču dublējot šo lieko informāciju mēs iegūstam būtisku ātrdarbības pieaugumu ;)

 

Bet, protams, katrs gadījums jāizvērtē atsevišķi.

[andrisp]

bubu, 3 normālforma: http://www.bkent.net/Doc/simple5.htm#label3.2

Third normal form is violated when a non-key field is a fact about another non-key field

Šajā gadijumā tas būtu lauks "type", kas ir fakts par lauku "id_who" (Tā laikam autors tos laukus nosaucis)

 

Aleksejs, komentāru skaita glabāšana pie rakstiem manuprāt nav normāluformu (vismaz pirmo 3) pārkāpums.

 

Par UNION ātrdarbību gan neko nezinu.

Edited August 15, 2007 by andrisp

[v3rb0]

tas normālformas jau ir tikai guidlaines kā labāk darīt, kad tās kļūst neizdevīgas, neievērojam.

cita runa ir pateikt to kādam akadēmiskam profesoram, uzreiz ādu pār acīm tev novilks :)