Mislim da ti tu ne treba nova kolona nego napravis dve nove tabele, jedna koja ce sadrzati opis, drugu koja ce sadrzati tip i onda bi imao nesto kao

IdProizvoda, (svi tvoji stari podaci), IdOpisa


druga tabela bi imala opis
IdOpisa, TipOpisa i Opis

i treca bi sadrzala sve tipove opisa
TipOpisa, Naziv


i u tu trecu tabelu bi stavio npr:
1, Snaga
2, Fabricki Broj
itd

Ako bi jedan proizvod trebao da sadrzi vise tih 'opisa' mozes dodati trecu tabelu koja bi samo premostavala Proizvod i Opis. Nadam se da sam bio jasan, ako ne, daj nekoliko realnih primera i pokusacu da ti napravim dijagram.

Fedya, pre svega hvala na ukljucivanju u diskusiju.
Nism te dobro razumeo ili ti mene nisi dobro razumeo, postoji vise primera gde
ovo treba primeniti, recimo:
1. Osnovna sredstva i alat.
Zajednicko im je na primer:
Inventarni broj (PK), Naziv, ........ dok
ako je os. masina ima sledece kolone
instalisanaSnaga integer,
fabrBroj varchar(25)
...........
ako je os. zgrada ima sledece kolone
DatumZavrsetkaIzgradnje Date,
DatumTehnPrijema Date,
Sparatnost integer,
PovrsinaSparata integer,
UkupnaPovrsina integer
..............
Ovde je ovo lako resiti sa subtipovima, medjutim ..........
ako se pojavi nova vrsta os. koja ne moze da se uklopi u
neki od navedenih setova podataka, a i glupo je da se u
jednoj ozbiljnoj bazi nesto tako improvizuje, tu nastaje
relativno veliki problem, traba ponovo projektovati bazu, odnosno
dodati subtipsku tabelu, ispravljati trigere, ispravljati stored
procedure i na kraju dodavati, ili ispravljati korisnicki interfejs.
2. Drugi ocigledan primer predstavljaju dokumenta.
Zajednicko im je na primer:
vrstaDokumenta (pk) char(2),
BrojPrijema (pk) varchar(20),
Naslov nvarchar(255),
Author nvarchar(255),
...................
ako je dokument ugovor tada mu trebaju sledece kolone:
VrstaUgovora char(2) - ovde treba da ima reletionship sa tabelom vrsta ugovora
predmetUgovora varchar(255)
Komitent varchar(7)
.........
ako je dokument faktura tada mu trebaju na primer:
brojOtpremnice varchar(x),
brojPrijemnice varchar(x),
osnovicaZaPDV numeric(18,2),
PDV numeric(18,2)
........
Ako bi resavao ovo sa subtipskim tabelama imao bih problem
konacnosti broja tabela i indexa slozenosti projekta.

Nadam se da sam bio jasan, i da mi je jasno da je MS SQL relaciona a ne objektna baza.

Ovo nije bas 100% tacno, bar ne vise. XML omogucava drzanje serializovanih objekata u tabelama i njihovu obraadu i citanje preko xquery-a







Na xml datatype mozes i da nalepis XSD semu koja ce kontrolisati unos podataka i brat bratu mozes SVE svoje objekte da drzis u jednoj tabeli. AKo xml ogranizujes tako da srodni objekti koji "nasledjuju" jedni druge imaju slicne podseme mozes i xquery da koristis za neke obrade na visem nivou granulacije.

postoje samo dva problema sa ovim, prvo T-SQL je ok za query-je ali ce aplikactivni nivo mnogo bolje da ti odradjuje generisanje i serijalizaciju objekata u xml, sto znaci malo vise posla na aplikaciji (sa druge strane ako koristis aplikativni nivo koji podrzava serijalizacije vec imas sebi odradjen posao konverzije podataka u objekte); drugo, nisam nikad koristi XQuery na nekom vecem nivou sa puno redova tako da ne znam koji je performance penalty za upotrebu istog, nesto mi se cini da value() primenjen na milion redova nije bas zanimljiv (al opet sa par hiljada redova sto sam ja koristio pokazao se odlicno).

_{[Ovu poruku je menjao mmix dana 30.11.2009. u 10:50 GMT+1]}

mmix, Hvala na odgovoru, ovo resava pitanje objekata, ali sta ce se dogoditi ako se javi potreba
dodatavanja novog atributa objektu
<data><sijalica><vati>60</vati><proizvodjac>Tesla</proizvodjac><radniCas>1000</radniCas></sijalica></data>
svi delovi aplikacije padaju u vodu, jer (mozda meni u ovom trenutku nije sasvim jasno) su query za
manipulaciju podataka fiksni i zasnivaju se na vec poznatim svojstvima koji su existirali u odredjenom
vremenskom trenutku, bilo da su pisani kroz t-sql ili sqlxml.

Pa moras da odradis migraciju podataka u novu semu i za to se koristi SQL DML:




ako koristis XSD validaciju, prvo dodas node kao optional, onda posle "migracije" ubacis kao obavezan i baza je opet spremna, modify DML moze da dodaje atribute i nodove, da im menja vrednosti i cak i da brise kompletne delove xml stabla tako da je moguce preformatirati sve.


sto se tice ostatka tvoje poruke mislim da imas malo prevelika ocekivanja, nijedan computing deo danas nema kognitivne sposobnosti i ocekivati da se sistem sam prestroji za sve moguce promene koje tebi padnu na pamet je malo previse, da ne pominjem ocekivanje intelektualnog rezonovanja cemu zapravo sluzi dodato polje i kako se ono u T+1 trenutku uklapa sa stanjem sistema u trenutku T, mnogo smo mi daleko od toga a kad taj trenutak i dodje ja i ti necemo lupat glavu oko toga , moze samo skynet da polupa nase glave

Imas sisteme koji su manje ili vise zeznuti za prosirivanje ali kako god da okrenes ne gine ti dodatni posao niti mozes povecavati kompleksnost sistema bez da on postane kompleksniji.

mmix, Hala na odgovoru. Kraj diskusije.