SQL verslavingen..

Om even bij DATE functies in de database te blijven: Zodra je je datum op formaat brengt in je SQL queries mix je logica & presentatie. Ik denk dat het niet aan je queries is om te beslissen dat je '10 uur geleden' of '12-05-2008 13:45' als datum gaat weergeven, maar aan je presentatielaag. Althans, als je je aan het MVC paradigma wilt houden. Zou je de results van queries naar models mappen, dan zou dus de query moeten weten of je de model gaat gebruiken om direct weer te geven, of om mee te rekenen (met '10 uur geleden' valt minder te rekenen) Ook is het formaat van de weer te geven datum afhankelijk van de plek waar hij wordt weergegeven. In een kalender zet je niet snel '10 uur geleden' neer.

Dus wanneer je de datums in formaat brengt binnen de database, ben je een laagje abstractie kwijt. Ik weet niet hoe jullie het zouden doen, ikzelf gebruik uiteindelijk altijd PHP's date functies om de datum die in mijn model zit om te zetten in een datum die ik wil weergeven. De DATE functies van de database zijn dan alleen nog handig voor het filteren en sorteren op datum. Ikzelf zou ze niet gebruiken in het SELECT gedeelte van een query - althans, niet voor het mooi maken van m'n datum. Voor eventueel rekenwerk, bijvoorbeeld vergelijken met andere data uit de db is het dan weer wel nuttig.

Daar heb je op zich wel gelijk in Jelmer, maar waarom zou je, als je toch al weet dat je die timestamp niet weer gaat geven, omdat die niet algemeen leesbaar is wel gebruiken? Daar ging het mij vooral om.

Met een datum kan je veel gemakkelijker berekeningen/ bepalingen doen (bijvoorbeeld alle gegevens die op de 20e dag van de maand vallen)

Daarnaast zorg ik in mijn query's wel dat ik een datum op de manier ophaal zoals ik hem weergegeven wil hebben. ("Onze" notatie, of met maanden voluit, laat ik allemaal vanuit de database doen)
De logica gebeurt nu al tijdens het uitlezen, en bewerkingen hoef je niet meer te doen als het al uitgelezen is, bevalt mij in elk geval beter. Maar zo heeft ieder zijn eigen werkwijze.

In de webwereld heb je al snel met diverse talen te maken, denk aan html, css, javascript, php en sql. xml en xslt kom ik ook regelmatig tegen, evenals PL/pgSQL, Xpath en Xquery. Dat zijn er dus al 10... 3 talen is wel het minimum wat je nodig hebt, zonder html, php en sql kun je onmogelijk een webbased php-applicatie met database maken. De overige talen zijn uitbreidingen of toevoegingen, dat lukt dan ook wel weer. Hoewel ik js nauwelijks foutloos weet te spellen...

Wat hier nog niet genoemd is, maar wat wel moet worden genoemd, is de data integriteit. Wanneer het niet uitmaakt dat de data van geen meter klopt of zelfs is verdwenen, dat hoef je hier geen aandacht aan te besteden, gebruik vooral de MyISAM-engine van MySQL, in alle andere gevallen zul je toch echt een slimme database (-engine) moeten gebruiken. Multiversion Concurrency Control is onmisbaar op een site met meerdere bezoekers die gelijktijdig van alles uitspoken. Zie de handleiding van PostgreSQL voor meer uitleg, in de MySQL-handleiding kun je er ook e.e.a. over vinden.

Een database gebruik je zelden of nooit voor heel weinig data voor slechts 1 user, men kan elkaar in de weg zitten en dat kun je met PHP onmogelijk controleren. Dat kan uitsluitend in de database, daar zul je dit dus moeten regelen.

Verder kunnen ook nog meerdere applicaties of websites van 1 database gebruik maken, dan wordt het vanuit jouw applicatie al helemaal onmogelijk om erop te vertrouwen dat een datum altijd als 'vier april tweeduizend acht' wordt opgeslagen...

Door alles met een slimme database te regelen, weet je zeker dat alles op één manier wordt verwerkt, correct en veilig is. Ook de toegang kan centraal worden geregeld, beveiliging is dus ook geregeld.

Hoever je dit gaat centraliseren in de database, dat is afhankelijk van o.a. kennis, kunde, hardware, software, wensen en voorkeuren. Ik doe het omdat ik het leuk vind en omdat het veilig is. Dat het wellicht niet de meest flexibele manier is, dat neem ik dan voor lief. Ik kan je wel garanderen dat de boel veilig is, dat is ook wat waard.

Frank:

Opslaan als Unix-rommel kan ook, maar dat begint pas bij 1-1-1970 en je kunt vrijwel onmogelijk hier analyses op loslaten. Ga maar eens uitzoeken welke records op een maandagmorgen zijn aangemaakt, dan zul je eerst met een stuk code alle mogelijke maandagochtenden moeten gaan berekenen. Vervolgens deze ellende vergelijken met de data in de database en dan heb je eindelijk de gewenste resultaten. In SQL heb je dat in 1 regeltje wel klaar...

Heb je hier ook informatie over?

Ik bedoel dus dat je met datetime/date alle maandagen of maandagmorgen,s uit de database kunt halen.

kijk eens even in de handleiding

http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html

DAYOFWEEK() kan handig zijn voor je

En voor de tijden op een maandagmorgen (laten we zeggen tussen 6:00 en 12:00) gebruik je natuurlijk BETWEEN.

In het geheel (DAYOFWEEK() 2 betekend maandag) :

SELECT
   column
FROM
    table
WHERE
    DAYOFWEEK(datum) = 2
AND
    HOUR(datum)
BETWEEN
    6
AND
    12    

Het is dan dus?:

SELECT * FROM tabel WHERE DAYOFWEEK(datumkolom) = 2

Voor alle maandagen.
Datetime heb ik niet in alle tabellen nodig maar dit zou wel mooi zijn in een statistieken tabel.

Hoeft ook niet in een DATETIME kan ook een DATE zijn.

@Martijn

In een datetime wordt de boel opgeslagen als:
2008-04-26 11:22:00
In een date wordt alleen het datumgedeelte opgeslagen.

Beiden kan je gebruiken om te rekenen met een datum, het voordeel van een datetime is (zeker met statistieken) dat je ook kan bepalen op welk uur van de dag de grootste drukte geeft op je website.

(Sorry voor giga bump wat ik hiermee veroorzaak maar ik ben nogal bezig geweest en had nu pas weer tijd voor het topic)

Reactie zelf:
------------------------------

Bij kleinere databases vind ik de unix timestamp toch wel degelijk makelijker rekenen.. Ook voor timebans is dit toch stukken makelijker? Ik reken liever met iets waarbij ik weet dat 60 1 minuut is, ipv dat ik in queries moet gaan kloten met datum min datte etc..