mboost-dp1
"Kalender"tabel
Mojn
Jeg sidder lige og roder med lidt SQL.
Jeg vil gerne have lavet en tabel, der kan lave en "kalender" så at sige. Altså en tabel, hvor man kan slå f.eks. uge 18 op og så få alle ugedagene. Dato er ikke nødvendig, men en fin bonus.
Jeg overvejer lidt noget i denne stil:
KalenderID (Primary Key) - UgeNR - Dag
Problemet er jo så, at hver uge fylder 7 rækker (en for hver dag).
Kan det gøres mere elegant? Evt. med datetime? Men så er problemet jo bare at få tabellen "fyldt", hvis i forstår.. jeg har ikke lyst til at sidde og indtaste datoer for flere år frem :p
Jeg sidder lige og roder med lidt SQL.
Jeg vil gerne have lavet en tabel, der kan lave en "kalender" så at sige. Altså en tabel, hvor man kan slå f.eks. uge 18 op og så få alle ugedagene. Dato er ikke nødvendig, men en fin bonus.
Jeg overvejer lidt noget i denne stil:
KalenderID (Primary Key) - UgeNR - Dag
Problemet er jo så, at hver uge fylder 7 rækker (en for hver dag).
Kan det gøres mere elegant? Evt. med datetime? Men så er problemet jo bare at få tabellen "fyldt", hvis i forstår.. jeg har ikke lyst til at sidde og indtaste datoer for flere år frem :p
#1
Hvad skal det bruges til, lidt mere specifikt?
Umiddelbart kan du jo saadan set faa alle datoer ud af date(), med lidt mktime krydderi.
Hvilket sprog, udover SQL, benytter du?
Edit: Hvis det bare er ren SQL:
[id][ugenr][maaned][dag][aar]
SQL tager ikke skade af at faa for meget information, hvis du kun hiver ugenr ud, fx.
Men uanset hvad, saa skal du jo bruge et sprog der forstaar "date" til at indtaste det :)
Hvad skal det bruges til, lidt mere specifikt?
Umiddelbart kan du jo saadan set faa alle datoer ud af date(), med lidt mktime krydderi.
Hvilket sprog, udover SQL, benytter du?
Edit: Hvis det bare er ren SQL:
[id][ugenr][maaned][dag][aar]
SQL tager ikke skade af at faa for meget information, hvis du kun hiver ugenr ud, fx.
Men uanset hvad, saa skal du jo bruge et sprog der forstaar "date" til at indtaste det :)
Der er da overhovedet ingen grund til at lave en tabel med statisk information omkring datoer, da du bare kan hente værdierne ud fra DATETIME.
Du kan benytte DATEPART til info omkring ugenummeret og mere.
Eksempel (T-SQL), for uge 33:
Resultat:
Du kan benytte DATEPART til info omkring ugenummeret og mere.
Eksempel (T-SQL), for uge 33:
DECLARE @YEAR char(4) = YEAR(GETDATE());
SELECT DATEADD(wk, 33, @YEAR + '/01/01'));
Resultat:
2009-08-20 00:00:00.000
Beklager sent svar - har ikke lige været i nærheden af en computer siden middag.
#2
Det skal bruges, helt specifikt, til at folk logger ind på en webside, vælger en uge (uge 33, 34 w/e), får en popup, hvor de så skal krydse af, hvilke dage de er i bygningen. Denne info skal så gemmes i en database, så en admin (mig :p) kan logge ind på en admin-sektion og skrive uge-oversigter ud.
Måske det er nemmere at lave en drop-down boks som er præ-udfyldt med ugenr og så 5 "kryds-af-bokse" (hva fanden hedder de nu?) og så nøjes med at gemme den info i databasen, sammen med brugerID?
#3
Ja, jeg har kigget på datetime, men jeg er ikke sikker på, at den kan bruges i det her projekt.
edit:
Det er MySQL og PHP jeg benytter.
#2
Det skal bruges, helt specifikt, til at folk logger ind på en webside, vælger en uge (uge 33, 34 w/e), får en popup, hvor de så skal krydse af, hvilke dage de er i bygningen. Denne info skal så gemmes i en database, så en admin (mig :p) kan logge ind på en admin-sektion og skrive uge-oversigter ud.
Måske det er nemmere at lave en drop-down boks som er præ-udfyldt med ugenr og så 5 "kryds-af-bokse" (hva fanden hedder de nu?) og så nøjes med at gemme den info i databasen, sammen med brugerID?
#3
Ja, jeg har kigget på datetime, men jeg er ikke sikker på, at den kan bruges i det her projekt.
edit:
Det er MySQL og PHP jeg benytter.
Man bør gemme som datetime, da det tillader meget bedre kontrol fra databasen!fidomuh (7) skrev:Saa kan jeg gemme alle entries som unixtime. :)
Google lidt så, og læs op på det. Både PHP og SQL har et stort dato API.XorpiZ (8) skrev:Det kan jeg ikke gennemskue, må jeg erkende.
Som sagt, skal du ikke bruge din database til andet end at gemme hvilke dage folk er på arbejde, dvs. et [UserId] felt/nøgle, og et [Working] felt, med typen DateTime.
Og så laver du resten i PHP, dynamisk opbygget.
Eksempel på ideelt Javascript komponent du kan benytte dig af:
http://developer.yahoo.com/yui/examples/calendar/e...
http://developer.yahoo.com/yui/examples/calendar/e...
#1
Kalender systemer er normalt ret giftige at lave men dine behov virker ret simple, så det bør være muligt med en relativt simpel løsning.
Tabel struktur:
status
------
ansatid,FK->ansat,PK,INTEGER
dag,PK,DATE
inde,BOOLEAN
ansat
-----
ansatid,PK,INTEGER
navn,VARCHAR
...
Query for at finde dem som er inde for en given dag:
SELECT navn
FROM status,ansat
WHERE status.ansatid=ansat.ansatid AND dag=? AND inde
ORDER BY navn
Query for at finde dem som er inde for en uge:
SELECT dag,navn
FROM status,ansat
WHERE status.ansatid=ansat.ansatid AND dag >= ? AND dag <= ? AND inde
ORDER BY dag,navn
Query for at finde hvor mange som er inde for en uge:
SELECT dag,COUNT(*) AS n
FROM status,ansat
WHERE status.ansatid=ansat.ansatid AND dag >= ? AND dag <= ? AND inde
GROUP BY dag
ORDER BY dag
Query for at finde dem som ikke har udfyldt for en uge:
SELECT navn
FROM ansat
WHERE ansatid NOT IN (SELECT ansatid FROM status WHERE dag >= ? AND dag <= ?)
Indtastning fungerer som:
- side med uge valgs combo box
- bruger vælger uge
- side med 5/6/7 dage med hver deres checkbox
- bruger checker af
- 5/6/7 INSERT udføres
Kalender systemer er normalt ret giftige at lave men dine behov virker ret simple, så det bør være muligt med en relativt simpel løsning.
Tabel struktur:
status
------
ansatid,FK->ansat,PK,INTEGER
dag,PK,DATE
inde,BOOLEAN
ansat
-----
ansatid,PK,INTEGER
navn,VARCHAR
...
Query for at finde dem som er inde for en given dag:
SELECT navn
FROM status,ansat
WHERE status.ansatid=ansat.ansatid AND dag=? AND inde
ORDER BY navn
Query for at finde dem som er inde for en uge:
SELECT dag,navn
FROM status,ansat
WHERE status.ansatid=ansat.ansatid AND dag >= ? AND dag <= ? AND inde
ORDER BY dag,navn
Query for at finde hvor mange som er inde for en uge:
SELECT dag,COUNT(*) AS n
FROM status,ansat
WHERE status.ansatid=ansat.ansatid AND dag >= ? AND dag <= ? AND inde
GROUP BY dag
ORDER BY dag
Query for at finde dem som ikke har udfyldt for en uge:
SELECT navn
FROM ansat
WHERE ansatid NOT IN (SELECT ansatid FROM status WHERE dag >= ? AND dag <= ?)
Indtastning fungerer som:
- side med uge valgs combo box
- bruger vælger uge
- side med 5/6/7 dage med hver deres checkbox
- bruger checker af
- 5/6/7 INSERT udføres
#9
Nej tak.
Jeg har specifikt valgt at bruge unixtime, da det er hvad jeg bruger allesteder, i alle tabeller, alle programmer og generelt alt hvad jeg selv laver.
Kan du give mig et godt argument for at konvertere til unixtime efter jeg har hevet datetime ud?
( Hvis det da kan konverteres direkte? :) )
Man bør gemme som datetime, da det tillader meget bedre kontrol fra databasen!
Nej tak.
Jeg har specifikt valgt at bruge unixtime, da det er hvad jeg bruger allesteder, i alle tabeller, alle programmer og generelt alt hvad jeg selv laver.
Kan du give mig et godt argument for at konvertere til unixtime efter jeg har hevet datetime ud?
( Hvis det da kan konverteres direkte? :) )
Et godt gæt er så at du aldrig arbejder med SQL, Java, C#, eller skriver WebService APIs ?fidomuh (13) skrev:Jeg har specifikt valgt at bruge unixtime, da det er hvad jeg bruger allesteder, i alle tabeller, alle programmer og generelt alt hvad jeg selv laver.
For ikke at nævne alle de andre sprog som IKKE basere deres API på unixtime. Jeg kan faktisk kun tænke på C/C++, og PHP, som gør det.
Med typisk ORM kan du jo netop mappe et DATE eller DATETIME field til en specifik type direkte, hvor unixtime er et Integer felt, og derfor kræver ekstra mapping, hvis det givne ORM framework overhovedet tillader det.
At der ALDRIG er en grund til at konvertere det i første omgang, hvis du arbejder i hvilket som helst andet sprog end PHP? ;-)fidomuh (13) skrev:Kan du give mig et godt argument for at konvertere til unixtime efter jeg har hevet datetime ud?
#7, 9, 13, 16
Unix tid er ikke i sig selv et problem i hverken Java eller .NET da deres interne tids repræsentation er en lineær funktion af Unix tid.
Men det er vigtigt at man vælger en data type i databasen er en en tids type.
Det giver nemlig mulighed for at bruge de indbyggede tids funktioner i SQL.
Hvordan databasen faktisk opbevarer den tids type er helt transparent.
MySQL har f.eks. både en DATETIME type som gemmes som yyyymmdd og hhmmss og en TIMESTAMP type som gemmes som Unix tid.
I de fleste tilfælde er det ligegyldigt om man vælger den ene eller den anden.
Den største forskel er at Unix tid er UTC tid ikke lokal tid.
Unix tid er ikke i sig selv et problem i hverken Java eller .NET da deres interne tids repræsentation er en lineær funktion af Unix tid.
Men det er vigtigt at man vælger en data type i databasen er en en tids type.
Det giver nemlig mulighed for at bruge de indbyggede tids funktioner i SQL.
Hvordan databasen faktisk opbevarer den tids type er helt transparent.
MySQL har f.eks. både en DATETIME type som gemmes som yyyymmdd og hhmmss og en TIMESTAMP type som gemmes som Unix tid.
I de fleste tilfælde er det ligegyldigt om man vælger den ene eller den anden.
Den største forskel er at Unix tid er UTC tid ikke lokal tid.
Jeg vil stadig fraråde det i .NET, da ORM frameworks som Linq2Entities er svære at skrive manuelle mappings til.arne_v (17) skrev:Unix tid er ikke i sig selv et problem i hverken Java eller .NET da deres interne tids repræsentation er en lineær funktion af Unix tid.
Det er vel også ret meningsløst at gemme som UNIXTIME, når både SQL og alle ORM produkter, baserere sine APIs på at det er DATE/DATETIME.
Jeg ser sjældent andre end PHP udviklere gøre det, fordi de ikke har et særlig godt date/time API til rådighed.
Lige et spørgsmål - ikke så meget om SQL, men det er vel mere simpel HTML eller PHP.
Jeg har lavet en dropdown-boks jeg autopopulater med en for-løkke, hvilket virker fint.
Dernæst har jeg lavet en check-box, bare for at teste lidt.
Men!
Jeg kan ikke få begge dele med over, når jeg trykker "Submit". Enten må jeg nøjes med værdien fra dropdown-boksen eller også må jeg nøjes med værdien fra check-boxen.
Dette er min kode, der fylder dropdown-menuen ud. AntalUger() er en funktion, der regner ud hvor mange uger, der er i det aktuelle år. Den er ikke så vigtig her.
Dette er koden, der laver checkboxen - ikke noget avanceret overhovedet. Det eneste "takereg.php" laver er bare
Men
Jeg har lavet en dropdown-boks jeg autopopulater med en for-løkke, hvilket virker fint.
Dernæst har jeg lavet en check-box, bare for at teste lidt.
Men!
Jeg kan ikke få begge dele med over, når jeg trykker "Submit". Enten må jeg nøjes med værdien fra dropdown-boksen eller også må jeg nøjes med værdien fra check-boxen.
<form action="takereg.php" method="get" name="uge">
<select name="ugenr" class="dropdownmenus">
<option selected></option>
<?php
$uger = AntalUger();
for ($i= 1; $i <= $uger; $i++)
{
echo "<option value='$i'>$i</option>";
}
?>
</select></form>
Dette er min kode, der fylder dropdown-menuen ud. AntalUger() er en funktion, der regner ud hvor mange uger, der er i det aktuelle år. Den er ikke så vigtig her.
<form action="takereg.php" method="get" name="uge">
<input name="mandag" type="checkbox" checked="checked">
<INPUT type="submit" value="search">
</form>
Dette er koden, der laver checkboxen - ikke noget avanceret overhovedet. Det eneste "takereg.php" laver er bare
echo $_GET['ugenr'];
echo $_GET['mandag'];
Men
#16
SQL, relativt ofte, men aldrig direkte.
( Det er, imo, ikke det SQL er designet til )
Og i det tilfaelde benytter jeg alligevel altid UnixTime, saa hvorfor skulle jeg faa en direkte fordel af at benytte datetime?
( Udover at jeg med unixtime skal konvertere foerst, selvfoelgelig )
Det er saa ogsaa de to eneste sprog jeg umiddelbart interesserer mig for, samt at jeg ikke umiddelbart bruger andres frameworks, men holder mig til de ting jeg selv laver :)
ORM?
Altsaa kan jeg hive, fx, mm ud af yymmddhhmmss ?
Det kraever selvfoelgelig ikke en direkte konvertering, men stadig et indgreb.
JEg har endnu ikke vaeret i en situation hvor jeg ikke var glad for at bruge unixtime.
DATETIME brugte jeg i starten, men gik over til unixtime stortset med det samme.
( eller TIMESTAMP )
How so?
Hvordan faar du "Januar" ud af 090122153452 ?
- Du har selvfoelgelig en funktion der laver det output tll dig.
Det har jeg ogsaa: date("M",'090122153452'), som ioevrigt ogsaa bruges i linux/unix date kommandoen. :)
Et godt gæt er så at du aldrig arbejder med SQL, Java, C#, eller skriver WebService APIs ?
SQL, relativt ofte, men aldrig direkte.
( Det er, imo, ikke det SQL er designet til )
Og i det tilfaelde benytter jeg alligevel altid UnixTime, saa hvorfor skulle jeg faa en direkte fordel af at benytte datetime?
( Udover at jeg med unixtime skal konvertere foerst, selvfoelgelig )
For ikke at nævne alle de andre sprog som IKKE basere deres API på unixtime. Jeg kan faktisk kun tænke på C/C , og PHP, som gør det.
Det er saa ogsaa de to eneste sprog jeg umiddelbart interesserer mig for, samt at jeg ikke umiddelbart bruger andres frameworks, men holder mig til de ting jeg selv laver :)
Med typisk ORM
ORM?
kan du jo netop mappe et DATE eller DATETIME field til en specifik type direkte
Altsaa kan jeg hive, fx, mm ud af yymmddhhmmss ?
Det kraever selvfoelgelig ikke en direkte konvertering, men stadig et indgreb.
hvor unixtime er et Integer felt, og derfor kræver ekstra mapping, hvis det givne ORM framework overhovedet tillader det.
JEg har endnu ikke vaeret i en situation hvor jeg ikke var glad for at bruge unixtime.
DATETIME brugte jeg i starten, men gik over til unixtime stortset med det samme.
( eller TIMESTAMP )
At der ALDRIG er en grund til at konvertere det i første omgang, hvis du arbejder i hvilket som helst andet sprog end PHP? ;-)
How so?
Hvordan faar du "Januar" ud af 090122153452 ?
- Du har selvfoelgelig en funktion der laver det output tll dig.
Det har jeg ogsaa: date("M",'090122153452'), som ioevrigt ogsaa bruges i linux/unix date kommandoen. :)
#18
SQL benytter TIMESTAMP, som er UNIXTIME.
Og hvilke APIs er det vi snakker om her?
Jeg har umiddelbart en del forskellige programmer der fint understoetter unixtime.
Eller ogsaa er folk bare helt fint tilfredse med at gemme i unixtime.
Jeg er i hvert fald.
Det er vel også ret meningsløst at gemme som UNIXTIME, når både SQL og alle ORM produkter, baserere sine APIs på at det er DATE/DATETIME.
SQL benytter TIMESTAMP, som er UNIXTIME.
Og hvilke APIs er det vi snakker om her?
Jeg har umiddelbart en del forskellige programmer der fint understoetter unixtime.
Jeg ser sjældent andre end PHP udviklere gøre det, fordi de ikke har et særlig godt date/time API til rådighed.
Eller ogsaa er folk bare helt fint tilfredse med at gemme i unixtime.
Jeg er i hvert fald.
Nå - tilbage til PHP'en :p
Nu er det som sagt lykkedes mig at få ugenr med over og så værdien af de 5 checkbokse jeg har lavet (man-fre).
Men hvordan er det lige, jeg skal komme fra f.eks. 33,1 (mandag i uge 33) til en rigtig "date" værdi, som SQL kan forstå, og som jeg kan sammenligne på?
Og ville det ikke have været nemmere, hvis jeg tilføjede en kolonne til den tabel arne_v kom med?
Så istedet for:
ansatid,FK->ansat,PK,INTEGER
dag,PK,DATE
inde,BOOLEAN
ville det være
ansatid,FK->ansat,PK,INTEGER
dag,PK,int
uge, int
inde,BOOLEAN
Så kan jeg bare gemme uge 33 og 1 uden at skulle konvertere det til et andet format først.
Nu er det som sagt lykkedes mig at få ugenr med over og så værdien af de 5 checkbokse jeg har lavet (man-fre).
Men hvordan er det lige, jeg skal komme fra f.eks. 33,1 (mandag i uge 33) til en rigtig "date" værdi, som SQL kan forstå, og som jeg kan sammenligne på?
Og ville det ikke have været nemmere, hvis jeg tilføjede en kolonne til den tabel arne_v kom med?
Så istedet for:
ansatid,FK->ansat,PK,INTEGER
dag,PK,DATE
inde,BOOLEAN
ville det være
ansatid,FK->ansat,PK,INTEGER
dag,PK,int
uge, int
inde,BOOLEAN
Så kan jeg bare gemme uge 33 og 1 uden at skulle konvertere det til et andet format først.
#29
Ja, som jeg skrev, det ville vaere piece of cake, hvis du havde brugt unixtime fra starten af :)
Men jeg vil overlade det til Windcape og Arne_v, da den nemmeste loesning imo er at bruge unixtime helt fra starten :)
[add]
Som en ret daarlig loesning kunne du jo finde foerste dag i foerste uge, regne +33 uger og saa tjekke om date("w",[timestamp]) giver dig 33 :)
Ja, som jeg skrev, det ville vaere piece of cake, hvis du havde brugt unixtime fra starten af :)
Men jeg vil overlade det til Windcape og Arne_v, da den nemmeste loesning imo er at bruge unixtime helt fra starten :)
[add]
Som en ret daarlig loesning kunne du jo finde foerste dag i foerste uge, regne +33 uger og saa tjekke om date("w",[timestamp]) giver dig 33 :)
Hvis vi kalder et DATETTIME field for "PostDate", så:fidomuh (22) skrev:Hvordan faar du "Januar" ud af 090122153452 ?
.PostDate.Month
Ikke mit problem at PHP stadigvæk ikke har et ordeligt tidsapi.
Derudover kan jeg lave .PostDate.ToString("dd-mm-yyyy") hvis det passer mig :)
Pointen er at når man mapper et DATE eller DATETIME field får du i et objekt-orienteret sprog, adgang til alle methoder der nu skulle være tilhørende et tidsobjekt.
Hvis du bare har en integer... så skal du skrive ekstra kode for at opnå det samme!
#30
Jeg er slet ikke med på, hvordan det skulle have været gjort anderledes :)
Men nå, nu har jeg vist fundet noget brugbart:
Den er godt nok lige en uge for langt fremme, men nu begynder det hvertfald at ligne noget :P
Jeg er slet ikke med på, hvordan det skulle have været gjort anderledes :)
Men nå, nu har jeg vist fundet noget brugbart:
function week_start_date($wk_num, $yr, $first = 1, $format = 'F d, Y')
{
$wk_ts = strtotime('+' . $wk_num . ' weeks', strtotime($yr . '0101'));
$mon_ts = strtotime('-' . date('w', $wk_ts) + $first . ' days', $wk_ts);
return date($format, $mon_ts);
}
$sStartDate = week_start_date($week_number, $year);
$sEndDate = date('F d, Y', strtotime('+6 days', strtotime($sStartDate)));
Den er godt nok lige en uge for langt fremme, men nu begynder det hvertfald at ligne noget :P
Nej, det handler mere om når du skal foretage udregninger, sammenligninger osv.fidomuh (33) skrev:Saa manglen paa et ordentligt API er altsaa at jeg skal skrive...
Desuden så kan du jo netop med DATE/DATETIME som arne_v påpegede, lave SQL selects med MONTH/DAY/WEEK osv.
Hvis du kigger på min kode fra #3 , hvordan ville du skrive det pænt hvis du havde benyttet et timestamp?
#34
Jeg bruger ikke MS SQL, og har absolut ingen planer om nogensinde at goere det:
http://dev.mysql.com/doc/refman/5.0/en/date-and-ti...
Jeg kan ikke se problemet.
I dit eksempel faar du bare SQL serveren til at lave udregningen for dig, hvilket er fint, men det kan man ogsaa fint med MySQL - naar der bruges TIMESTAMP ( som er UnixTime ).
Saa jeg kan stadig ikke se hvad problemet er, eller hvorfor man ikke skulle bruge det.
Du kan starte med at forklare hvordan XorpiZ nemt kommer til det oenskede resultat.
Du har altsaa millisekunder i dit DATETIME field?
Saa "090122153452" indeholder millisekunder?
10, hvad er problemet?
Eller er det tidszoner vi snakker om?
Du maa lige uddybe lidt :)
- Er ikke noget jeg har haft brug for, overhovedet, men det vil vaere et problem i et system der regner tid ud fra en fastsat dato, sjovt nok :)
Jeg bruger ikke MS SQL, og har absolut ingen planer om nogensinde at goere det:
http://dev.mysql.com/doc/refman/5.0/en/date-and-ti...
Jeg kan ikke se problemet.
I dit eksempel faar du bare SQL serveren til at lave udregningen for dig, hvilket er fint, men det kan man ogsaa fint med MySQL - naar der bruges TIMESTAMP ( som er UnixTime ).
Saa jeg kan stadig ikke se hvad problemet er, eller hvorfor man ikke skulle bruge det.
Du kan starte med at forklare hvordan XorpiZ nemt kommer til det oenskede resultat.
Og så lidt drilleri:
Milisekunder?
Du har altsaa millisekunder i dit DATETIME field?
Saa "090122153452" indeholder millisekunder?
Skudsekunder?
10, hvad er problemet?
Eller er det tidszoner vi snakker om?
Du maa lige uddybe lidt :)
Datering før 1931 på 32-bit systemer?
- Er ikke noget jeg har haft brug for, overhovedet, men det vil vaere et problem i et system der regner tid ud fra en fastsat dato, sjovt nok :)
At alle funktionerne der bearbejder datoer der, benytter DATETIME som argument (faktisk en string, for at være præcis), ikke TIMESTAMP.fidomuh (36) skrev:#34
Jeg bruger ikke MS SQL, og har absolut ingen planer om nogensinde at goere det:
http://dev.mysql.com/doc/refman/5.0/en/date-and-ti...
Jeg kan ikke se problemet.
#37
Om strengen er DATETIME eller TIMESTAMP aendrer ikke paa du ikke bare magisk hiver "uge 33" ud af roeven.
Den skal udregne hvad uge det er ( eller slaa det op i en tabel ) - og i det tilfaelde er det praecis det samme anyway.
( Set fra brugerens oejne, om det er hurtigere performancemaessigt at bruge DATETIME ved jeg ikke, det er ikke noget jeg har bemaerket paa nogen af vores systemer )
Om strengen er DATETIME eller TIMESTAMP aendrer ikke paa du ikke bare magisk hiver "uge 33" ud af roeven.
Den skal udregne hvad uge det er ( eller slaa det op i en tabel ) - og i det tilfaelde er det praecis det samme anyway.
( Set fra brugerens oejne, om det er hurtigere performancemaessigt at bruge DATETIME ved jeg ikke, det er ikke noget jeg har bemaerket paa nogen af vores systemer )
http://dev.mysql.com/doc/refman/5.0/en/date-and-time-types.htmlfidomuh (38) skrev:Den skal udregne hvad uge det er
Igen, som du ser i #3, behøver jeg ikke kender time/minut eller sekundtal for at sætte eller udregne en dato.
Det giver ingen mening at benytte unixtime da det giver MINDST muligheder set fra SQL- og hvilket som helst andet sprogs synspunkt.
PHP er den absolutte eneste undtagelse.
Det er nærmere et spørgsmål om data integritet, end performance, da forskellen burde være minimal.fidomuh (38) skrev:om det er hurtigere performancemaessigt at bruge DATETIME ved jeg ikke, det er ikke noget jeg har bemaerket paa nogen af vores systemer
Noget der betyder noget i størrere systemer. Et gæt er vel at du også benytter en float/double til at håndtere pris/penge felter? ;)
En DBA ville også være enig med mig i at at benytte de typer som SQL kan manipulerer med, er en klar fordel.
Hvis det stadig skulle have interesse, så er det nu lykkedes mig at omregne brugerens input til noget min database kan forstå:
Ovenstående udregner datoen på den første dag i $year i $weeknr., men returnerer det i MM/DD/YYYY.
Og så er det bare at lave:
for at få det skrevet ud i YYYY-MM-DD :)
edit:
Bah, lorte linjeskift.. :<
function getFirstDayOfWeek($year, $weeknr)
{
$offset = date('w', mktime(0,0,0,1,1,$year));
$offset = ($offset < 5) ? 1-$offset : 8-$offset;
$monday = mktime(0,0,0,1,1+$offset,$year);
$date = strtotime('+' . ($weeknr - 1) . ' weeks', $monday);
return date('m/d/Y',$date);
}
Ovenstående udregner datoen på den første dag i $year i $weeknr., men returnerer det i MM/DD/YYYY.
Og så er det bare at lave:
echo strftime("%Y-%m-%d", strtotime(getFirstDayOfWeek($year, $week_number)));
for at få det skrevet ud i YYYY-MM-DD :)
edit:
Bah, lorte linjeskift.. :<
windcape (44) skrev:Ja, men det er jo forkert.
Første dag i uge 1, i 2009, er en Torsdag.
Nåååh på den måde. Det er korrekt til mit brug, da den første dag i uge 1 (i 2008/9) er mandag den 29. december 2008.
Og selvom uge 1 i 2009 starter med en torsdag, så er den første dag i uge 1 vel stadig mandag?
#39
Sandt, men:
Udgangspunktet i Unixtime er jo egentligt at du slet ikke skal rode med det manuelt, men at alt er haandteret af systemet.
Deri skal jeg heller ikke kende sekund, minut elelr time, for at lave en unixtime, men jeg kan se din pointe.
Det giver bare ikke nogen mening for mig at bruge noget andet end unixtime til timestamps, da det ( imo ) er vaesentligt nemmere at arbejde med.
Fx hele uge problematikken her, ville vaere ufatteligt nemt hvis bare man bruge unixtime.
Det giver rigeligt muligheder i PHP og C/C , SQL ser jeg ikke som et selvstaendigt system, saa det goer mig ikek noget at det ikke forstaar Unixtime ( selvom jeg finder det direkte ulogisk ikke at understoette det ).
Sandt, men:
Igen, som du ser i #3, behøver jeg ikke kender time/minut eller sekundtal for at sætte eller udregne en dato.
Udgangspunktet i Unixtime er jo egentligt at du slet ikke skal rode med det manuelt, men at alt er haandteret af systemet.
Deri skal jeg heller ikke kende sekund, minut elelr time, for at lave en unixtime, men jeg kan se din pointe.
Det giver bare ikke nogen mening for mig at bruge noget andet end unixtime til timestamps, da det ( imo ) er vaesentligt nemmere at arbejde med.
Fx hele uge problematikken her, ville vaere ufatteligt nemt hvis bare man bruge unixtime.
Det giver ingen mening at benytte unixtime da det giver MINDST muligheder set fra SQL- og hvilket som helst andet sprogs synspunkt
Det giver rigeligt muligheder i PHP og C/C , SQL ser jeg ikke som et selvstaendigt system, saa det goer mig ikek noget at det ikke forstaar Unixtime ( selvom jeg finder det direkte ulogisk ikke at understoette det ).
Men udgangspunket i databaser er jo typisk at det IKKE er håndteret 100% af systemet.fidomuh (46) skrev:Udgangspunktet i Unixtime er jo egentligt at du slet ikke skal rode med det manuelt, men at alt er haandteret af systemet.
Og nej, det bliver ikke nemmere hvis du benytter unixtime. Det er ligeså besværligt, fordi der benyttes PHP i første omgang.
#40
Hvilket problem er der da med data integritet?
Jeg bruger unixtime overalt, saa det er nemt at bruge i alle systemer jeg benytter.
Det er PHP, saa jeg kan ikke fortaelle dig om det er en INT eller en Float :(
( hvilket du sikkert godt kender problematikken ved )
Han vil sikkert ogsaa forklare dig at MS SQL er det bedste SQL system i verden.
( Et stykke papir er ikke ensbetydende med at man ved hvad man snakker om )
Det er nærmere et spørgsmål om data integritet, end performance, da forskellen burde være minimal.
Hvilket problem er der da med data integritet?
Jeg bruger unixtime overalt, saa det er nemt at bruge i alle systemer jeg benytter.
Noget der betyder noget i størrere systemer. Et gæt er vel at du også benytter en float/double til at håndtere pris/penge felter? ;)
Det er PHP, saa jeg kan ikke fortaelle dig om det er en INT eller en Float :(
( hvilket du sikkert godt kender problematikken ved )
En DBA ville også være enig med mig i at at benytte de typer som SQL kan manipulerer med, er en klar fordel.
Han vil sikkert ogsaa forklare dig at MS SQL er det bedste SQL system i verden.
( Et stykke papir er ikke ensbetydende med at man ved hvad man snakker om )
Pointen var nu at man ikke må benytte floats til penge :p Der er en specifik type "Money" (DECIMAL i MySQL) som bør benyttes til finacielle data, da det skal være så præcist som muligt.fidomuh (49) skrev:Det er PHP, saa jeg kan ikke fortaelle dig om det er en INT eller en Float :(
Jeg tænker mere specifikt på at en database kan tilgåes fra flere systemer, hvorfor det naturligvis giver mest mening at benytte databasens givne typer for forskellige operationer (thus, DateTime).fidomuh (49) skrev:Hvilket problem er der da med data integritet?
Forhåbenlig ikke.fidomuh (49) skrev:Han vil sikkert ogsaa forklare dig at MS SQL er det bedste SQL system i verden.
Oracle og DB2 er jo selvsagt i den sammenhæng, men jeg har også snakket med en del udviklere som mener at PgSQL er på niveau (endda bedre) end Oracle.
Typisk vælges der database (i det størrelsesniveau) på baggrund af features. (bla. PL/SQL for Oracle).
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund