Welcome to Sign in | Join | Help
in Search

Feedback Intalnire 20 Octombrie 2007

Last post 10-30-2007, 9:31 AM by Julius. 28 replies.
Page 1 of 2 (29 items)   1 2 Next >
Sort Posts: Previous Next
  •  10-21-2007, 6:38 PM 3014

    Feedback Intalnire 20 Octombrie 2007

    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
  •  10-21-2007, 8:43 PM 3018 in reply to 3014

    Re: Feedback Intalnire 20 Octombrie 2007

    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.

     

     

     

  •  10-21-2007, 9:36 PM 3020 in reply to 3018

    Re: Feedback Intalnire 20 Octombrie 2007

    Bogdan citeste articolul asta: And the EAV winner is .... sparse columns  si putem continua discutia Smile
    Cristian Andrei Lefter, SQL Server MVP
    MCT, MCSA, MCDBA, MCAD, MCSD .NET,
    MCTS, MCITP - Database Administrator SQL Server 2005
    http://sqlserver.ro
  •  10-21-2007, 9:51 PM 3022 in reply to 3020

    Re: Feedback Intalnire 20 Octombrie 2007

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

  •  10-21-2007, 10:05 PM 3023 in reply to 3022

    Re: Feedback Intalnire 20 Octombrie 2007

    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
  •  10-21-2007, 10:10 PM 3024 in reply to 3022

    Re: Feedback Intalnire 20 Octombrie 2007

    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
  •  10-21-2007, 10:21 PM 3025 in reply to 3020

    Re: Feedback Intalnire 20 Octombrie 2007

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

  •  10-21-2007, 10:49 PM 3027 in reply to 3025

    Re: Feedback Intalnire 20 Octombrie 2007

    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
  •  10-21-2007, 11:58 PM 3028 in reply to 3027

    Re: Feedback Intalnire 20 Octombrie 2007

    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 ? 

  •  10-22-2007, 7:15 AM 3029 in reply to 3028

    Re: Feedback Intalnire 20 Octombrie 2007

    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 Smile
    Secolul XXI ori va fi religios ori nu va fi deloc
  •  10-22-2007, 12:41 PM 3032 in reply to 3029

    Re: Feedback Intalnire 20 Octombrie 2007

     Unde gasesc prezentarea lui Sebi de sambata ?

     

    Merci! 


    MCSE;MCITP
  •  10-22-2007, 6:39 PM 3051 in reply to 3029

    Re: Feedback Intalnire 20 Octombrie 2007

    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 Smile
    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 ?
  •  10-22-2007, 7:58 PM 3054 in reply to 3014

    Re: Feedback Intalnire 20 Octombrie 2007

    Salutare, as dori si eu prezentarea facuta de Sebi. Cum pot sa intru in posesia ei?
  •  10-22-2007, 7:59 PM 3055 in reply to 3051

    Re: Feedback Intalnire 20 Octombrie 2007

    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 Smile
    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
  •  10-22-2007, 8:55 PM 3056 in reply to 3055

    Re: Feedback Intalnire 20 Octombrie 2007

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


     

Page 1 of 2 (29 items)   1 2 Next >
View as RSS news feed in XML
Powered by Community Server (Commercial Edition), by Telligent Systems