Intrebari generale

Re: Optimizare si redesign tabele

B_gd_n[ ]Sahlean — Mon, 08 Jun 2009 21:44:33 GMT

silviu:
Multumesc pentru lamuririle privind tipul uniqueidentifier. Nu sunt foarte experimentat pe SQL Server si nu l-am mai vazut folosit, undeva. Voi discuta cu colegii si voi incerca sa schimb varchar-ul cu uniqueidentifier, urmand ca ulterior sa fac teste de performanta. Dupa cum Remus a intuit, privind folosirea uneia din functiile Uuid standard, avem un wrapper ce foloseste UuidCreate(), si nu un algoritm propriu.

200.000 înregistrări nu sunt multe.
Recomandarea 7252 a fost ca înainte de a încerca diverse [non]soluţii
să rulezi o interogare (care are timpi de execuţie mari) în SQL Server Management Studio cu opţiunea Query > Include actual execution plan.
Vei putea să identifici care etape din execuţia interogării (operatori) sunt "costisitoare"(costuri mari care de obicei se traduc prin timpi mari).

Eventual, poţi publica aici (dacă e posibil) interogarea şi planul de execuţie.

Re: Optimizare si redesign tabele

silviu — Mon, 08 Jun 2009 21:22:09 GMT

Multumesc pentru lamuririle privind tipul uniqueidentifier. Nu sunt foarte experimentat pe SQL Server si nu l-am mai vazut folosit, undeva. Voi discuta cu colegii si voi incerca sa schimb varchar-ul cu uniqueidentifier, urmand ca ulterior sa fac teste de performanta.

Dupa cum Remus a intuit, privind folosirea uneia din functiile Uuid standard, avem un wrapper ce foloseste UuidCreate(), si nu un algoritm propriu.

Re: Optimizare si redesign tabele

rremus — Mon, 08 Jun 2009 15:01:15 GMT

Dupa cum tzi-a zis si Bogdan, exista tipul de date specializat uniqueidentifier, care are 16 bytes. Tu ai les sa stochezi in formatul character, care este mai mult decit dublu ca lungime. Si nu numai atit, ai ales varchar(36) ca sa mai adaugi inca citiva biti la stocare, desi lungimea unui GUID reprezentat ca string este fixa. Si ca sa pui cireasa in virf ne atragi atentia ca este 'un identifier generat intr-un algoritm scris in C++' ! Un raspuns mirobolant. Sincer sper ca aplicatia ta nu genereaza UUID-uri intr-un algoritm propriu, ci le genereaza corect apelind fie UuidCreate fie UuidCreateSequential, sau una din functiile wrapper gen CoCreateGuid.

Re: Optimizare si redesign tabele

B_gd_n[ ]Sahlean — Mon, 08 Jun 2009 12:08:48 GMT

silviu:
rremus:
Deci e varchar(36), asa ca wtf se aplica
Citat din MSDN "By converting from a string constant in the form xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, in which each x is a hexadecimal digit in the range 0-9 or a-f. For example, 6F9619FF-8B86-D011-B42D-00C04FC964FF is a valid uniqueidentifier value." Un astfel de string sub ce format de coloana le stochezi, altul decat varchar(36)? Daca nu exista altul mai potrivit, atunci nu e nici un wtf.

În antetul paginii web indicate de tine scrie:
"

uniqueidentifier (Transact-SQL)

Is a 16-byte GUID.

Remarks

A column or local variable of uniqueidentifier data type"

Re: Optimizare si redesign tabele

silviu — Mon, 08 Jun 2009 11:27:34 GMT

rremus:
Deci e varchar(36), asa ca wtf se aplica

Citat din MSDN

"By converting from a string constant in the form xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, in which each x is a hexadecimal digit in the range 0-9 or a-f. For example, 6F9619FF-8B86-D011-B42D-00C04FC964FF is a valid uniqueidentifier value."

Un astfel de string sub ce format de coloana le stochezi, altul decat varchar(36)? Daca nu exista altul mai potrivit, atunci nu e nici un wtf.

Re: Optimizare si redesign tabele

rremus — Fri, 05 Jun 2009 17:31:22 GMT

Deci e varchar(36), asa ca wtf se aplica

Re: Optimizare si redesign tabele

silviu — Fri, 05 Jun 2009 11:00:56 GMT

E tot un unique identifier generat printr-un algoritm scris in C++ (are loc conversia unui string constant in unique identifier - cazul doi din link-ul tau). Aplicatia ce utilizeaza baza de date este scrisa in C++, iar la nivel de baze de date e tinut ca si varchar (36).

Re: Optimizare si redesign tabele

rremus — Fri, 05 Jun 2009 09:20:44 GMT

Deci e uniqueidentifier sau varchar(36) ?

Re: Optimizare si redesign tabele

silviu — Thu, 04 Jun 2009 21:42:29 GMT

In primul rand, multumesc pentru sfaturi. Sfaturile tale m-au determinat sa ma gandesc serios teste suplimentare de eficientitate, inainte de a trece la modificari in aplicatia propriu-zisa ce utilizeaza baza de date avuta in discutie voi efectua teste cu interogarile respective.

In alta ordine de idei, acel guid despre care vorbesc eu este exact unique identifier la care faci tu referire... Deci nu e nici un wtf. :)

Numai bine!

Re: Optimizare si redesign tabele

rremus — Wed, 03 Jun 2009 16:31:37 GMT

Exista o singura idee si un singur sfat: masoara, nu ghicii. De unde stii ca dimensiunea cheii este problema? Masoara, masoara si iar masoara.
Ia un query din cele de zeci de secunde si ruleaza-l din SSMS. Seteaza SET STATISTICS IO ON si vezi ce logical reads are, pe ce rowset. Sint zeci sau sute? De la mii in sus in mod sigur faci scan nu seek. Poate ca un rowset este scana in intregime? Poate mai multe sint scanate? Paote chiar de mai multe ori? Afiseaza planul actual de executie (nu cel estimat, ala e BS). Planul arata ce operator consuma cel mai mult timp si de unde vin cele mai multe date. Ce operator e?

GUID nu e intradevar o alegere fericita, mai ales daca este tzinut ca varchar(36) (wtf!!!!) si nu ca uniqueidentifier. Dar daca problema este de query design atunci convertirea in numeric a cheilor va fi doar o operatie extrem de dureroasa si fara nici un rezultat.

Masoara, Masoara, Masora. Apoi taie.

Optimizare si redesign tabele

silviu — Wed, 03 Jun 2009 14:05:04 GMT

Am o baza de date SQL Server 2005 iar cheile de indexare si legaturile dintre tabele sunt retinute prin GUID-uri unice (varchar(36)).
Problema e ca am mai multe join-uri intre tabele, tabele care ajung sa aibe foarte multe inregistrari (200.000 de inregistrari) si se ajunge ca unele queries sa dureze foarte mult (zeci de secunde, uneori chiar minute).
Incerc sa gasesc solutii pentru a reduce acesti timpi.

Una din idei ar fi inlocuirea guid-urilor cu id-uri de tip integer si adaugarea unor tabele de guid-uri care sa faca legatura dintre id-ul nou creeat si guid. Am inteles ca interogarile dupa chei numerice ar rula mult mai repede.

O alta idee ar fi impartirea unei astfel de tabele cu multe inregistrari in mai multe tabele, in functie de tipul inregistrarilor (inregistrarile sunt de mai multe tipuri generale). Astfel, voi avea interogari mai rapide, pe un numar mult mai limitat de inregistrari. Totusi, e f. greu de impartit pe astfel de categorii caci majoritatea inregistrarilor sunt doar de un anumit tip.

Orice idee si sfat sunt bine-venite.