Salut,

1) Se da un tabel, care ar avea 3 coloane ntext(si x coloane de alte tipuri). Problema ar fi ca aceste coloane (ntext) de multe ori nu sunt folosite. Cam cat ar ocupa daca raman goale ?. sa zicem la 100.000 de inregistrari pe un server mssql2000.

2) Ce parere aveti de un design in stilul acesta. Avem tabelul Proiect - aici gasim cateva coloane numerice. mai departe avem ProiectContentShort ,ProiectContentLong si ContentType. Acum , daca ContentType-ul pentru un camp este "long" punem in tabela ProiectContentLong care are o coloana ntext. Daca tipul este "short" se pune in tabela ProiectContentShort unde este o coloana nvarchar(255) .
Cam asta a fost design-ul care mi-a fost propus, practic in loc sa am coloane .. am randuri care mimeaza coloane. :-s
Mie mi se pare foarte aiurea sa fac treaba asa ... mai ales apoi selecturi chestii probleme( gen cum iau toate datele pentru un proiect - la un select mi-ar intoarce pentru un proiect cu 5 campuri .. un tabel cu 5 randuri :| ).

Dupa cum ati inteles, intrebarile sunt legate. Daca puteti da cateva sfaturi, raman recunoscator.


PS: evident as prefera sa am coloane, dar e posibil sa nu pot schimba structura de la punctul 2

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

 

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.

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

 

---

Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)

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.

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?

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.

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

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.

---

Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)

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.

 

 

 

---

Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)

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

---

Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)

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.

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".

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

---

Secolul XXI ori va fi religios ori nu va fi deloc

crestinul:

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

E vb. de SQL2000 !