Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Problem trajnosti podataka

[es] :: MS SQL :: Problem trajnosti podataka

[ Pregleda: 1903 | Odgovora: 2 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

skyforever
bg

Član broj: 85533
Poruke: 72
91.185.100.*



Profil

icon Problem trajnosti podataka28.08.2010. u 11:17 - pre 165 meseci
Mozda nisam najbolje definisao temu, ali radi se o sledecem:

(Klijentska aplikacija je C# destkop, baza MS SQL 2005) Korisnik unosi razne sifarnike, podesavanja, elemente i na kraju treba da dobije jednu listu. Ta lista sadrzi spisak elemenata sa podelementima i nekim stavkama kao najnizim u hijerarhiji. Stavke mogu da sadrze stavke druge vrste. Tu cu i neke cene, jedinice mere i ostalo.
Poenta je da kada korisnik kreira tu listu, vise nista od tih stavki ne sme da se menja. Sa druge strane, korisnik ce zeleti da kreira neku drugu listu, sa istim stavkama, ali ce se mozda neke cene ili nazivi promeniti za tu novu listu, ali u staroj moraju da ostanu iste.
Razmisljao sam o nekoliko pristupa, ali nisam siguran sta je najbolje. Dosao sam i do toga da koristim LINQ to XML pa da eksportujem u XML sve tabele koje mi trebaju, tako da korisnik moze da menja originale, ali meni kopije uvek ostaju. Ili da napravim potpuno iste tabele, pa da upisujem u njih. Princip je isti, samo su tehnologije razlicite. Medjutim, radi se o velikom broju tabela i nasao sam da nijedan od ta dva pristupa nije bas najbolji. Posebno sa aspekta odrzavanja koda.

Zatim sam mislio, posto vec kreiram razne izvestaje i izvlacim i poslednji detalj, da to upisem u XML fajl, pa da to koristim, ali ne mogu (ili ne znam kako) da kreiram fajl iz stored procedure.

Sa druge strane, mora da postoji mogucnost da korisnik, nakon cuvanja liste, dodaje nove stavke, ili brise postojece.

Pokusacu da dam bolje objasnjenje ukoliko ovo nije jasno, ali ako neko ima iskustva sa takvim problemima, voleo bih da cujem nekakav predlog, savet...

Hvala
 
Odgovor na temu

Zox
Belgium

Član broj: 4402
Poruke: 197
..yconnect.schedom-europe.net.



+1 Profil

icon Re: Problem trajnosti podataka31.08.2010. u 23:04 - pre 165 meseci
Hm. Nisam siguran da sam najbolje razuleo ali evo kako ja to radim (ako sam razumeo).
Objasnicu ti na primeru sa proizvodima i cenama.

Sitaucija: imam listu proizvoda. Imena proizvoda su fiksna kao i jos neke karakteristike (tezina, gabariti...). Medjutim cene su razlicitite za nekih 10 razlicitih marketa koje imam u EU.

Tabela 1: Products
sadrzi nazive i druge fixne elemente vezane za proizvod. Ali ne i cene
prod_pk, prod_name, prod_lotnumber.....
1 cipela 123456

Tabela 2: Marketi
mark_pk, mark_name....
1 Spanija
2 Italija

Tabela 3: Cene (koje su "in relation to product to market)"
ovde pisem cene za svaki proizvod po marketu ali uvodim i vremensko trajanje tako da mogu da cuvam sve promene cena zbog istorije tako da mogu lako da nadjem koja je danasnja vazeca cena ali i koja je cena bila za cipelu u Spaniji u 2009 godini.

pric_pk, pric_inretomarket, pric_inretoproduct, pric_cena, pric_validfrom, pric_validtill
1 1 1 10.00 2009-01-01 2009-12-31
2 2 1 12.00 2009-01-01 2009-12-31
3 1 1 17.00 2010-01-01 2010-12-31
4 2 1 20.00 2010-01-01 2010-12-31
..........

Nazalost moraces da imas posebne tabele za svaki promenjivi element i jednu tabelu za neku entitet koji je referenca za sve ostale. Pazi, ne kopije originalne tabele nego posebne tabele za svaki element koji se menja.
Pogledaj malo Normalizacija Tabela. Moraces da "isparcas" na posebne tabele jer to i jeste princip relacionih baza.

Jesam li razumeo tvoj problem?
 
Odgovor na temu

nadavesela
programer, DZS

Član broj: 199298
Poruke: 93
*.205.17.179.robi.com.mk.



+3 Profil

icon Re: Problem trajnosti podataka09.09.2010. u 10:25 - pre 165 meseci
Iako ne znam detaljnu problematiku, pokusacu da dam ideju, malo van normalizacije, a da se ima evidencija svakog reda preko Id kao vestackog kljuca.
Ako se Lista (dobivena kao rezultat bilo cega , ili se ima iz nekog view, UDF) zapise u tabelu
ListaPromena ( Id, Lista,Stavka, Cena, Proizvod, PrethodniId, TiPromene,Datumpromene, Aktivna,VlasnikListe)
PocetnaLista kao i Promene nad listom se mogu evidentirati.
Id bi bio vestacki kljuc koji bi dalje bio veza ove tabele sa ostalim tabelama
A ostale kolone vecim delom su ustvari Id iz odgovarajucih referentnih tabela.
Stavka bi bio neki kljuc Liste (znaci bitni atributi koji razlikuju svaku stavku liste, ili ako je ta lista u nekoj drugoj tabeli koja ima vestacki kljuc, onda bi mogao da bude taj kljuc koji jednoznacno odredjuje red te tabele)
Cena i Proizvod su kao primer onih atributa koji mogu da se menjaju i koji se evidentiraju ( a shodno tome mogu biti Id iz neke tabele gde se na jednom mestu vodi sifrarnik proizvoda)
PrethodniId bi ukazivao na Id (red) iz ListePromena nad kojim je izvrsena promena. Za pocetnu listu isti bi imao vrednost 0. Obrisan zapis bi shodno tome bio dodat u tabeli ListaPromena kao neaktivan (deaktiviran) za novog VlasnikaListe, a u PrethodniId bi se upisao Id reda koji se brise.
Isto i pri btinoj izmeni odredjene stavke iz pocetne liste, novi red se dodaje, a u kolonu PrethId se upisuje Id reda koji se menja. Pri tome se ima evidenicja koji red prelazi u koji.
Pocetna lista su oni redovi koji pripadaju pocetnom Vlasniku.
Svaki VlanikListe svoju listu gleda kao Select svojih aktivnih redova (Kazem svojih aktivnih redova, jer VlasnikListe moze cuvati evidencije nad izmenama stavki iz svoje liste.) i onih PocetnogVlasnika ciji Id nije u koloni PrethId VlasnikaListe. (Znaci oni koji pripadaju PocetnomVlasniku a nisu promenjeni od strane VlanikaListe).
Kolone TiPromene,Datumpromene, Aktivna,VlasnikListe su vec dovoljno asocijativne ili spomenute.
Jedina sugestija je sto pri evidenciji izmena sam korisnik treba da izabere dali su promene bitnog tipa ili su takoreci tehnickog (znaci korekcija tipa pogresnog unosa, ne treba se upisivati kao nov red, nego samo izmena koregovanih kolona nad redom koji je pogresno unesen)
Glavna ideja je da igrajuci se identifikatorima reda, mozete pratiti istorijat promena i imate mogucnost razlicitih prikaza (za sta najcesce koristim UDF Table Valued Functions jer imaju mogucnost parametrizacije), a i imate direktnu vezu istorijskog cinjenicnog stanja kad je taj red (Id) upotrebljen kao veza (relacija) u nekoj drugoj tabeli.
Izmene nad Pocetnom listom mogu se spreciti ili preko proceduralnih uslova, ili cak i particijom tabele prema koloni VlasnikListe, stim da se ona particija PocetnogVlasnikaListe smesti u file grupu koja je read only.
 
Odgovor na temu

[es] :: MS SQL :: Problem trajnosti podataka

[ Pregleda: 1903 | Odgovora: 2 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.