Lauku skaits mysql tabulā

[betons]

Tātad man ir user tabula, kurā tiek glabāti reģistrētie lietotājis.

Man ir tāda nepieciešamība, ka katram userim ir nepieciešami kādi 40 datu lauki.

Šie lauki tek izmantoti dažādos aprēķinos un tiem ir dažādi datu tipi.

Bez tam programmas upgreidošanas procesā var rasties vēl pāris desmiti lauku.

 

Mans jautājums ir tāds, kā labāk darītu šādā situācijā jūs???

- Glabātu visus laukus user tabulā?

- Ustaisītu vēlvienu tabulu, kurā viens ieraksts ir piesaistīts vienam lietotājam user tabulā?

- citi varianti?

 

 

Vēl vien jautājums:

Kā jūs domājat ir darīt labāk:

1) Aprēķinus likt veikt MySQL serverim;

2) Pieprasīt daus no MySQL, aprēķināt ar PHP un tad aizsūtīt atpakaļ uz MySQL.

Edited December 1, 2007 by betons

[andrisp]

Laukus, kurus tik bieži nevajadzēs izmantot kā galvenos datus (id, name utt) varētu pārnest uz citu tabulu.

 

Par tiem aprēķiniem: tas ir stipri atkarīgs no situācijas. Bet vispār jau priekšroku dotu aprēķiniem mysql pusē. Kaut gan parasti tur tos ir grūtāk realizēt.

[Kaitnieks]

Es visus laukus glabātu user tabulā, tikai ar selectiem rīkotos apdomīgāk, nevis kā parasti (tb., nevis SELECT * FROM bet SELECT lauks, lauks, lauks FROM), it īpaši ja runa iet par gariem teksta laukiem.

 

Aprēķinus, ko var veikt ar MySQL labāk veikt ar MySQL. Jo īsāks klaiņošanas ceļš datiem, jo mazākas kļūdas iespējamības un labāka pārskatāmība.

[MC_]

Man piem. nepatīk platas tabulas. esmu dzirdējis ka MySQL arī ne. :)

Es taisītu 3 tabulas:

users (uid,...)

users_fields (uid, fid, field_name_lv, field_name_ru,....)

users_fields_values (vid, fid, uid, ....)

[andrisp]

Kaut gan ideja neslikta, tomēr imo perfomances ziņā šāds risinājums būtu lēnīgāks nekā plata tabula. Bet nu einusazin :)

[Grey_Wolf]

viss ir atkarigs kadi dati tiks glabati

teiksim :

id| vards | uzvards | pers kods | tel1 |tel2 |tel3 ...

butu liederigi sadaliit

kur telefonii tiek izdaliiti atseviskja tabula ...

tapat ar pasutijumu utt... datiem

 

Dati kas 1 userim NEKAD nebus dublikata viena tabula parejos uz citu tabulu....

teiksim:

telefona nr.. (parasti buus no 1-(~~ 10)

adreses arii vairakas (majas , darba utt...)

izdaritie pasutijumi --> neprognozejami --> Gandriz obligati atseviskja tabula...

 

dati kas var but ir , varbut nav .... arii der izdaliit atseviskja tabulaa....

----

Taka katrs gadijums jaskata invidiuli ....

 

P.S. dazreiz plata tabula ir labaka par daudz mazinjam, ka arii ja tabula ir daudz text lauki, tad biezji vien tosvelams iznest atseviskji , (it ipashi ja tur vel glabajas ielagosanas infa (username/password) ) buus krietni vien atrak...

[nemec]

ja datus neizmanto sorteeshanai, mekleeshanai vai veel kur. tad es vienkaarshi uztaisu veel vienu kolonnu `params` (text) un tur visu salieku ar http://lv.php.net/serialize.

bet nevaru saprast kaada skaitiishana var buut `user` tabulaa?

[betons]

Jautāšu šijā pašā topikā:

 

1) Ja man ir kverijs:

UPDATE t1 SET a1=now(), ... (daudz visādi aprēķini, kas var aizņemt laiku) ..., a2=now() WHERE id=1;

Vai ir teorētiski iespējams ka a1 un a2 atšķiras, tas ir, ja kverijā vairākas reizes izmanto now(), vai viņš viena kverija ietvaros būs vienāds?

 

2) Ja tāds pats kverijs tikai WHERE id>1 and id<100

Vai šādā gadījumā katrā no rindām now() lielums var atšķiries?

 

 

3) Ja ir kverijs, kuram tiek nodoti kādi 3 parameri, bet viņš ir kādus 500-1000 simbolus garš, jo viņā ir gari aprēķini, vai ir jēga taisīt STORED PROCEDURE ar domu samazināt trafiku starp php un mysql serveri? Vai varbūt kāda cita jēga?

[Grey_Wolf]

betons -->

1. DB tomer ir domata DATU glabasanaj nevis aprekjinu veiksanai

2. Ir pilnigi bezjedzigi viena UPDATE likt 2 NOW() {varjaubut ka kadreiz savadak nevar }

3. Jaa ja bus vairaks reizes UPDATE tad NOW() laiks atskjirsies {ja izpildes laika starpiiba buus ~~~ 1 sek...}

----

Un velreiz DB ir Domata DATIEM .... nevis aprekjinu veiksanai

---

P.S. protams buus bezjedzigi skaitit cik reizes ir tabula updeitota PHP puse nevis SQL ( bla=bla+1 gadijums) ...

[Kaitnieks]

Jautāšu šijā pašā topikā:

 

1) Ja man ir kverijs:

UPDATE t1 SET a1=now(), ... (daudz visādi aprēķini, kas var aizņemt laiku) ..., a2=now() WHERE id=1;

Vai ir teorētiski iespējams ka a1 un a2 atšķiras, tas ir, ja kverijā vairākas reizes izmanto now(), vai viņš viena kverija ietvaros būs vienāds?

 

2) Ja tāds pats kverijs tikai WHERE id>1 and id<100

Vai šādā gadījumā katrā no rindām now() lielums var atšķiries?

 

 

3) Ja ir kverijs, kuram tiek nodoti kādi 3 parameri, bet viņš ir kādus 500-1000 simbolus garš, jo viņā ir gari aprēķini, vai ir jēga taisīt STORED PROCEDURE ar domu samazināt trafiku starp php un mysql serveri? Vai varbūt kāda cita jēga?

 

Par pirmajiem diviem jei bogu nezinu (bet jautājumi ļoti interesanti, godīgi sakot; gribētos notestēt), lai gan minētu, ka atbilde ir "nē" (edit: as in "nē, viņš nebūs viena kverija ietvaros vienāds") uz #1 un "jā" uz #2.

 

Par 3 - no stored procedūras ir daudz jēgas, bet minimālo trafika samazināšanu es nekad nebūtu saucis kā galveno ieguvumu :D Galvenie ieguvumi ir drošībai (teiksim, ja izej uz modeli, kurā Tevis veidotā sistēma slēdzas datu bāzei ar lietotāju, kurš tabulām vispār klāt netiek, bet tikai sev atvēlētajām procedūrām, tad pat iegūstot pieeju datu bāzei, Malfojs neko izdarīt nespēs), kā arī arhitektūrai, pieliekot datu loģiku tuvāk tās asinīm - datiem, tādā veidā ļaujot Tev uztaisīt vēl kādu sistēmu kaut vai citā vidē, kas varētu izmantot šīs pašas procedūras, izvairoties no datu loģikas dublēšanas.

Edited December 3, 2007 by Kaitnieks

[betons]

2. Ir pilnigi bezjedzigi viena UPDATE likt 2 NOW() {varjaubut ka kadreiz savadak nevar }

 

Konkrētis piemērs ir šāds

 

UPDATE t1 SET l1=l1+l2*(UNIX_TIMESTAMP(now())-UNIX_TIMESTAMP(lpt)), ... vēl aprēķini, kuros izmanto to pašu now() ..., lpt=now() WHERE .....

 

tātad lpt ir laiks, kurā tika veikts pēdējais aprēķins

(UNIX_TIMESTAMP(now())-UNIX_TIMESTAMP(lpt)) ir laika starpība starp pēdējo aprēķinu un tagadni

 

un man ir svarīki lai laika starpības izmantotais now(), būtu tāds pats, kā beigās, kad lpt=now();

 

 

 

Nu, tad sakarā ar šo vēl viens jautājums:

 

Es vairākas reizes izmantoju aprēķins laika starpību

(UNIX_TIMESTAMP(now())-UNIX_TIMESTAMP(lpt))

 

Vai ir kāds veids, ka viņu izmantot vienreiz, es pašlaik atradu tikai veidu, ja izmanto papildus fieldu:

 

UPDATE t1 SET dt=(UNIX_TIMESTAMP(now())-UNIX_TIMESTAMP(lpt)), l1=l1+l2*dt, ... , lpt=now() WHERE .....

 

Vai to ir iespējams izdarīt bez papildus fielda?

[Grey_Wolf]

betons --> tas ir apsaluti bezjedzigi , ja vien negrasies noskaidrot cik tad atri tev strada serveris ....

parsvara matimatiskas operacijas notiek TIK ATRI ka rezultats 99,99 gadijumos buus pilnigi vienads ...

vel buus ljoti svarigs paraametrs ka Procesora atrums / atminjas daudzums utt....

Respektivi Ljoti daudz pilnigi neparedzamu (dotaja laika momenta) parametru -->

+ ietekmet tu to nekadi nevaresi ... Nu neizdosies piespies (dotaja laika) teiksim serveri neveikt keshu vai nezko vel... (standart proceduras...)

ta ka IMPHO shis ja nav tas gadijums kur tas nepieciesams....

+ arii useria kompis / savienojums dos savu piedevu procesa neprognozeesanai.....

+ ir iespejams savakt laiku cik ilga laika tika paveikts dotais kverijs un to pectam mierigi ierakstiit DB (ja ja tas tik nepieciesams ) --> buus daudz vienkarsaak

+ Krietni vien precizak ......

[v3rb0]

php pusē vienu reizi time(); un talāk sql'aa izmanto dabūto timestampu? katrā ziņā, tas varētu būt labāk par papildus lauka izmantošanu.

[xPtv45z]

Par NOW() - http://dev.mysql.com/doc/refman/6.0/en/dat...ml#function_now

[andrisp]

Interesanti, nemaz nezināju, ka iekš kverija var izmantot tādu lietu kā sleep() :)