Zakaj v Sql Serverju ne obstaja nekaj takega:
select * from xxx where date = createdatetime(2006, 1, 4)
Tako pa je potrebno vedno nekaj mešetariti s teksti. Govorim seveda o ročnem sestavljanju sql stavkov (aplikacija itak pošilja parametre naokoli). Ali sem kaj spregledal?
Avtor: MihaM, objavljeno na portalu SloDug.si (Arhiv)
AndrejT - nedelja, 23. april 2006
Pikapolonica ponavadi izpolni vse želje... Tudi tiste najbolj fantazijske
bojanv - nedelja, 23. april 2006
Te strani (produkt feedback) se pa nisem videl. Zanimivo, kaj vse prebereš.....
lmat74 - sobota, 22. april 2006
Zveni kot povsem logičen in veljaven predlog. Če ga daš na product-feedback, ga takoj podprem.
AndrejT - sobota, 22. april 2006
Tu je v veljavi prvi zakon razširljivosti programskih jezikov - ne razširjaj nabora funkcij, dokler z obstoječimi funkcijami lahko dosežeš želeno. SQL je pač malce bolj eksaktna znanost... Sicer pa že obstaja datepart(), zakaj ga ne bi SQLovci porabil za nekaj takega: datepart(date, getdate()), datepart(time, getdate())...
lmat74 - sobota, 22. april 2006
Ja! In na blogih bomo objavljali vsak svojo skripto za bazo model.
MihaM - sobota, 22. april 2006
"z drugimi besedami miha.... prevec si razvajen " src="/emoticons/emotion-1.gif"/>" src="/emoticons/emotion-1.gif"/>" src="/emoticons/emotion-1.gif"/> evo miha samo zate:" Ej, hvala, sej bi znal kaj takega spackat skupaj. Samo še vedno ne reši osnovnega vprašanja. Tele stvari bi morale biti privzeto prisotne, ne pa da se piše tele funkcije. Saj ne govorim o neki hudi abstraktni stvari ki jo uporablja neki nori znanstvenik enkrat na 1000 let :-)
MihaM - sobota, 22. april 2006
"Na SLODUG/SQL2005 dogodku sta se oba SQL developerja strinjala, da lahko to rešimo s CLR UDT. " src="/emoticons/emotion-1.gif"/> Zato se oni v to niso poglabljali. Glede na to, kako hitro je prišel SP, bi rekel, da se v marsikaj niso poglabljali..." LOL. Zdaj bomo pa vsak svojo CLR UDT funkcije napisali in tovorli zbire (assemblije) naokoli. :-)
spirit1 - sobota, 22. april 2006
z drugimi besedami miha.... prevec si razvajen nic se nisem preverjal kar se getdate-a tice... sem pa probal najdit tisto FastParse zadevo v SISS-u za katero je Farmer rekel da pohitri import iz flat file-a za 20%. po parih urcah iskanja sem rekel naj se gre solit in sel pocet druge stvari.... evo miha samo zate: Create function dbo.Date(@someDate datetime) returns datetime as SELECT @someDate = DATEADD(d, DATEDIFF(d, 0, @someDate), 0) return @someDate kaksen je tag za kodo prikazovat??
lmat74 - sobota, 22. april 2006
Na SLODUG/SQL2005 dogodku sta se oba SQL developerja strinjala, da lahko to rešimo s CLR UDT. Zato se oni v to niso poglabljali. Glede na to, kako hitro je prišel SP, bi rekel, da se v marsikaj niso poglabljali...
lmat74 - sobota, 22. april 2006
Tudi workaround z viewjem je grdo breme za optimizer. Jaz raje uporabljam parameter, v katerega pred klicem zapišem getdate(). Precej pospeši izvajanje. Kako je v 2005 še nisem preveril, domnevam pa, da je manj I/O. Si kaj meril/primerjal? (Opisal v blogu? )
MihaM - sobota, 22. april 2006
Joj, ljudi kaj vse je potrebno mučkati za normalne datumske operacije. SELECT DATEADD(d, DATEDIFF(d, 0, GetDate()), 0) da dobim samo datum? Ne pravim da je slabe rešitev v okviru obstoječega stanja, ampak očitno je na prvi pogled kaj select dela, a ne. Ma kje živjo tile SQLjevci? A bi blo zlo preveč hudo narediti Date(d), če se še d.Date ne da. Torej, kaj je bolj pregledno: SELECT DATEADD(d, DATEDIFF(d, 0, GetDate()), 0) ali SELECT Date(d) ? Ne vem, morda sem razvajen :-)
spirit1 - sobota, 22. april 2006
da malce unicim zabavo... v SS2000 getdate() ne more biti v UDF-u ker to naredi funkcijo nedeterministicno. seveda lahko naredimo trik z view-jem.... v SS2k5 pa je getdate() mozno imeti v UDF-u.
AndrejT - sobota, 22. april 2006
lmat74 wrote:Moj rojstni dan je porodničar določil do minute natančno. Ja, mi 'tamladi' imamo to srečo Dvojna petnajstka zame... Oba selecta sta sicer čisto ok, mučil me je tisti getdate(), ki bi ga eventuelno lahko mogoče želel nadomestit s createdate(2006, 4, 22), da bi se izognil podajanju datuma v stringu. lmat74 wrote:No silver plate => no golden data. In datum kot datum, ni ravno "serviranje na srebrnem pladnju".Res, razen v primerih, ko imaš zafiksirane specifikacije [eh, kaj spet govorim ]
lmat74 - sobota, 22. april 2006
Moj rojstni dan je porodničar določil do minute natančno. Želiš zapise, ki imajo datum/čas te minute? Želiš zapise, katerih datum/čas je znotraj dneva, ko sem se rodil? Nekaj takega? Povsem brez parametrov in brez kakršne koli kontrole:select * from [table] where ([datetime column] >= dateadd(dd, 0, datediff(dd, 0, getdate()))) and ([datetime column] < dateadd(dd, 1, datediff(dd, 0, getdate())) Sicer pa:declare @t datetime select * from [table] where ([datetime column] >= dateadd(dd, 0, datediff(dd, 0, @t))) and ([datetime column] < dateadd(dd, 1, datediff(dd, 0, @t)) Pa ne se hecat, ker vem, da ti ne bi uporabniku nikoli dovolil vnosa neveljavnega datuma. No silver plate => no golden data. In datum kot datum, ni ravno "serviranje na srebrnem pladnju".
AndrejT - sobota, 22. april 2006
lmat74 wrote:Mene bolj zanima, od kod datum v treh (ali več) kosih. Verjetno ne pričakuješ, da bo vse vedno servirano na srebrnem pladnju? Bom poskusil še malo poenostavit... želim recimo funkcijo brez parametrov, ki mi bo vrnila vse zadetke, ki se datumsko ujemajo s tvojim rojstnim dnevom.[OK, to gre že proti principom, ampak recimo, for argument's sake...]
lmat74 - sobota, 22. april 2006
Ja, SQL ne pozna day/month/year, pozna datetime (in smalldatetime). Če datum sestavljaš "ročno", je potrebno nekje zagotoviti, da bo nastal veljaven datum. Npr. kombinacija 29/2/2000 je veljavna, medtem ko 29/2/2001 ni, v obeh primerih pa so sestavine trije povsem veljavni integerji. Mene bolj zanima, od kod datum v treh (ali več) kosih. Napisat konstruktor v obliki UDF je ena opcija, bolj naravno pa je uporabljati datum ko to, kar pač je - datum - obdobje od/do. In v SQL je to pač datum s časom. Kaj je vprašanje: Kdaj se je neka stvar zgodila (dogajala)? Ali: Kateri datum je bil, ko se stvar zgodila (dogajala)? In v drugem primeru - kaj če je dogodek trajal več dni?
AndrejT - sobota, 22. april 2006
Če se vrnemo k prvemu vprašanju o konstruktorju... Recimo, da dobimo v proceduro parametre @day int, @month int, @year int Če želim iz tega dobit nek uporabni datum, ne vidim druge rešitve, kot da zaupam standardu in si drznem sestavit string ala select cast(cast(@year as varchar(4)) + '-' + cast(@month as varchar(2)) + '-' + cast(@day as varchar(2)) as datetime) ali pa sem še bolj drzen in zaupam, da je izhodiščna datumska meja res 1.1.1900: select dateadd(dd, @day-1, dateadd(mm, @month-1, dateadd(yyyy, @year-1900, 0))) Ali pač obstaja kaj bolj preprostega in zanesljivega? Vprašanje, ali 'konstrukcijsko' funkcijo (kakršnokoli pač uporabimo), priredimo parametru, ali pa jo postavimo v pogoj, pa je stvar odločitve, koliko prostora za 'optimizacijo' si želimo pustit za naprej...
spirit1 - sobota, 22. april 2006
res je. se prevelikokrat vidim convert(varchar(35), dateColumnName, 121) = @somedate ali kaj podobnega....
lmat74 - sobota, 22. april 2006
Ja, danes je pravi dan za pivo. Sicer je pa za preverjanje datumov bistveno, da na polje ni obešena kakšna funkcija, ki bi zahtevala table scan; npr. kakšna šala a-la detetime constructor (=performance destructor).
spirit1 - sobota, 22. april 2006
ROTFL!! ce bi ta forum imel slikco piva bi ti to zdaj dal
lmat74 - sobota, 22. april 2006
Preveč enostavno.
spirit1 - sobota, 22. april 2006
ja parametri so obvezna oprema. kar se pa tice konvertiranja v float... tega raje ne pocni. datetime je shranjen kot 2 int tipa (1 za datum, 1 za cas) zato raje uporabljaj samo datetime funkcije: - samo datum: SELECT DATEADD(d, DATEDIFF(d, 0, GetDate()), 0) - samo ura: SELECT DATEADD(d, -DATEDIFF(d, 0, GetDate()), GetDate()) in pa eksplicitni datetime konstruktor je poplnoma nepotreben
lmat74 - torek, 18. april 2006
Ni treba "mešetariti s teksti":select * from [table] where ([datetime column] >= floor(cast(@datetimeParameter as float))) and ([datetime column] < case floor(cast(@datetimeParameter as float)) when @datetimeParameter then dateadd(d, 1, @datetimeParameter) else ceiling(cast(@datetimeParameter as float)) end) select * from [table] where ([datetime column] between floor(cast(@datetimeParameter as float)) and case floor(cast(@datetimeParameter as float)) when @datetimeParameter then dateadd(ms, -3, dateadd(d, 1, @datetimeParameter)) else dateadd(ms, -3, ceiling(cast(@datetimeParameter as float))) end) Je pa smiselno uporabljati parametre. To pa!
ExAmigan - sobota, 15. april 2006
No ja, z uporabo obeh podprtih ISO formatov, ki veljata za varna, torej yyyy-mm-dd in yyyymmdd (oz. 126 in 112) ni bojazni, da bi šlo kaj narobe. Vseeno pa se pridružujem mnenju, da manjka marsikakšna funkcija za bolj praktično delo z datumi. (ločevanje in združevanje datumskega in časovnega dela je npr. vedno prijetno). MMG: Tale članek je uporabna referenca za to področje.
MihaM - petek, 14. april 2006
Ma ja, vem za tele stringe, samo se mi zdi malo tko, da nikoli nisi prav siguren kaj bo padlo ven :-). In da se dela implicitna pretvorba iz teksta v datum - ojojoj, kaj so sql server pisali ljudje od VB3? Pa trim polja datetime manjka....
AndrejT - petek, 14. april 2006
Mislim, da je v Sql Serverju najbolj zanesljiv format 'YYYY-MM-DD', ki je neodvisen od nastavitev formata datuma in regionalnih nastavitev. Funkcija pa očitno manjka, ja