[ASP] Datum als nummer opslaan en vice versa

[Webdoc]

Ik word er helemaal gek van. MSDN - no answer. Google? No answer. ASP boeken?? No answer!!

Dus.. wat ik wil is heeeeel simpel. in ASP kan je een datum converteren naar een nummer

bijvoorbeeld:
<%= cDate(200001) %> wordt 7/31/2447
<%= cDate(1) %> wordt 12/31/1899
etc

Nou is het uiteraard zo dat je niet van mensen kan verwachten dat zij deze nummers kennen, dus ik wil ook een INVOER zoals 2/2/2007 weer TERUG kunnen converteren naar een nummer. En hoe DIT moet, kan ik echt nergens vinden. FormatDateTime support de functie niet, echt geen IDEE. Het lijkt me ZO logisch en simpel...

Reden dat ik dit wil is omdat opslaan vaneen int in DB uiteraard beter/sneller is, en omdat het sowieso veel makkelijker wordt om de data te manipuleren en door te zoeken. Thank you !

[pjonk]

Vroeger in VB6 gebruikte ik wel eens Clng(Date).
Maar waarom denk je dat het opslaan van een date als INT efficienter is dan het datetime datatype van je DBMS wat veel gangbaarder is. Als je een int gebruikt kun je ook niet meer Date specifieke functies van je DBMS gebruiken.

[ Voor 4% gewijzigd door pjonk op 06-02-2007 20:44 ]

[CrashOne]

Wat ik zou doen is een dateDiff tussen Now() en 01-01-1970 en dan in seconde, net als een unix time stamp.

[giMoz]

om hoeveel records gaat het in vredesnaam dat je op dat niveau aan het optimaliseren bent..

en of het opslaan van een datum in een integer veld in de database beter is zou ik zo niet durven beweren, (integendeel zelfs) al was het alleen maar vanwege wat pjonk al zegt, database specifieke zaken..

[whoami]

Waarom denk je dat het makkelijker is om op die manier door datums te zoeken ?
Wat als ik nu eens een query wil doen, die mij alle records teruggeeft waarop die datum in een bepaalde maand in een bepaald jaar valt ?
Waarom denk je dat een datum opslaan als INT sneller is (bij het zoeken dan) dan die datum opslaan als DateTime. Een DateTime is intern ook gewoon maar een float (of twee floats; eentje voor de datum en eentje voor de tijd). Maw; intern wordt die datum al als puur numeriek gegeven opgeslagen.

Eigenlijk is dit niet over-optimaliseren, of over-engineeren, maar gewoon over-prutsen.

[PaulZ]

Ik ben ooit zoiets wel eens tegengekomen (dacht ik) in VB.NET.
Dus onder voorbehoud:
Pak de Ticks property van een datumobject en dan krijg je een nummertje terug. Geen idee of dat in ASP ook te vinden is overigens... Maar het lijkt ongeveer hetzelfde te werken als wat CrashOne aangeeft.

[RobIII]

PaulZ schreef op dinsdag 06 februari 2007 @ 21:59:
Geen idee of dat in ASP ook te vinden is overigens...

Nee, in ASP (of, waar TS het eigenlijk over heeft, VBScript) heb je dat niet maar dat doet er ook helemaal niet toe zoals whoami al aangeeft. Je bent een "domoor" (als ik even zo vrij mag zijn) als je datums als een int gaat zitten opslaan als je DBMS gewoon een Date(Time) type heeft. whoami's reply is daar redelijk duidelijk over; het heeft nul komma nul nut om dit, om wat voor reden dan ook, uberhaupt te willen.

[ Voor 42% gewijzigd door RobIII op 06-02-2007 22:09 ]

[Webdoc]

Laat het nut ervan nou maar aan mij over Dank voor het antwoord - Clng() werkt.

Het nut is bijvoorbeeld dat ik met minder moeite lengtes kan berekenen - als iets begint op datum 77781 en eindigt op 77791 is het meteen duidelijk dat iets 10 dagen duurt, EN kan ik ook met minder ingewikkelde en error-gevoelige SQL (waarbij ik dan ook nog rekening moet houden dat sommige servers NL datums hanteren en andere US datums) sneller dit soort informatie achterhalen en vergelijken. En zoals ik al zei - een int is minder data en ook sneller in het uitlezen en bewerken dan een datetime. Maar het is vooral een gemaks-kwestie waarbij er 100% zeker duidelijk is wele datum bedoeld wordt.

Daar komt overigens bij dat ik de tijd in dit geval niet nodig heb. Gaat mij puur en alleen om een datum. Trust me - in this particular instance is het gebruiken van een int waarschijnlijk handiger dan het opslaan van een datum. Ik wil deze functie voor het eerst op deze manier gebruiken (na het 8 jaar op de conventionele manier gedaan te hebben).

[ Voor 44% gewijzigd door Webdoc op 06-02-2007 22:58 ]

[RobIII]

Webdoc schreef op dinsdag 06 februari 2007 @ 22:36:
Het nut is bijvoorbeeld dat ik met minder moeite lengtes kan berekenen - als iets begint op datum 77781 en eindigt op 77791 is het meteen duidelijk dat iets 10 dagen duurt

Iets dat op 5 januari begint en 15 januari eindigt duurt ook 10 dagen hoor

Webdoc schreef op dinsdag 06 februari 2007 @ 22:36:
EN kan ik ook met minder ingewikkelde en error-gevoelige SQL

Wat is er error-gevoelig aan een datediff

Webdoc schreef op dinsdag 06 februari 2007 @ 22:36:
(waarbij ik dan ook nog rekening moet houden dat sommige servers NL datums hanteren en andere US datums)

Dan heb je het niet begrepen; je query analyzer of enterprise manager of whatever presenteert het als NL/US datum; onderliggend zijn het gewoon dezelfde bytes hoor.

Webdoc schreef op dinsdag 06 februari 2007 @ 22:36:
sneller dit soort informatie achterhalen en vergelijken. En zoals ik al zei - een int is minder data en ook sneller in het uitlezen en bewerken dan een datetime.

En zoals wij al aangaven complete bull; je maakt meer overhead met het terugrekenen naar datums dan dat je er van profiteert. Dit soort micro-optimalisaties zijn in zelfs in de meest extreme gevallen zelden nodig. Je zult je 'performance' ergens anders vandaan moeten halen als het niet performed zoals je graag wil; datums omrekenen naar een int is helpt daar niet aan.

Webdoc schreef op dinsdag 06 februari 2007 @ 22:36:
Maar het is vooral een gemaks-kwestie waarbij er 100% zeker duidelijk is wele datum bedoeld wordt.

Als je je data opslaat in UTC is er ook niks aan de hand

Webdoc schreef op dinsdag 06 februari 2007 @ 22:36:
Daar komt overigens bij dat ik de tijd in dit geval niet nodig heb. Gaat mij puur en alleen om een datum. Trust me - in this particular instance is het gebruiken van een int waarschijnlijk handiger dan het opslaan van een datum.

Trust me; je maakt het jezelf moeilijker dan nodig en je profiteert er echt 0,0 van. Als je met ints gaat zitten rekenen kun je er geen enkele datum functie van je SQL op los laten.

Webdoc schreef op dinsdag 06 februari 2007 @ 22:36:
Ik wil deze functie voor het eerst op deze manier gebruiken (na het 8 jaar op de conventionele manier gedaan te hebben).

Eigenwijs Maar goed; have fun.

[ Voor 4% gewijzigd door RobIII op 06-02-2007 23:18 ]

[whoami]

een int is minder data en ook sneller in het uitlezen en bewerken dan een datetime

De snelheidswinst is marginaal; een int is (in sql server) 4 bytes en een datetime is er 8.
Wat dus wil zeggen dat je voor een int inderdaad 2x zoveel keer intjes in één node kunt opslaan dan een datetime, wat wil zeggen dat, in het slechtste geval er 2x zoveel nodes moeten doorlopen worden. Big deal.
Als er geen index op dat veld staat, dan zie ik zowiezo geen performance winst.

waarbij ik dan ook nog rekening moet houden dat sommige servers NL datums hanteren en andere US datums

Als je je datums goed opslaat, dan hoef je daar geen rekening mee te houden.
Zoals ik al zei, de datum wordt in de DB opgeslagen als een float, en of die nu als dd/mm/yyy moet getoond worden, of als mm/dd/yyyy, is een probleem van de presentatie-laag.

kan ik ook met minder ingewikkelde en error-gevoelige SQL

Wat versta je hier onder een ingewikkelde query ?
Stel nu eens dat je alle records moet terugkrijgen waarvan die datum in januari 2004 OF in december 2003 ligt.

[kenneth]

Webdoc schreef op dinsdag 06 februari 2007 @ 22:36:
(waarbij ik dan ook nog rekening moet houden dat sommige servers NL datums hanteren en andere US datums)

Alleen als je string-concatenation gebruikt voor je query's of niet expliciet opgeeft hoe je datums gerepresenteerd moeten worden.

Je zit best wel heel hard met een waterpomptang op een spijker te slaan omdat je hamer stuk is. Probeer eerst nou die hamer te fixen

[Verwijderd]

Wanneer je je queries niet parametriseert werkt een YYYY-MM-DD formaat vrijwel altijd. Alleen bij oude Interbase servers (<5) is DD.MM.YYYY handiger. (Duits formaat, die punt zorgt ervoor dat dag en maand niet omgewisseld zullen worden.)

[frickY]

Stel nu eens dat je alle records moet terugkrijgen waarvan die datum in januari 2004 OF in december 2003 ligt.

Of leuker.. als je alle records vn Maart uit een willekeurig jaar terug wilt.
Kun je eerst gaan bepalen wat het laagste en hoogste jaar in je dataabse zijn, om vervolgens met een hele reeks BETWEENs al die jaren af te lopen, in plaats van een MONTH(date) = 3.

Bepalen hoeveel dagen tussen 2 records zit op de 'conventionele' manier; DATEDIFF(d, date1, date2).
Op jouw manier; (date2 -- date1) / 60 / 60 / 24

[ Voor 6% gewijzigd door frickY op 07-02-2007 08:05 ]