Srodne teme

14.04.2024. Re: Gde je Kejt? (samo pogrešni odgovori)
06.02.2004. Kako napraviti izvjestaj u delphiu
22.06.2004. Izvjestaji... nikad kraj
08.02.2005. FireBird: problem sa COMPUTED BY kolonom
11.03.2005. Kako napraviti niz datuma od DatumOd do DatumDo
02.02.2006. Pomoc Oko Izvoza U XML
30.04.2006. Crosstab Query i datumi
01.04.2008. SQL goup by Operator
09.04.2008. SQL DISTINCT naredba master/details
10.04.2008. SQL daje rezultat manje

Navigacija

Brisanje liste

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

Computed DatumDo

[es] :: MS SQL :: Computed DatumDo

Strane: 1 2 3

[ Pregleda: 6887 | Odgovora: 52 ] > FB > Twit

Autor

nadavesela
programer, DZS

Član broj: 199298
Poruke: 93
195.26.131.*

+3 Profil

Re: Computed DatumDo

^{07.04.2011. u 13:18 - pre 158 meseci}

Citat:

Kompjuteri nazalost imju UPDATE i DELETE komande i mi se uglavnom ne stitimo od toga. Istina, uglavnom je UDATE/DELETE par sakriven od korisnika, ali nije od programera

Hvala na interesovanju i cestitkama, a da ideja zahteva doradu, odnosno jos constrainta, i pukotina koja trazi resenje je sledeca:
DELETE nije moguc, ni Update kolone StariStatus, ali...kolonu DatumOd, Cenu, Naziv je moguce menjati u istoriskim podacima.
Ako pogodim Constaint za jednu od ovih kolona imam ga i za ostale.

Dok sa dodavanjem kolona u 'tvom' primeru, PRIMARNG KLJUCA

Code:

ALTER TABLE [dbo].[Status_HistoryES] ADD  CONSTRAINT [PK_Status_HistoryES] PRIMARY KEY CLUSTERED
(
    [StatusID] ASC,
    [DatumOd] ASC,
    [cena] ASC,
    [naziv] ASC
)WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF) ON [PRIMARY]

i referencijalnog integriteta

Code:

ALTER TABLE [dbo].[Status_HistoryES] WITH CHECK ADD CONSTRAINT [FK_Status_HistoryES_Status_HistoryES] FOREIGN KEY([StariStatus], [DatuOdStari], [CenaStara], [NazivStari])
REFERENCES [dbo].[Status_HistoryES] ([StatusID], [DatumOd], [cena], [naziv])

izmene nisu moguce, TAKO DA JE KUZNECOV IPAK VISHE U PRAVU, u smislu ogranicenja.
Sad mi je ideja u pravcu da te kolone koje ipak treba dodati, budu computed kolone koje kao Persisted, kreirane fizicki ne znam dal mogu ucestvovati u izgradnji referencijalnog integriteta. Probacu.

_{[Ovu poruku je menjao nadavesela dana 07.04.2011. u 15:39 GMT+1]}

_{[Ovu poruku je menjao nadavesela dana 07.04.2011. u 16:31 GMT+1]}

Odgovor na temu

nadavesela
programer, DZS

Član broj: 199298
Poruke: 93
195.26.131.*

+3 Profil

Re: Computed DatumDo

^{09.04.2011. u 08:48 - pre 158 meseci}

Pukotina u mom resenju se najednostavnije krpi trigerom

Code:

ALTER TRIGGER [Status_HistoryES_ZabranjenoUPDATE] ON [dbo].[Status_HistoryES] FOR UPDATE
AS
rollback

Na taj nacin je zadovoljen uslov da nikakve izmene nisu moguce nad vec upisanim podacima (redovima).
Delete je vec ogranicen Referencijalnim Integritetom izmedju StausId i StariStatus,
Insert je ogranicen Constraintima koji koriste UDF i koje mogu menjati i prilagodjavati saglasno potrebama,
a izbegavam fizicki upis podataka u kolone(StaraCena,StariNaziv....) koje vec imam u prethodnom zapisu i mogu ih dobiti u svakom momentu preko StariStatus i neke UDF.

Odgovor na temu

MarkoBalkan

Član broj: 141124
Poruke: 1624
46.188.218.*

+19 Profil

Re: Computed DatumDo

^{09.04.2011. u 21:06 - pre 158 meseci}

za @Zidar

zidar je stari baja koji zna puno toga, ali komplicira.

što se tiče tablica za history.

može se napraviti bez puno kompliciranja, recimo, nešto u stilu:

create table artikli (
artikli_šifra integer,
artikli_ime varchar(50),
artikli_opis varchar(200),
artikli_jm varchar(10)
)

create table artikli_cjenik(
artikli_šifra integer,
datumOd date,
datumdo date,
cijena double precision,
PRIMARY KEY (artikli_šifra,datumOD)
)

datum do stavimo recimo 2099.
za artikl za koji želimo dohvatiti cijenu, provjerimo da li se datum nalazi između DatumOd i datumDo.
npr.

Code:

INSERT INTO artikli(
            artikli_sifra, artikli_ime, artikli_opis, artikli_jm, artikli_tezina)
    VALUES (1, 'jabuke', 'jabuke 1 klase', 'kg');

INSERT INTO artikli(
            artikli_sifra, artikli_ime, artikli_opis, artikli_jm)
    VALUES (2, 'sok', 'sok od jabuke', 'kom');

Code:

INSERT INTO artikli_cjenik(
            artikli_sifra, datumod, datumdo, cijena)
    VALUES (1, '1.1.2011', '1.3.2011', 5.00);

INSERT INTO artikli_cjenik(
            artikli_sifra, datumod, datumdo, cijena)
    VALUES (1, '1.4.2011', '31.12.2100', 5.20);

ako bi sad za artikl sa šifrom 1 ubacili novu cijenu, prvo bi morali postaviti današnji datum (datumDo) i ubacili bi artikl sa novom cijenom
datumOd -> sutašnji datum, a datumDo bi stavili 2100 godinu.

i u svakom trenutku možeš saznati koja je bila cijena artikla u određenom periodu.

Code:

SELECT
  artikli.artikli_sifra,
  artikli.artikli_ime,
  artikli.artikli_opis,
  artikli.artikli_jm,
  artikli_cjenik.datumod,
  artikli_cjenik.datumdo,
  artikli_cjenik.cijena
FROM
  public.artikli,
  public.artikli_cjenik
WHERE
  artikli.artikli_sifra = artikli_cjenik.artikli_sifra;

1;"jabuke";"jabuke 1 klase";"kg";"2011-01-01";"2011-03-01";5
1;"jabuke";"jabuke 1 klase";"kg";"2011-04-01";"2100-12-31";5.2

ovo je napravljeno na postgresql-u.
ali princip je isti.

Odgovor na temu

nadavesela
programer, DZS

Član broj: 199298
Poruke: 93
195.26.131.*

+3 Profil

Re: Computed DatumDo

^{11.04.2011. u 08:04 - pre 158 meseci}

Posto zelim da se ideja shvati probacemo na konkretnim primerima:
Dali tvoje resenje dozvoljava nakon:

Citat:

INSERT INTO artikli_cjenik(
artikli_sifra, datumod, datumdo, cijena)
VALUES (1, '1.1.2011', '1.3.2011', 5.00);

INSERT INTO artikli_cjenik(
artikli_sifra, datumod, datumdo, cijena)
VALUES (1, '1.4.2011', '31.12.2100', 5.20);

Da neko u nekom buducem trenutku, nakon sto je dati artikl upotrebljen u nekim drugim tabelama (sa cenama u periodu vazenja ) izvrsi ovakve inserte:

Code:

INSERT INTO artikli_cjenik(
artikli_sifra, datumod, datumdo, cijena)
VALUES (1, '20.12.2010', '31.12.2010', 4.00);

ili pak

Code:

INSERT INTO artikli_cjenik(
            artikli_sifra, datumod, datumdo, cijena)
    VALUES (1, '15.1.2011', '15.2.2011', 6.00);
INSERT INTO artikli_cjenik(
            artikli_sifra, datumod, datumdo, cijena)
    VALUES (1, '16.2.2011', '28.2.2011', 8.00);

Dali to znaci da ce za fakture izdate na primer u periodu meseca januara postojati dve cene za artikl 1:
od '1.1.2011' do '1.3.2011' koja kaze 5.20
i druga od '15.1.2011' do '15.2.2011' koja kaze 6.00
i tu je sad pitanje validnosti vazenja datumdo, jer po toj logici cena 5.20 vazi do 14.1.2011.

_{[Ovu poruku je menjao nadavesela dana 11.04.2011. u 11:00 GMT+1]}

Odgovor na temu

MarkoBalkan

Član broj: 141124
Poruke: 1624
46.188.178.*

+19 Profil

Re: Computed DatumDo

^{11.04.2011. u 16:37 - pre 158 meseci}

provjeru staviš datumOd > (select max(datumD0) from artikli_cjenik where artikli_šifra=@šifra)

ovo možeš odraditi programski ili na proceduri.

Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.dsl.bell.ca.

+79 Profil

Re: Computed DatumDo

^{11.04.2011. u 21:00 - pre 158 meseci}

Marko, nisi shvatio poentu. Poenta nije uopste da se prati istorija promena da bi se videlo kad se sta promenilo. Poenta je da se garantuje kvalitet podataka, integritet ako hoces, tako da se sprece u najvecoj meri mogucnosti da nepazljivi UPDATE ili DELETE napravi stetu.

Ako zapisujem promene cene u obliku (ArtklID, Cena,VaziOdDatuma) to je sasvim dovoljno da mi da istoriju kroz nekakav kveri, ne treba mi nikakav DatumOD, DatumDo. I sve to lepo vazi dok se ne napravi greska na unosu. Greska je obicno takva da se tesko i otkriva. A podaci se u bazu unose na sve moguce nacina. Kroz aplikaciju X, kroz aplikaciju Y, bulk insert, kroz proceduru, direktno INSERT INTO narednom kroz SMS, na milion nacina. Naivno je verovati da se integritet podataka stiti programskim kodom, bilo u nekom programskom jeziku, bilo u stored proceduri, pa cak i trigeri nisu pravo resenje. Trigeri se ne aktiviraju uvek prilikom bulk insert. Naivno je reci da ce isert uvek ici kroz neku stored proceduru i samo tako. Ni ogranicenja kroz permissions nisu resenja, jer kako rekosmo, katastrofalne greske prave oni koji imaju permissions jako visokog nivoa. Nije retko da svi programeri u odeljenju imaju 'sa' privilegije. A ako i nemaju, nisu daleko od toga. Mogu da kreiraju objekte, izvrsavaju procedure i imaju write access podacima.

Jos je naivnije oslanjati se na sposobnosti programera da zastite podatke 'kroz kod'. Eto, ti nisi ni primetio sta se u stvari trazi, koji se problem resava, a ponudio si resenje koje je Nada istog momenta torpedovala jer ga je lako torpedovati.

Cela ova prica nije zapoceta da bi se sporili koji je najbolji nacin da se prati istorija cene ili naziva proizvoda. Primer je izabran jer je zgodan da se objasne principi jednog metoda koji se dalje moze nadgradjivati tako da donese velike koristi. O tome ce bitio vise reci na blog-sajtu BazePodataka, tokom narednih nekoliko nedelja.

Opet, na srecu ili nesrecu, data management nije regulisan zakonom kao inzinjerske grane i svako moze bukvalno da radi sta i kako hoce. Ako ti je metoda dosadna i prekomplikovana, niko te ne tera da je upotrebis.

Rekoh, radi ko sta hoce i kako hoce. Iako ne bi bilo zgoreg da su neke stvari propisane zakonom, na primer da sta sve ulazi u dokumentaciju i koji koraci i postupci moraju da se odrade i sta sve mora da se dokaze na papiru pre nego sto se projekat pusti u produkciju. Ni jedan gradjevinski projekat ne dobija zeleno svetlo dok se ne urade arhitektonski planovi, staticki proracun, proracun struje, vode knalizacije, grejanja i tako dalje. I nije dovoljno samo imati sve te dokumente, nego cela stvar ide na reviziju gde je nako placen da pronadje sto vise rupa u projektu. Pa se opet desi da padne poneki balkon i nakrivi se zgrada. Ali mnogo, mnogo manje nego broj softverskih resenja koja ili ne rade uopste ili ne rade kako se ocekuje da rade.

Odgovor na temu

nadavesela
programer, DZS

Član broj: 199298
Poruke: 93
195.26.131.*

+3 Profil

Re: Computed DatumDo

^{12.04.2011. u 10:44 - pre 158 meseci}

Posto sam generalno shvatila i zelim primenu metoda i nacina rada o kome je Zidar pisao, ipak imala bih da prijavim jos jednu rupu u mom resenju a Zidar ce nam reci dal je tako i u resenju Kuznecova, pa da vidim koja su moguca resenja.
Naime constraint koji je izmedju StasusId i StariStatusId, odlicno funkcionishe (ogranicava) kad brisem jedan po jedan zapis osim poslednjeg zapisa za dati artikl, al kad izvrsim naredbu

Code:
DELETE FROM dbo.Status_HistoryES

izbrise sve redove iz tabele.
Isto ogranicenje vazi za naredbu

Code:
DELETE FROM dbo.Status_HistoryES Where StariDatumOd is not null

Nadam se da jedino resenje nije triger koji radi revoke na DELETE za zapise ciji StariDatumOd is not null.
I to mi se vishe svidja (sto jednistavniji triger) nego programski ili proceduralni kod.
Sve Vas pozdravlja Vesela

Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.

+79 Profil

Re: Computed DatumDo

^{12.04.2011. u 15:56 - pre 158 meseci}

Kod Kuznetsova nije moguce obrisati sve redove odjednom. Na poslednjem redu za dati entitet, dozvoljene su promene 'novog stanja'. Taj red je moguce i obrisati. Ostale redove nije moguce obrisati jer FK to ne dozvoljava.

Mnogi ovo ne vole. Ako se zaista napravi greska negde na pocetku, recimo zaboravi se jedna promena, gresku je nemoguce ispraviti, niti je moguce obrisati sve pa ispocetka. Brisanje se radi jedan po jedan red, pa se onda ponovo sve insertuje. Alex ne preporucuje funkcije u FK jer tvrdi da se razlicito ponasaju kad imas single-row insert/update i kad imas multiple-row insert/update, u nekim slucajevima. Ja nisam uspeo da ove probleme sa funkcijama u FK potvrdim, ali nisam mnogo ni probao. alex kaze da je moguce dobiti false-positive i false-negative reakcije stranog kljuca, u nekim situacijama.

Sto se tice ispravke gresaka i masovnog brisanja, u nekim slucajevima Alex koristi MERGE komandu, ali to radi samo u SQL 2008 koji ja jos uvek nemam pa ne mogu da komentarisem.

Odgovor na temu

MarkoBalkan

Član broj: 141124
Poruke: 1624
46.188.226.*

+19 Profil

Re: Computed DatumDo

^{12.04.2011. u 16:38 - pre 158 meseci}

za @nadavesela i @zidar, da odgovorim

kreiramo funkciju i constraint

Code:

CREATE OR REPLACE FUNCTION provjera(integer)
  RETURNS date AS
'select max(datumDo) from artikli_cjenik where artikli_sifra=$1'
  LANGUAGE sql VOLATILE
  COST 100;
ALTER FUNCTION provjera(integer) OWNER TO postgres;

ALTER TABLE artikli_cjenik
  ADD CONSTRAINT proba CHECK (datumod > provjera(artikli_sifra));

ovo nam osigurava da se razdoblja za određeni artikl ne preklapaju.

što se tiče brisanja, zato postoje role, useri i prava na bazi da se definira tko što smije raditi.

tako da se sve može napraviti sa funkcijama i constraint-ima, a da se ne komplicira.

Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.

+79 Profil

Re: Computed DatumDo

^{12.04.2011. u 18:17 - pre 158 meseci}

Marko je u pravu, iako je u pocetku malo bio narogusen

Citat:

tako da se sve može napraviti sa funkcijama i constraint-ima, a da se ne komplicira.

Ne moze sa bas uvek sev napraviti, ali treba teziti tome. Ne vidim samo zasto su FK bez funkcija vise komplicirani nego FK sa funkcijama. neka to ostane stvar ukusa i testova brzine, vazno je da psotoje constraints

Citat:

što se tiče brisanja, zato postoje role, useri i prava na bazi da se definira tko što smije raditi.

To je sve OK, ali kako rekoh, podatke obicno sprzi neko ko ima odgovarajucu rolu i permission. I nikad namerno. Uglavnom se previdi nesto i poof - otisli podaci. Podaci se ne stite paswordima. To mozemo i u obicnom file sistemu, ne treba nam RDBMS za to.

Da sumiramo: ako ne postoje constraints, CHECK, FK, UNIQUE, sve ostalo ne garantuje integritete podataka. Podaci se ne stite ni programskim kodom - stored procedure i trigeri su programski kod, ako je bolje koristiti sp i trigger nego VB/C# kod za garantovanje integritete. UDF funkcije su negde na pola puta, ponekd korisne, ponekad opasne, ponekad brze, ponekad spore. Naravno, ima situacija kada se mora koristiti sto se ima i sto se ume, kad nema mnogo izbora. U svakom slucaju vredi sto vise alata imati u torbi, moze da zatreba.

Postoje situacije koje se ne mogu resiti onim sto nam trenutno nude proizvodjaci RDBMS. Koje ikad cuo za praznu fakturu? U realnom svetu faktura bez stavki je nemoguca. Fakture je celina koju cien zaglavlje i stavke. U RDBMS mi to razbijamo na dve tabele - Faktura i Stavke. Da bi stavka postojala, mora prvo da postoji faktura, tako kazu pravila normalizacije. Znaci, 'INSERT INTO Fakture' => evo je faktura bez ijedne stavke. Tek onda mozemo da radimo 'ISNERT INTO Stavke'. Ako iz nekog razloga dodje do prekida u radu, ostade nam faktura bez stavki - roditelj bez dece. Ne postoje constraints niti funkcije niti trigeri, nista sto moze da speci postojanje fakture bez stavki. U tom slucaju moramo da to odardimo na nivou stored procedure ili na nivou front end koda. Pocnemo TRANSakciju, pa ako ne unesemo stavke, onda ROLLBACK. Lepo. ali radi samo kroz stored proceduru ili kroz program. Masovni insert ili bulk insert ne radi ovako. Neki pametni ljudi trazili su vec da u SQL standard udje nesto sto se zove DEFERRED CONSTRAINT RESOLUTION, gde bi se ove stvari omogucile. Mi mozemo da ostavimo relaciju (relationship, ne relatin) 1: (nula ili vise) u SQL => ne mozemo da sperceimo 1: 0, bar u jednom kratkom vremenu. Za sada, ni jedan proizvodjac ne nudi nista na ovu temu. Isto kao sto ne nude pracenje istorije promene, pa da one duplicirane i komplicirane kolone budu sakrivene od korisnika, ali prisutne u sistemu i da se automastki popunjavaju.

A da je komplikovano, jeste, nije lako ni da se razume, ni da se primeni kad se jednom razume. Pa sta ako nije lako, one velike pare koje placaju DBA treba i da se opravdaju, niko nas ne samo placa da cuvamo lozinke.

Odgovor na temu

MarkoBalkan

Član broj: 141124
Poruke: 1624
46.188.226.*

+19 Profil

Re: Computed DatumDo

^{12.04.2011. u 19:04 - pre 158 meseci}

Citat:

Zidar
Da sumiramo: ako ne postoje constraints, CHECK, FK, UNIQUE, sve ostalo ne garantuje integritete podataka. Podaci se ne stite ni programskim kodom - stored procedure i trigeri su programski kod, ako je bolje koristiti sp i trigger nego VB/C# kod za garantovanje integritete. UDF funkcije su negde na pola puta, ponekd korisne, ponekad opasne, ponekad brze, ponekad spore. Naravno, ima situacija kada se mora koristiti sto se ima i sto se ume, kad nema mnogo izbora. U svakom slucaju vredi sto vise alata imati u torbi, moze da zatreba.

zašto se kod velikih enterprise aplikacija sve radi kroz orm mapiranje bez ičega na bazi osim referenci?
sustav je brz onoliko koliko je optimizirano sve.ako radiš query sa 10 funkcija, a svaka funkcija ima 10 query-a, naravno da bude sporo.
što se tiče skrivanja strukture, koriste se view-i(ili pogledi).
što se tiče bulk inserta, obraditi i pročistiti preko ETL-a i ubaciti ili učitati i obraditi preko procedure.

Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.

+79 Profil

Re: Computed DatumDo

^{12.04.2011. u 19:40 - pre 158 meseci}

Citat:

zašto se kod velikih enterprise aplikacija sve radi kroz orm mapiranje bez ičega na bazi osim referenci?

Ne razumem sta ovo znaci. Sta je 'orm' i sta je 'mapiranje bez icega na bazi osim referenci'?

Odgovor na temu

MarkoBalkan

Član broj: 141124
Poruke: 1624
46.188.226.*

+19 Profil

Re: Computed DatumDo

^{12.04.2011. u 20:00 - pre 158 meseci}

Citat:

Zidar: Ne razumem sta ovo znaci. Sta je 'orm' i sta je 'mapiranje bez icega na bazi osim referenci'?

http://en.wikipedia.org/wiki/Object-relational_mapping

zašto se to koristi, zato što je po nekim aprogramiranje time brže, dok s druge strane je jedno 3-5 puta sporije što se tiče performanci.

da li je ok, neću komentirati, neki kažu da je ok, neki kažu da je glupost.

Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.

+79 Profil

Re: Computed DatumDo

^{12.04.2011. u 20:53 - pre 158 meseci}

OK, object relational mapping. Onda uporedjujemo babe i zabe, ne vredi raspravljati. Ne valja samo ako ono 'bez icega na bazi' znaci da na bazi nema nikakvih constraints. Od previse constraints ne moze da boli glava.

U zdravlje, valjda je vereme da zavrsimo temu.

Odgovor na temu

nadavesela
programer, DZS

Član broj: 199298
Poruke: 93
195.26.131.*

+3 Profil

Re: Computed DatumDo

^{13.04.2011. u 08:10 - pre 158 meseci}

Citat:

Za sada, ni jedan proizvodjac ne nudi nista na ovu temu. Isto kao sto ne nude pracenje istorije promene, pa da one duplicirane i komplicirane kolone budu sakrivene od korisnika, ali prisutne u sistemu i da se automastki popunjavaju.

Mislim da ce sirenje same metode o istoriji promena i integritetu podataka u tom smislu, zahtevati i da DBMS omoguce na nivou tabele definiranje dali ista moze da bude samo INSERT tabela, dali moze INSERT i UPDATE, dali INSERT i DELETE, dali INSERT i UPDATE i DELETE,
pa da mi sami u dizajnu definiramo kakav nacin rada zelimo i tada mozda necemo morati definirati ni Constraint, ni UDF, ni Trigger...sve ce to biti skriveno od nas i shvatljivo svima.

Odgovor na temu

nadavesela
programer, DZS

Član broj: 199298
Poruke: 93
195.26.131.*

+3 Profil

Re: Computed DatumDo

^{13.04.2011. u 08:49 - pre 158 meseci}

Citat:

Mnogi ovo ne vole. Ako se zaista napravi greska negde na pocetku, recimo zaboravi se jedna promena, gresku je nemoguce ispraviti, niti je moguce obrisati sve pa ispocetka.

Samo kao pocetna ideja da je sve ipak moguce al da trazi rad i doradu, moze se ispraviti i izbrisati...
Mozda je jednostavnije u mom primeru jer radim sa Identifikatorima reda (Vestackim kljucem), tako da mi datumOd nije deo primarnog kljuca.
Ideja je ova, kao sto je zapis istorije promena isla u jednom pravcu

Id datumOd Cena PrethodniId Korekcija
1 01/01/2011 200 - 0
2 01/02/2011 300 1 0
3 01/03/2011 400 2 0

isto je moguce napraviti korekciju inserta do momenta unazad koji treba da bude poslednji vazeci
(neka to bude momenat kad je datum '01/01/2011' kad je cena 200 a Id=1)
te bih unazad zapisujuci datum kad pravim promenu '01/04/2011' insertovala ovako
4 '01/04/2011' 400 3 1
5 '01/04/2011' 300 2 1
u svim funkcijama moracu kao uslov imati i kolonu Korekcija, a sam upis vrednosti cene u uvom slucaju mi je odvisan jer meni je bitna veza da znam koji redovi su proglaseni nevazecim ( a to su redovi za vrednosti kolone Korekcija=1 koji su u koloni PrethodniId, znaci redovi 2 i 3) i za naredni upis redovi ciji Id=2 i 3 ne ulazi u mogucnost da se preko UDF i constrainta definisanog preko nje unese kao vazeci za kolonu PrethodniId
e tad mogu da upisem eventualni naredni ispravni podatak, sa ispravnim datumom
6 '01/03/2011' 400 1 0
Malo je futuristicki i nerealno al ipak to je to...imate trag svega sto se radi...bas kao u knjigovodstvu.
Izviinjavam se za eventualni los prikaz podataka za primer.

Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.

+79 Profil

Re: Computed DatumDo

^{13.04.2011. u 15:22 - pre 158 meseci}

Citat:

Malo je futuristicki i nerealno al ipak to je to...imate trag svega sto se radi...bas kao u knjigovodstvu.

Upravo to je poenta - trag svega sto se radi, bas kao u knjigovodstvu.

Sve je ovo novo, ima puno da se radi i istrazuje i otkrivaju nove stvarina svakom koraku, sta moze i sta ne moze. Prvi clanak na ovu temu napisao je Joe Celko, cak je dao i kod, koji naravno nije radio. Posle nekoliko meseci Alex je napisao knjigu sa primerima iz stvarne prakse gde deo toga radi. Onaj deo koji smo opisali u ovoj temi - pracenje promena. Sada je na nama da istrazujemo i probamo. Ja imam jednu bazu u produckciji koja radi dve stvari - pracenje promena i validaciju statusa, po Celkovom modelu. nemem vremena da to objavim i opisem

ali bice valjda uskoro. Nada ce imati nesto sa korekcijama, neko drugi jos nesto i eto nas na sledecem nivou kvaliteta.

Alex je dao i primer kako se iz ove price lako ulazi u pracenej stanja, gde je stanje = SUM(ulaz) - SUM(izlaz) . Stanje se se cuva u tabeli i uvek je azurno, a sve bez trigera. Samo FK i CHECK.

A na forumu Access dali smo resenje za probleme tipa iznajmljivanja - biblioteka, rent-a-car, duzenje osnovnih sredstava (ko je u kom momentu duzio kamion...) Ne znam tacno koja je tema, potrazicu na Access forume. E vala ako smo mogli u Accesu da uspostavimo sva ogranicenja na nivou tabela, bez koda, onda mora da moze i u SQL. Samo treba da se potrudimo, pa sta bude.

Odgovor na temu

MarkoBalkan

Član broj: 141124
Poruke: 1624
188.125.17.*

+19 Profil

Re: Computed DatumDo

^{13.04.2011. u 16:08 - pre 158 meseci}

Citat:

Zidar

Alex je dao i primer kako se iz ove price lako ulazi u pracenej stanja, gde je stanje = SUM(ulaz) - SUM(izlaz) . Stanje se se cuva u tabeli i uvek je azurno, a sve bez trigera. Samo FK i CHECK.

zašto se stanje čuva u bazi?
zašto se takve promjenjive vrijednosti čuvaju u bazi, kad se može napraviti fukcija koja to računa?

ako imamo par tisuća artikala, nije problem, ionako se korisniku prikazuje maksimalno 20 artikala na stranici, ako lista dalje, računa se za slijedećih 20 i sve brzo radi.

Odgovor na temu

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427

+19 Profil

Re: Computed DatumDo

^{13.04.2011. u 18:08 - pre 158 meseci}

On 13.4.2011 17:08, "MarkoBalkan" wrote:

Citat:

...
zašto se stanje čuva u bazi?
...

Zato što se koristi tip podataka kao izračunata vrednost. Ne zauzima
prostor i izračunava se u vreme upita. Nekada može da bude izuzetno
koristan podatak.

Odgovor na temu

MarkoBalkan

Član broj: 141124
Poruke: 1624
188.125.17.*

+19 Profil

Re: Computed DatumDo

^{13.04.2011. u 18:24 - pre 158 meseci}

Citat:

mkaras: On 13.4.2011 17:08, "MarkoBalkan" wrote:

Zato što se koristi tip podataka kao izračunata vrednost. Ne zauzima
prostor i izračunava se u vreme upita. Nekada može da bude izuzetno
koristan podatak.

nismo se razumjeli.
npr,
kreiram funkciju "stanje" sa ulaznim parametrom artikla, a funkcija mi vraća double na dvije decimale.

i onda imam

select artikl_šifra,artikl_ime,artikl_stanje(artikl_šifra) as stanje from artikli

vrijednosti koje se moraju računati, nikad se ne čuvaju u bazi već se dinamički izračunavaju.
kad korisnik pregledava artikle(proizvode), njemu se izračunava stanje i prikazuje na ekranu za 20 artikala(20 artikala po stranici).

jer ako se zapiše u bazu, stanje se non stop mijenja i nije 100 % točan podataka, a i narušava se 3. normalna forma.

jer ako se vrijednost može dobiti pomoću agragatnih funkcija i/ili pomoću operacija, tada se vrijednost ne čuva u bazi.

ako oltp baza nije minimalno u 3. normalnoj formi, kompliciraju se stvari, a osim toga postoji redudancija podataka, održavanje je teško, a onaj tko je projektirao takvu bazu nema pojma.

da se vratim na moj prijedlog, kad se stave ograničenja, datum do se ostavi prazan, a kad se unosi nova cijena, slog sa praznim poljem se update-a i ubaci novi.

znači u mojem slučaju nije moguće izvršiti update bilo kojeg postojećeg sloga bilo kojeg polja, osim ako to polje nije prazno.
a samo za datumdo bi stavio null, ostala polja bi trebala biti not null.

_{[Ovu poruku je menjao MarkoBalkan dana 13.04.2011. u 19:51 GMT+1]}

_{[Ovu poruku je menjao MarkoBalkan dana 13.04.2011. u 19:51 GMT+1]}

Odgovor na temu

[es] :: MS SQL :: Computed DatumDo

Strane: 1 2 3

[ Pregleda: 6887 | Odgovora: 52 ] > FB > Twit

Srodne teme

04.06.2008. razlika datum izrazena u mm i dd
14.06.2008. firebird kreiranje baze podatak,Flame Robin kako ..
23.08.2008. Stanje vrednosti u dataGridu
17.01.2009. Problem sa SQL-om???
04.03.2009. Kastovao datum i zeznuo pretrazivanje
29.10.2009. Problemi sa selektovanjem tabele po datumu
09.11.2009. SQL upit ne daje rezultat
24.01.2010. Novi igrac sa medjunarodnim linkom u Srbiji?
12.01.2010. Kalendar - kombinovani niz datuma

Navigacija

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