Pentru cei care au participat acest thread este dedicat feedback-ului. Va multumim.

---

Cristian Andrei Lefter, SQL Server MVP
MCT, MCSA, MCDBA, MCAD, MCSD .NET,
MCTS, MCITP - Database Administrator SQL Server 2005
http://sqlserver.ro

Legat de noua functionalitate din sql2008 denumita "sparse columns" si de exemplul cu respectivele produse care au caracteristici diferite (ex. pentru mouse : este wireless = {D/N} , ... pentru monitor: tip = {CRT, LCD} ), soluţia sugerata a fost utilizarea unei singure tabele care va include ca şi câmpuri toate caracteristicile (ex. IsWireless) ca şi campuri care accepta si valori nule.

Problema enuntata mai sus e in primul rand (in opinia mea) una de proiectare a bazei de date. Daca am avea la dispozitie o baza de date orientata-obiect sau un limbaj de programare orientat-obiect atunci solutia ar fi fost simpla: specializarea & mostenirea.

In cazul acesta subclasele Monitor si Caiet vor mosteni atributele superclasei Produs.

Aceasta diagrama UML poate fi implementata intr-o baza de date relationala astfel:

a) câte o tabela pentru fiecare clasă =>

Produs(CodProdus - Cheie Primara, Denumire)

Monitor(CodProdus - CheiePrimara si CheieExterna referinta Produs(CodProdus), Tip, Diagonala, DimensiunePunct, ...)

Caiet(CodProdus - CheiePrimara referinta Produs(CodProdus) si CheieExterna, NrPagini)

E adevarat ca va apare astfel o joncţiune suplimentară.

b) o singură tabelă care include toate atributele (cazul amintit de catre tine)

c) câte o tabelă pentru fiecare subclasă =>

 

Monitor(CodProdus - CheiePrimara, Denumire, Tip, Diagonala, DimensiunePunct, ...)

Caiet(CodProdus - CheiePrimara, Denumire, NrPagini)

Alta solutie de proiectare a bazei de date ar presupune crearea urmatoarelor tabele:

Produs(CodProdus - CheiePrimara, Denumire)

Caracteristica(CodCaracteristica - CheiePrimara, Denumire)

CaracteristicaProdus(CodCaracteristicaProdus - CheiePrimara, CodProdus - CheieExterna, CodCaracteristica - CheieExterna, Valoare) (CodProdus + CodCaracteristica index cu valori unice si nenule daca caracteriticile sunt monovaloare)

E adevarat ca solutia de mai sus:

[1] nu este 100% in spiritul modelului relational,

[2] presupune 2 joncţiuni suplimentare,

[3] este cea mai flexibilă (îmi permite chiar să adaug noi caracteristici dinamic, fară a fi necesară modificarea codului sursă a aplicaţiei client la adăugarea unei noi caracteristici). 

... alte soluţii ... de proiectare / implementare.

 

 

 

Bogdan citeste articolul asta: And the EAV winner is .... sparse columns  si putem continua discutia

---

Cristian Andrei Lefter, SQL Server MVP
MCT, MCSA, MCDBA, MCAD, MCSD .NET,
MCTS, MCITP - Database Administrator SQL Server 2005
http://sqlserver.ro

Sa zic ca as fi vrut sa fiu pa acolo ? Sau se subintelege
Ceva webcasturi sau materialele de prezentari poate ? Vorba aia daca nu e de "real thing"... 

O sa fac screencast-uri cu continutul prezentarii mele.

---

Cristian Andrei Lefter, SQL Server MVP
MCT, MCSA, MCDBA, MCAD, MCSD .NET,
MCTS, MCITP - Database Administrator SQL Server 2005
http://sqlserver.ro

Oricum ca sa intelegi despre ce e vorba - printre altele am afirmat ca nu sunt foarte increzator in Entity Data Model si in LINQ luate ca solutie pentru aplicatii Enterprise. Astept sa vad daca va fi adoptat cu adevarat acolo unde scalability, availability, reliability (etc) sunt critice.

Strict la feedback-ul lui Bogdan exista o noua functionalitate in SQL Server 2008 denumita Sparse Columns (si asociata o alta functionalitate Filtered Indexes). Citeste articolul lui Bob pentru mai multe detalii.

---

Cristian Andrei Lefter, SQL Server MVP
MCT, MCSA, MCDBA, MCAD, MCSD .NET,
MCTS, MCITP - Database Administrator SQL Server 2005
http://sqlserver.ro

Scenariile de tipul "90% of the column values would be NULL" imi sugereaza o problema ... de proiectare a bazei de date in mod special atunci cand numarul campurilor de acest tip este mare (adica tocmai scenariul la care se adreseaza  aceasta noua functionalitate). Nu vreau sa fiu gresit inteles: nu sunt total impotriva unei astfel de functionalitati.

XML trebuie sa fie (opinie personala) utilizat doar pentru transferul datelor si nu pentru stocare/memorare.

Un fel de concluzie: "I even had the opportunity to ask Joe Celko (no fan of EAV) which he prefers, trying to ease him towards the "model as XML" mechanism. He stood up for sparse tables (solutiile a si c) or sparse columns (solutia b)."

Cred ca solutia cea mai simpla la problema asta folosind sqlserver ar fi

codprodus varchar, pk denumire varchar,caracteristici xml

Unde structura xml-lui de caracteristici ar putea fi urmatoarea:

<caracteristici>

<caracteristica id=0 name=" " value= />

 

.

</caracteristici>

---

Secolul XXI ori va fi religios ori nu va fi deloc

crestinul:

Cred ca solutia cea mai simpla la problema asta folosind sqlserver ar fi

codprodus varchar, pk denumire varchar,caracteristici xml

Unde structura xml-lui de caracteristici ar putea fi urmatoarea:

<caracteristici>

<caracteristica id=0 name=" " value= />

 

.

</caracteristici>

În ce formă normală va fi tabela asta ? 

Trebuie neaparat sa fie.?Normalizarea ,ca si xml de altfel sau oop nu e cheua rezolvarii tututor problemelor,trebuie sa mai faci si compromisuri asa un pic

---

Secolul XXI ori va fi religios ori nu va fi deloc

 Unde gasesc prezentarea lui Sebi de sambata ?

 

Merci! 

---

MCSE;MCITP

crestinul:

Trebuie neaparat sa fie.?Normalizarea ,ca si xml de altfel sau oop nu e cheua rezolvarii tututor problemelor,trebuie sa mai faci si compromisuri asa un pic

Modelul relational are anumite limite, fara indoiala. Totusi atat timp cat modelul relational iti ofera solutii (vezi primele 3 solutii) de ce sa ne complicam viata folosind XML ?

Salutare, as dori si eu prezentarea facuta de Sebi. Cum pot sa intru in posesia ei?

B_gd_n[ ]Sahlean:

crestinul:

Trebuie neaparat sa fie.?Normalizarea ,ca si xml de altfel sau oop nu e cheua rezolvarii tututor problemelor,trebuie sa mai faci si compromisuri asa un pic

Modelul relational are anumite limite, fara indoiala. Totusi atat timp cat modelul relational iti ofera solutii (vezi primele 3 solutii) de ce sa ne complicam viata folosind XML ?

Pai rezolvarea problemei asa mi se pare ca e cam limitatata ,imagineaza-ti ca ai o baza de date cu produse de categorii cat mai variate ,o sa faci o tabela pt fiecare tip,daca acest tip nu e cunoscut in faza de design a aplicatiei ce se intampla?

---

Secolul XXI ori va fi religios ori nu va fi deloc

crestinul:

B_gd_n[ ]Sahlean:

crestinul:

Trebuie neaparat sa fie.?Normalizarea ,ca si xml de altfel sau oop nu e cheua rezolvarii tututor problemelor,trebuie sa mai faci si compromisuri asa un pic

Modelul relational are anumite limite, fara indoiala. Totusi atat timp cat modelul relational iti ofera solutii (vezi primele 3 solutii) de ce sa ne complicam viata folosind XML ?

Pai rezolvarea problemei asa mi se pare ca e cam limitatata ,imagineaza-ti ca ai o baza de date cu produse de categorii cat mai variate ,o sa faci o tabela pt fiecare tip,daca acest tip nu e cunoscut in faza de design a aplicatiei ce se intampla?

Scenariile de tipul " ...  daca acest tip nu e cunoscut in faza de design a aplicatiei ce se intampla ... " imi plac la nebunie.

Intreb si eu atunci: ce faci de exemplu daca initial nu a existat o cerinta  de genul "trebuie ca pentru produsele electronice sa memoreze in  baza de date poza" dar dupa darea in exploatare a sistemului (dupa 3/4 luni) clientul  solicita o functionalitate de genul asta ? Memorezi imaginea tot in campul xml ? Intreb si eu ...