Oracle- Check datetime

[Kluvanek Martin]

Honza Pazdziora wrote:
> On Mon, Oct 27, 2003 at 07:37:36PM +0100, Kluvanek Martin wrote:
> 
>>Ked som chcel obmedzit, aby sa nestrkali zaznamy napriklad novsie ako 
>>SYSDATE.
>>Spravil som takyto pokus:
>>
>>create table EMPLOYEE
>>(Birthdate DATE check(BirthDate <= SysDate));
>>
>>Vysledok je:
>>ORA-02436: v kontrolním omezení je chybně definovaná datumová či systémová 
>>proměnná
>>
>>Pritom som to pouzil identicky ako v 
>>http://www.embarcadero.com/news/auditdatevalues.asp
> 
> 
> ... a přesně o chybě ORA-02436 se v tom článku také píše, spolu se
> zdůvodněním.
Prave ze nie.
Tam sa len vysvetluje, ze pri importe dat v buducnosti by mohla toto CHECK 
obmedzenie sposobit problemy (rozumel som LOGICKE a nie implementacne). To je 
pravda ale 1)importe neplanujem 2)pocas importu mozem podmienku(y) docasne 
zrusit. (samozrejme moj problem je trochu ineho razenia a tam k takejto logickej 
komplikaci nemoze dojst vobec)
ORA-02436 sa tam spomina len v suvislosti s pouzitim obmedzenia pevnym datumom 
kde je rok len v 2miestnom formate '01-JAN-10' koli nejednoznacnosti 
specifikacie roku.
Podla mna tam nieje ani slovo zmienky o tom, ze je pouzitie sysdate v CHECK 
zakazane ale len nevhodne.

S tym 2miestnym rokom som si tiez pekne uzil :-)
Pouzivam nls_date_format="DD.MM.YY HH24:MI:SS" a preto ma prekvapilo ze ked pri 
vstupe datumu zadam
01.02.03 01:02:03 tak dostanem rok 0003
kdezto pre
01.02.03 11:02:03 dostanem rok 2003
(pisem to z pamati takze je mozne ze to nieje uplne do puntiku presne)
Takze aplikacia ktora si vyziadala data z obdobia od
8.9.03 01:00 do 8.9.03 23:00 v skutocnosti obdrzala data od zaciatku chodu 
systemu z coho mala niekolko hodin hlavu v pejru.
:-))

Naproti tomu musim uznat, ze ma prijemne prekvapila zmena ked som previedol 
tabulku typu
cas,zariadenie,vstup (primarny kluc) + 3 datove polia
kde v jednom case pre jedno zariadenie existuje sucasne 96 takychto zaznamov

na tabulku typu
cas,zariadenie (primarny kluc) + 3 polia typu VARRAY(96)
V jednom case pre jedno zariadenie len jediny (vacsi) zaznam

Povodna tabulka mala totiz 76 mil poloziek a nova 96xmenej.
Tym padom bol index 96x mensi a navyse sa uz asi vliezol do pamate. (system ma 
len 1GB RAM)
Povodne napriklad export (vlozenou procedurou) 1 tyzdna dat
(cca 100tis zaznamov  3xnumber) trval asi 1300sekund (a pre kratsie useky dat 
trval stejne dlho )
Po uprave (cca 10 tisic zaznamov 3xVARRAY) to chodi za 35sekund pricom pre 
kratsie useky to je linearne kratsie.

Mal som z toho strach, ze to bude
1)komplikovane na inplementaciu
2)narocne na vykon ORACLE
ale opak je pravdou.

Mozem doporucit pre velky cocet zaznamov a polozky v ktorych nieje nutne sa 
priliz detailne prehrabovat.


> Ano. Check je statické omezení kladené na hodnoty v tabulkách. Oproti
> tomu trigger Vám dovoluje vrátit chybu při akci nad daty. To že Vy
> víte, že funkce sysdate je monotónní, ještě neznamená, že to ví
> Oracle, a taky to neznamená, že se najednou nestane, že někdo bude
> chtít ta data naimportovat do databáze, kde bude sysdate o tři roky
> nazpět. Kde by ta samá data už nebyla validní. Test s použitím sysdate
> tedy není námět pro check, anýbrž pro trigger.
Suhlasim, trigger ma ovela sirsie moznosti, len ma prekvapilo, ze som nikde 
nenasiel, ze to je ZAKAZANE.


-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz