[ anaxim @ 27.12.2008. 18:38 ] @
Postoji li nacin da u MS SQL 2005 Express setujem da se u polje tipa DateTime upisuju vrednosti u evropskom formatu dd/MM/yyyy?

Pozz
[ .:Marvin:. @ 29.12.2008. 11:28 ] @
Ja ne znam bas za datetime tip. A da li si siguran/a da moras da koristis taj tip? Za datum je bolje koristiti varchar i nemas problema.

Ako ako ti je vec zapisan datetime, f-jama GetDate i Convert mozes da ga konvertujes u sta hoces.
[ anaxim @ 29.12.2008. 16:05 ] @
Probacu da to odradim na taj nacin.

Pozzz
[ jablan @ 29.12.2008. 16:19 ] @
Citat:
.:Marvin:.: Za datum je bolje koristiti varchar i nemas problema.

Ovo apsolutno ne.

Kao što si posle rekao, formatiranje datuma treba ostaviti za SQL ili, još bolje, aplikaciju.
[ .:Marvin:. @ 30.12.2008. 07:30 ] @
Hajde onda mi objasni zasto APSOLUTNO ne?
Ponudio sam coveku vise resenja, pa neka bira.
[ jablan @ 30.12.2008. 09:10 ] @
Zato što postoje desetine razloga da se datum u bazi ne čuva kao string, a apsolutno nijedan da se čuva kao string.

Za tako elementarne stvari ne postoji više rešenja, nego samo jedno. Brojevi se čuvaju kao brojevi, datumi kao datumi a stringovi kao stringovi.
[ chachka @ 30.12.2008. 15:24 ] @
Citat:
.:Marvin:.: Hajde onda mi objasni zasto APSOLUTNO ne?

Morao bi da programiraš operacije sa datumima, poređenje datuma, sortiranje datuma, konverziju datuma iz jedne prezentacije u drugu, pa i samu proveru ispravnosti datuma. Ovo je bespotrebno izmišljanje tople vode.
[ Koce @ 31.12.2008. 09:48 ] @
Mozes da probas nesto ovako:

SET DATEFORMAT dmy

DECLARE @datevar datetime
SET @datevar = '31/12/08'
SELECT @datevar
[ .:Marvin:. @ 02.01.2009. 17:09 ] @
Uzmimo za primer, da se datum cuva kao varchar(10), uvek u formatu 'gggg.mm.dd'

Poredjenje datuma ne mora da se programira, jer se kod datuma i logicki poredi prvo godina pa mesec pa dan.
Isto vazi i za sortiranje.
Dalje, MS SQL f-ja IsDate vraca 1 za ispravan datum u formatu gggg.mm.dd i kad je varchar.

Sa Convert moze da se konvertuje u ostale tipove datuma.

Kojih je to milion razloga da se ne cuva datum kao varchar?


[ mmix @ 03.01.2009. 09:15 ] @
Evo ti za pocetak jedan, sasvim dovoljan.

Poredjenje ovih tvojih datuma radi samo za operator =. Prakticno je neke stvari ili nemoguce odraditi ili je moguce odraditi uz veliki performance hit, npr vrati sve redove izmedju 12.jan.i 17.mar 2006e. DateTime na SQL severu je implementiran kao 64bit binarni sortabilni komparativni tip sa direktnom procesorskom podrskom za te operacije. Sa drugestrane poredjenje tvojih string datuma zahteva poredjenje 11-bajtnih memorijskih blokova strcmp rutinom. Nema potrebe da izmisljas toplu vodu i forsiras prezentacioni layer u sql tabele, prezentaciona adaptacija datuma iz bianrnog formata u string se obavlja u kranjoj instanci korisniku koji operise podacima a u skladu sa njegovim loklanim regionalnim podesavanjima.
[ jablan @ 03.01.2009. 09:22 ] @
Osećam se glupo jer to je kao da odgovaram nekom na pitanje "a zašto ja ne bih mogao da vozim levom stranom"...

Evo ti samo jedan razlog dovoljan svakom razumnom da prestane da razmišlja da krši ženevske i ostale konvencije: na aplikativnoj strani moraš da pišeš specijalan kod koji će datume iz tvog custom formata da učitava u odgovarajuće datumske tipove i obrnuto - jer svi database access lejeri već obezbeđuju tu funkcionalnost kad datume držiš u polju za datume.

Da ne govorim o svim lepim funkcijama koje mogu da se primenjuju na Date tipove, automatskoj validaciji pri upisu (šta ćeš, da pišeš trigger ili constraint da korisnik ne bi mogao da upiše '2008.23.55' u tvoje string datumsko polje? ).

Na kraju krajeva, i sama loša karma koju ćeš steći čuvanjem datuma kao stringa dovoljna je da ti garantuje stotinak večnih patnji u programerskom paklu. Pa ti vidi.

(preteče me mmix sa još jednim razlogom)
[ Zidar @ 05.01.2009. 16:59 ] @
Marvin kaze
Citat:
Uzmimo za primer, da se datum cuva kao varchar(10), uvek u formatu 'gggg.mm.dd'


Obrati paznju na rec UVEK. Kako ces da obezbedis da tvoja tabela ne prihvata pogresne datume? Koje ces consnstraints da uvedes da bi sprecio da se unese '2009.02.29' ili '2053.17.31'? Ako napises ispravnu i kompletnu CHECK CONSTRAINT priznacu ti da si bar donekle u pravu.

:-)
[ mmix @ 06.01.2009. 00:19 ] @
Citat:
CHECK CONSTRAINT priznacu ti da si bar donekle u pravu.


Pa izostavis . i konvertujes ga u datetime preko ISO formata 112 (yyyymmdd) i vidis dal pukne

Code:
CREATE FUNCTION dbo.CheckMyDate
(
    @valdate varchar(10)
)
RETURNS bit
AS
begin
    set @valdate = REPLACE(@valdate, '.', '');
    declare @dt datetime;
    set @dt = CONVERT(datetime, @valdate, 112);
    return 1;
end


a poziv stavis u check contraint. Medjutim i dalje nije u pravu, ni donekle
[ .:Marvin:. @ 06.01.2009. 07:50 ] @
Ok, evo da konacno odgovorim. Ja znam da u praksi takav sistem funkcionise, i to sasvim lepo. U pitanju je jedna velika IT firma, gde su uradjene i sopstvene kontrole, sa validacijama (na klijentu) i gde ne postoji sansa da korisnik upise los datum.

Sa druge strane, programerima ovakav nacin zapisa ('gggg.mm.dd') znacajno olaksava posao, jer se precesto radi i na terenu i pod velikim vremenskim pritiskom. Kako su u pitanju finansijske transakcije, gde postoji puno datuma, zamislite da pri svakom mogucem upitu pisete convert, getdate itd. Nije bas zgodno.

Ja prihvatam razloge zasto ovo nije idelano resenje, ali hocu da kazem da nije ni bas tako strasno.
[ jablan @ 06.01.2009. 08:27 ] @
Možda definicija "sasvim lepog funkcionisanja" uključuje i to da na razvoju i održavanju tog softvera mora da radi znatno više ljudi nego što je objektivno potrebno, što se opet kompenzuje činjenicom da firma dere za svoj softver, što omogućava činjenica da je te poslove dobila na nameštenim tenderima ili bez tendera? A obično su takve konvencije pisanja datuma u string započeli ortaci koji su napisali prvu verziju programa, oni koji nisu bili baš neki programeri ali su sad vlasnici i direktori i obavljaju taj posao sasvim lepo...

Šalu na stranu, i kad se radi kako treba, nema potrebe za bilo kakvim konvertovanjem datuma, kao što smo već rekli, o tome se stara klijentska platforma.
[ .:Marvin:. @ 09.01.2009. 07:35 ] @
Hehe, da li su sve velike IT firme u Srbiji iste, ili govorimo o istoj firmi :)
Samo se ne bih slozio oko jedne stvari, na razvoju i odrzavanju, s programerskog aspekta, uvek je manjak ljudi...

Ok, evo slozio sam se da je u opstem slucaju bolje da se na klijentu radi konverzija, i samo sam naveo jedan primer kad to nije bolje. (gomila ad hoc upita i stored procedura). Pozdrav
[ deerbeer @ 09.01.2009. 10:34 ] @
A ja se sve vreme pitam sta ce uopste datetime tip u bazi podataka
[ Fedya @ 09.01.2009. 11:12 ] @
I have seen the light!
Hajde da svi prestanemo da se opterecujemo tipovima i velicinama podataka. Hajde da sve trpamo u ntext polja, zabranimo upotrebu kljuceva, constrainta... svega...

Ili jos bolje da mi sve cuvamo u jednom velikom *.txt file-u, po mogustvu na destopu korisnika.
[ chachka @ 14.01.2009. 09:14 ] @
Evo jedna "lepa" funkcija za proveru validnosti datuma
Validating a Date with a Sledgehammer