07. oktober 2010 - 13:34Der er
13 kommentarer og 2 løsninger
Design af database med dynamiske felter
Jeg skal igang med at implementere et system, hvor jeg får brug for at kunne lave "dynamiske felter". f.eks. et varekatalog hvor en skærm har nogle specifinationer, mens en mus har andre specifikationer. Disse specifikationer skal være søgbare.
Men hvordan løser jeg det "pænest" i MS SQL 2008?
Jeg har selv følgende tanker:
1. bruge et XML datafelt til lagering af de dynamiske felter. Men hvordan performer det og er det søgbart?
2 lave en tabel hvor disse parameter gemme med en reference til varen (Logitech MX...) og en reference til typen (Mus)
3 ? andre gode forslag?
Det skal performe rimelig godt, jeg tror at vare databasen ca. kommer til at indeholde mellem 1.000 og 40.000 poster.
Nu ved jeg ikke hvordan du vil spørge i data, men der er flere muligheder. Når du har et sted imellem 1000 og 40.000 poster så kan du holde det uden videre i hukommelsen. Det er 40mb hvis hver post fylder 1kb og det er en stor post så :) Anyway.. det kan jeg altid hjælpe dig med... performance :)
Men smid egenskaberne/ produktattributterne i XML :) og så naturligvis ellers holde produktid, pris osv. som man normalt gør.
Ellers det andet du er ude i er en key-value og det er ikke ligefrem det en relationel database er kendt for at performe specielt godt i *LOL*
Et andet argument for at undgå key-value er at dataen der kommer retur kommer med en masse redundant data, medmindre du laver en spørger flere gange. Men ligegyldigt om du spørger flere gange vil key-value altid komme som key-value og det betyder at du "somewhere" skal omdanne data til noget bla bla mapping... bla bla... hvorimod XML *hiphip* her vil du formentligt blot smide en XML på, nemt og ligetil.
At spørge direkte i XML'en er også hurtigt, det kan både indexeres, FullText mv. men ellers så som jeg foreslog.. hold det hele i memory :)
Der er ingen tvivl om at XML datatypen er en fremragende "ny" ting i MSSQL - men jeg vil umiddelbart mene, at når vi arbejder med relationelle data bør de også gemmes relationelt. Selvom der godt kan lægges noget index på XML'en tvivler jeg på at det hastighedsmæssigt kan leve op til hastigheden på en relationel opbygning - specielt ved større søgninger. Ligger data i XML bare for at blive vist er det næppe et problem omend jeg kunne forestille mig at det udviklingsmæssigt vil tage lidt længere tid at lave - men den bedste både hastighed og fremtidssikring mener jeg uden tvivl ligger i relationstabeller.
Jamen jeg tror nu ikke vi er uenige, relationelle data bør gemmes relationelt. Dynamiske felter er ikke relationelle, men derimod 100% oplagt til Xml. At lave en tabel med key-value er ikke relationelt, men mere NoSql, eks.vis Redis eller Berkeley.
Hvis man smider et index på performer det ganske hæderligt, vi snakker millisekunder her. Når Xml'en samtidigt skal bruges i søgeøjemed så er det eminent at lægge full text search på og så har vi altså normal søgehastighed. FTS slår naturligvis ikke simple typer imod eksakte værdier, men fælles metadata bør også stadig holdes som normal relationel data, eks.vis produktid, pris, lagerbeholdning, leverandørnummer mv.
Mht præsentation, så tager det altså ikke mange minutter at lave en XSLT, den er samtidigt så fleksibel og i sagens natur kan denne ændres uden at recompile. Det må da betegnes som fremtidssikkert :)
Jeg vil altid anbefale Xml til dynamiske attributter, i særdeleshed når vi ikke snakker mere end et par millioner poster.
ER der nogle krav til det xml som jeg smider i MS SQL, kan jeg bare seralisere et object og dumpe det i xml feltet? eller kræver det lidt mere struktur for at få det til at performe godt?
jeg er for så vidt ikke uenig janus - men så tror jeg at vi læser opgaven forskelligt fra hinanden, for selvom der bliver skrevet "dynamiske" felter lyder det i mine øjne stadig til at være bedst angrebet relationelt.
Det er altid godt at have struktur på sin XML - så er det muligt for dig at lave et skema vil det nok være at foretrække.
Jeg har det sådan lidt at når man bare skal opbevare data som bruges i præsentationslaget og ikke ligefrem aggregere, summere mv. på det så er Xml meget egnet. Men jeg finder det meget svært at tale om uden et konkret eksempel.
pnr-> Lige for at spørge... Du vil serialisere frem og tilbage, men... de data som skal serialiseres, hvor skal du bruge dem? og hvordan?
Vil du deserialisere og herefter binde data til præsentation? Eller sige lydLabel.text = myObject.Lyd, typeLabel.Text = myObject.Type fordi objektet er af typen Hovedtelefon?
jeg skal bruge de ekstra data på nogle personer. dvs. at jeg opretter x-antal personer med navn, adresse, postnr osv (obligatoriske felter). På disse personer kan der så være nogle ekstra parametre f.eks. antal børn, har løbet marathon osv. Disse parameter er forskellige fra kunde til kunde (Jeg bruger samme kode for alle kunder, men hver kunde har sin egen database). Min tanke er så for hver kunde at lave et "object" til disse parameter. Fordi at jeg taler performance, er fordi at jeg skal bruge disse parameter til noget statistik.
Men når jeg nu tænker nærmere over det, kunne modellen med 3 tabeller måske være den rigtige løsning, for så kunne jeg oprette de dynamiske parametre uden at skulle kode.
@janus Mht. det skema, hvad mener du så med at det kan klare vha.et interface på objectet, kan du give et eksempel på det?
Ja, altså som jeg har sagt, så hvis du skal bruge data til andet end præsentation som skal kunne søges frem så skal du nok bruge andet end Xml. Jeg nævnte kort summation, aggregering mv. nu nævner du jo statistik, så teknikken KS kom med vil være bedre egnet hvis du skal lave statistikken på db-niveau. Det som du skal overveje er om du skal trække alt data ud og lave statistik i C# eller ej.
Dynamiske attributter i C# kan nu sagtens laves med at dictionary eller lign. key-value :)
Med et interface på objektet mener jeg blot at det på den måde sikrer dig at du har en lille garanti for at de påkrævede attributter er til stede, Name, Id, Color mv. Hvis du bruger keyvalue så kan du ikke sikre attributterne, så det er sådan lidt hip som hap tror jeg. Det er sådan en slags poor man schema *GG*, uden at kode noget selv som validerer det serialiserede objekt.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
