Intrebari

Re: Coloana ntext

crestinul — Thu, 03 Apr 2008 16:38:48 GMT

B_gd_n[ ]Sahlean:
crestinul:
O alta varianta ar fi sa tii descrierea clientului intr-un camp xml
E vb. de SQL2000 !

hops sorry

Re: Coloana ntext

B_gd_n[ ]Sahlean — Thu, 03 Apr 2008 14:30:25 GMT

crestinul:
O alta varianta ar fi sa tii descrierea clientului intr-un camp xml

E vb. de SQL2000 !

Re: Coloana ntext

crestinul — Thu, 03 Apr 2008 14:19:56 GMT

O alta varianta ar fi sa tii descrierea clientului intr-un camp xml

Re: Coloana ntext

Diana — Thu, 03 Apr 2008 12:06:49 GMT

Cred ca merita sa testezi propunerile noastre si sa vezi cum "merge" fiecare (de exemplu la intro de date / raportare) - stabileste ce query-uri vrei sa rulezi, cam la ce volum de date, etc.

In cazul tau am inteles ca vrei sa folosesti baza si pentru intro de date, deci mi se pare OK sa pornesti cu o schema normalizata. Pe parcurs, daca chiar esti nevoit (adica daca nu mai poti optimiza altfel accesul la date), poti sa denormalizezi - schimbarile vor fi mai usor de facut si de mai mica anvergura. Sau poti folosi o solutie "OLAP"...In schimb, dupa cum spunea Andrei in http://sqlserver.ro/forums/thread/4491.aspx, "daca ai pornit denormalizat, e mai mare daraua sa normalizezi".

Re: Coloana ntext

Gherry — Wed, 02 Apr 2008 22:07:07 GMT

ggciubuc:
Diana:

Si ce faci daca alt client are de exemplu 3 sedii?

De obicei la momentul de analiza din ciclul de viata al unui proiect problema se lamureste foarte clar : "Cate sedii detin clientii dvs.? Cate ar trebui sa retineti in baza de date?" Mai pui intrebari ca sa se vada cat si cum se prelucreaza datele stocate in astfel de coloane de tip vector; daca acestea sunt des folosite si apar prin interogari iar bd se estimeaza ca va creste dramatic se poate sparge tabela printr-o trecere intr-o forma normala superioara.

poate oricand sa apara un client nou cu un numar mai mare de sedii insa daca utilizatorul decide (si e multumit) sa stocheze doar un anumit numar limitat pt fiecare in parte atunci ar putea fi acceptabila solutia.

Re: Coloana ntext

ggciubuc — Wed, 02 Apr 2008 20:34:54 GMT

Ca sa continui expunerea precedenta parerea mea este ca in activitatea de programare software trebuie sa urmarim viziunea lansata metodologia Agile care cere ca ca aplicatia sa fie utilizabila si utilizatorul satisfacut de ea. Degeaba ne incurcam in forme si-n interogari supersofisticate daca se asteapta o caruta de timp pt a returna datele. Apoi abordata mai intai simplitatea si apoi crescuta progresiv complexitatea.

In aceasta idee as vrea sa se vada si raspunsurile mele la postarea http://sqlserver.ro/forums/thread/4491.aspx

Re: Coloana ntext

ggciubuc — Wed, 02 Apr 2008 20:24:06 GMT

sirrocco:

Dar la partea cu coloanele inca nu sunt convins. Deci : Ai tabelul Proiect si are coloanele :
NumeProiect, NumeProiectLung, NumeProiectMaiScurt, Descriere, DescriereScurta, DescriereLunga si inca vreo 5 asa sa zicem. Chiar daca unele sunt null , tot nu vad in asta un motiv destul de bun sa folosesc tabel(col,tip).
Si nici nu vad cum ar fi mai usor pentru programator chestia cu tabel(col,tip). Eu chiar asta zic, ca mi-e mai greu.

Tabelul (col,tip) ar fi cam asa

tblDescrieri

IDDescriere (int) Descriere (tip text sau varchar(max)) TipDescriere (varchar cu valorile : "Lunga", "Scurta")

si tabelul de legatura

tblDescriereProiect

IDProiect IDDescriere

Problema e ca de fapt trebuie avut in vedere ca aplicatia sa fie usoara pt utilizator mai intai, sa returneze/prelucreze datele rapid deci performanta pe server si mai apoi cat de repede o rezolva programatorul.

Sigur e de discutat de exemplu TipDescriere are pe client un combobox, este o singura caseta text (nu 3 sau 2 ) si nu aglomereaza interfata.

Re: Coloana ntext

ggciubuc — Wed, 02 Apr 2008 20:11:14 GMT

Diana:

Si ce faci daca alt client are de exemplu 3 sedii?

De obicei la momentul de analiza din ciclul de viata al unui proiect problema se lamureste foarte clar : "Cate sedii detin clientii dvs.? Cate ar trebui sa retineti in baza de date?" Mai pui intrebari ca sa se vada cat si cum se prelucreaza datele stocate in astfel de coloane de tip vector; daca acestea sunt des folosite si apar prin interogari iar bd se estimeaza ca va creste dramatic se poate sparge tabela printr-o trecere intr-o forma normala superioara.

Re: Coloana ntext

Gherry — Wed, 02 Apr 2008 19:35:18 GMT

Diana:
Si ce faci daca alt client are de exemplu 3 sedii?

Sirrocco, la ce te referi cand spui ca ti se pare mai complicat sa introduci date noi?

personal cred ca e cazul sa se scoata campurile de adresa, telefon si de email din tabelele cu date personale

Re: Coloana ntext

Gherry — Wed, 02 Apr 2008 19:32:21 GMT

parerea mea este ca structura care ai mentionat-o la punctul 2 o sa o schimbi oricum mai devreme sau mai tarziu pt ca la 100.000 de inregistrari nu cred ca va fi foarte rapida rularea unui query mai complex (gandeste-te ce se va intampla daca vrei sa pui o conditie pe unul din acele "campuri"). in opinia mea acea varianta e utila daca vrei sa suporti campuri care sa poata fi definite ulterior de un utilizator (fara sa sti la design cate campuri vor fi). e foarte draguta insa eu o consider riscanta pe partea de performanta. deci se poate face si poate lucra foarte elegant dar nu stiu daca o va face la o viteza acceptabila.

Re: Coloana ntext

Diana — Wed, 02 Apr 2008 19:14:04 GMT

Si ce faci daca alt client are de exemplu 3 sedii?

Sirrocco, la ce te referi cand spui ca ti se pare mai complicat sa introduci date noi?

Re: Coloana ntext

sirrocco — Wed, 02 Apr 2008 18:47:11 GMT

Ok, ntext e lamurit. am gasit exact acelasi lucru si pentru 2000.

Dar la partea cu coloanele inca nu sunt convins. Deci : Ai tabelul Proiect si are coloanele :
NumeProiect, NumeProiectLung, NumeProiectMaiScurt, Descriere, DescriereScurta, DescriereLunga si inca vreo 5 asa sa zicem. Chiar daca unele sunt null , tot nu vad in asta un motiv destul de bun sa folosesc tabel(col,tip).

Si nici nu vad cum ar fi mai usor pentru programator chestia cu tabel(col,tip). Eu chiar asta zic, ca mi-e mai greu.

Re: Coloana ntext

ggciubuc — Wed, 02 Apr 2008 17:04:06 GMT

Citez din books online de la 2005

"ntext

Variable-length Unicode data with a maximum length of 2^30 - 1 (1,073,741,823) characters. Storage size, in bytes, is two times the number of characters entered. The SQL-2003 synonym for ntext is national text.

Asa cum am subliniat in rosu e vorba de o data variabila deci atat cat e atata stocheaza (nu maximum de 1 miliard); asa cum e si pt varchar se stocheaza undeva niste biti de supravegehere a continutului coloanei.

Cat despre locul unde ar fi sa fie postate datele este clar ca pe coloane atrage redundanta in date pt ca daca ai

tabel(col1,col2,...,coln) si coln, coln+1,coln+2 sunt goale inseamna pierdere de spatiu si complexitate crescuta pt programator fata de o abordare

tabel(col,tip) unde in col ar intra toate datele col1,...coln iar tip le deosebeste.

Dar si aici sunt exceptii apropos de scopul care trebuie servit de schema bd : de exemplul ai Adresa1, Adresa2 un client care are 2 sedii, e benefic sa pastrezi cele 2 coloane chiar daca ai clienti cu un singur sediu decat sa adaugi tabela Adrese care inseamna join-uri , indecsi etc

Re: Coloana ntext

sirrocco — Wed, 02 Apr 2008 15:47:32 GMT

Ms pentru incercarea de ajutor dar in mare as vrea sa evit tinerea de coloane in randuri , practic asta se realizeaza , si motivul pentru schema asta ar fi : o metoda prin care s-ar adauga campuri usor in entitatea Proiect. Mie nu mi se pare ca se adauga usor :|. eventual e mult mai confuz.

Deci, cam cat de mare ar fi paguba daca as avea inregistrari ntext goale .?
Si eventuale pareri - cum e mai bine sa fie : coloane, sau sa transform coloanele in randuri.

Re: Coloana ntext

Diana — Wed, 02 Apr 2008 13:37:31 GMT

Incearca:

- tabel Project cu coloanele: ProjectID int (primary key)+ coloanele numerice...

- tabel ContentType cu coloanele: ContentTypeID int (primary key), ContentType varchar(...) - "Long", "Short", etc...

- tabel ProjectContent cu coloanele: ProjectContentID int (primary key), ProjectID (foreign key), ContentTypeID (foreign key), Content (ntext). Daca proiectul exista si are "content", inserezi randuri in ProjectContent cu acel ProjectID si ContentTypeID.

"Content" - ul pentru un proiect:

SELECT Content FROM ProjectContent WHERE ProjectID = @ProjectID AND ContentTypeID = @ContentTypeID