Salut
Primul meu post si o intrebare :)

Cat de recomandat ar fi unui utilizator de nivel incepator, mediu lucrul cu UDT(SQL 2005). Sau ar fi mai bine migrarea catre SQL 2008 si folosirea de User-Defined Table Types ?
Am creat un UDT in C# si am incercat sa-l implementez. Pana aici totul bine si frumos, doar ca m-au descurajat articolele si parerile citite (de ex nu prea am posibilitatea modificarii ulterioare a lui, decat drop tabels / modificare assemby / recreate tables).

M-am gandit la o alta varianta; migrarea catre SQL 2008 (adica costuri de upgrade) si definirea de tipuri de date de tip table ?
Care varianta ar fi mai ok  (stabilitate, intretinere etc) ?

Multumesc

De fapt, ce vrei sa faci, practic? UDT, DataTables etc sunt doar tool-uri ... Problema este ce vrei sa realizezi ....

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

Ideea este urmatoarea.

Am nomenclatorul de produse,iar fiecare produs are anumiti parametri. Din tot nomenclatorul numai 4-5 parametri sunt generali, restul parametrilor fiind specifici fiecarui produs.
Pot exista produse cu 12 parametri sau produse cu 42 de parametri (o mica exagerare).

Daca ar fi sa iau un exemplu :
 - Produs : "Pantofi". Parametri : Marime, Culoare, Compozitie (Piele, Sarma, Plasa etc), Cu siret/Fara siret, Categoria Calitate,  Brand etc

In functie de valorile parametrilor se determina cotele de adaos pe produs; Stocul de marfa trebuie tinut in functie de acesti parametri.

Sunt prea multe produse si prea multi parametri pentru a defini cate o coloana pentru fiecare parametru. De asemenea, rulajul este mult prea mare pentru a tine intr-o tabela separata fiecare intrare / iesire pe fiecare lot.

Sunt anumite produse care suporta transformare (intra albe si ies verzi de ex ... )

Singura varianta "normala" pe care am gasit-o este sa defines un tip de data (UDT) la care sa-i zic "ParProd" si care sa tina caracteristicile fiecaruia. Definesc 20 de coloane de tipul ParProd (de ex) si mi-am rezolvat problema.

Intrebarea mea era assembly sau Table Type ...

Sper sa fi fost mai clar de data asta.

Multumesc

Sparse columns, Sql server 2008?
http://msdn.microsoft.com/en-us/library/cc280604%28v=SQL.100%29.aspx

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

Nu as vrea sa definesc proprietatile in coloane. Daca as proceda asa, ar trebui definite coloane in tabela de articole, stocuri, intrari/iesiri.
In plus aparitia unor noi produse / proprietati ar duce la modificarea structurii bazei de date - in tabelele cele mai mari (intrari/iesiri).

Un tip de data array ar fi cel mai indicat ... Oricum, multumesc pentru raspunsuri.

In general evit sa dau raspunsuri care ocolesc problema insa nu am lucrat cu ce incerci tu sa lucrezi asa ca eu as fi abordat problema asta in felul urmator:

un tabel care contine caracteristicile generale si comune (cei 4-5 parametrii) cu un id unic ProdID si un al doilea tabel care sa contina un id unic ParamID, un foreign key ProdId si un al treilea camp cu parametrul efectiv. In felul asta vei avea o legatura one to many in care, la fiecare produs, vei avea un record cu parametrii generali si un set de recorduri cu parametrii specifici.

e un pic problematic cu citirea dar in schimb ai flexibilitate foarte mare la numarul de parametrii asa ca, la o prima vedere, mi se pare un compromis acceptabil.

La solutia asta m-am gandit si eu prima data. Doar ca mi se pare ca baza de date ar creste foarte repede; practic pentru o receptie de marfa a unui produs care vine pe 3 de loturi as avea un numar de 3 *nr de parametri. Daca o receptie are 10 produse,  ar insemna ca pentru o receptie sa tin 10 * nr_loturi * parametri.

Nu imi dau seama cat de mult ar creste baza de date dar sa tin si 100 de linii pentru o receptie mi se pare mult.  Vanzarea este sezoniera (mai-septembrie) dar volumul este destul de mare in perioada respectiva. Pot estima cumva dimensiunea bazei de date ?

diferenta de dimensiune este data de cele 2 campuri de id (PK si FK) din al doilea tabel

ca sa estimezi diferenta de dimensiune cred ca e suficient un calcul care sa tina cont de dimensiunea unui camp int (id-urile vor fi int) care are 4 octeti daca nu am insel deci la 1 record (parametru) creste dimensiunea cu 8 octeti (aproximativ) => o dif de aprox 8MB la 1000 de recorduri deci 800MB la 100k recorduri (asta este diferenta). calculul nu e foarte exact si se poate sa fie ceva greseli din cauza ca l-am facut doar ca idee.

daca vrei totusi sa reduci diferenta de dimensiune poti sa folosesti seturi de parametrii (4 param pe record de exemplu) - solutie care mi se pare "badarana" si nu ma incanta sau poti sa parsezi tu textul care il stochezi (caz in care poti pune toti param intr-un camp, separati de un delimitator pe care ti-l definesti tu si la citire folosesti o functie care sa parseze si sa ii puna intr-un array); in varianta a doua diferenta de dimensiune e data de dimensiunea delimitatorului care poate fi un singur char (am vazut intr-o baza ca se folosea ~ si parea sa functioneze)

edit:
C# are din cate imi amintesc functie care sa separe un string intr-un array folosind un delimitator dat ca si parametru. asa ca solutia cu array intr-un camp mi se pare rezonabila

Intr-adevar in C# pot tranforma foarte usor un string in array si invers. Ca si diferenta intre varianta asta si cea aleasa de mine as puncta faptul ca orice raport, functie, procedura dezvoltata ar trebui mai intai sa faca acest split (in SQL Server)  si apoi sa extraga datele de care am nevoie + tot timpul trebuie sa fac conversia intre string si float.
daca parametrul
Pe de alata parte, folosind un assembly totul devine mult mai simplu se reduce la a specifica  - Select [Denumire camp].[Cod Parametru].
Initial ma gandisem la varianta care ai precizat-o, dar am ales varianta assembly pentru ca mi-i mai or sa o "standardizez" si apoi mi se pare mai eleganta si pentru diverse rapoarte mi se pare mult mai la indemana.

Pe varianta de sir ar trebui sa retin ori cod_parametru:valoare; ori sa pun absolut toti parametrii intr-o ordine predefinita si sa nu completez nimic daca parametrul nu se plaica produsului. Astfel as putea sa am un sir ceva de genul - MARIME:42:CULOARE:ROSU:TIP_GULER::COLECTIE:: etc sau 42:ROSU::::

Revenind la intrebarea mea initiala, solutia cu assembly mi se parea cea mai eleganta/practica doar ca din ceea ce am citit nimeni nu o recomanda. M-ar interesa parerea voastra vis a vis de folosirea sau nu a acestor tooluri / tipuri de date.

Multumesc inca o data pentru raspunsuri

din pacate nu am lucrat cu ceea ce zici tu dar in mod cert m-ai facut curios.

daca se poate sa postezi codul de c# care l-ai scris pt chestia asta si linkurile de unde te-ai documentat o sa am un punct de plecare si sanse mai mari sa imi fac o idee.

legat ce ziceai despre string, da, ai dreptate: tb si numele parametrului si "valoarea" (lucru valabiul si pt solutia care am propus-o eu cu un record pt fiecare parametru, caz in care diferenta de dimesiune ar creste considerabil) dar exista "ocolisuri" si pt treaba asta.

oricum, din ce ai scris e clar ca ai analizat destule variante si atata timp cat nu cunosc mai bine contextul (respectiv ceea ce ai facut in C# pana acum si articolele care le-ai citit) sansele sa iti pot da o idee decenta care sa iti fi scapat sunt mici

Raspund cu intarziere pentru ca am fost plecat din oras.

De unde m-am inspirat
http://www.codeproject.com/KB/database/UserDefDataTypes.aspx

Discutii despre ...
http://stackoverflow.com/questions/657568/how-cool-are-user-defined-data-types-in-ms-sql-server
http://www.sqlservercentral.com/articles/SS2K5+-+CLR+Integration/userdefineddatatypesinsqlserver2005/1979/

Altceva ...
http://www.mssqltips.com/tip.asp?tip=1628 (direct din sql)

Pentru partea de cod m-am inspirat de mai sus
Uite aici proiectul meu : https://rapidshare.com/files/2111806662/CustomTypes.zip

Oricum, multumesc pentru interesul acordat :)

Mi se pare compliocata abordarea ta,ai putea incerca un xml cu caracteristicile produselor o coloana de tip xml,sau pe 2008 studiaza sparse columns

---

Secolul XXI ori va fi religios ori nu va fi deloc

hmmm ... intr-adevar XML cred ca ii varianta cea mai buna; mi-i ciuda ca nu m-am gandit  :)
 

Va recomand sa parcurgeti urmatorul articol al lui Bob Beauchemin pe tema EAV (Entity-attribute-value): http://www.sqlskills.com/BLOGS/BOBB/post/And-the-EAV-winner-is-sparse-columns.aspx
E posibil sa va dea o alta perspectiva.

---

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

Cum zicea Andrei ori faci spar columns daca ai 2008 asta insemna sa definesti cate o coloana pt fiecare caracterisitca a produsului sau iti poti defini o coloana de tip xml in care iti tii caracteristicile variabile ale produsului

---

Secolul XXI ori va fi religios ori nu va fi deloc