Je kent het wel.. Een script en er word varchar gebruikt.. honderden reacties dat date() functie beter is.. Ok. Zal wel :|
Wat ik dan niet snap is waarom dat beter is als de UNIX_TIMESTAMP() ? Zover ik weet kan de date() functie van MySQL geen date('D', time()) nadoen.. Ikzelf vind het ook veel makelijker om met unix timestamp / time() de verschillen uit te rekenen tussen datums.. Sowieso is voor de minder ervaren programmeurs PHP makelijker dan de SQL functie date()
(Ikzelf snap namelijk geen fuck van die hele date() functie in SQL, wat misschien deze hele post veroorzaakt)
Edit, *me wacht vol verwachting op een reactie van pgFrank die het hem helemaal precies gaat uitleggen ^,^*
ModEdit
Waarom je dit bij 'Admin / mods hulp' hebt gezet is mij een raadsel. Persoonlijk vind ik het meer 'Koffiehoek', maar ik zal het topic verplaatsen naar 'Databases & SQL'.
Er is altijd al een groep programmeurs geweest die de logica graag in de DB heeft heeft. Een andere groep programmeurs verwerkt de logica in het programma/website.
Mijns inziens heeft de eerste methode de voorkeur, daar valt ook het rekenen met datum en tijd onder.
Waarom dat zo is?? Ja dat is gewoon zo.....
Wat heeft het opslaan van een datum als datum nu met programmeurs en logica te maken? Je dient er voor te zorgen dat je een datum maar op 1 manier kán opslaan en dat je hier nog eens iets mee kunt. Een varchar kun je de grootst mogelijke onzin in zetten, die valt dus al direct af. Of is 'broodje aap' een geldige datum? 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...
Met SQL en de juiste datatypes ben je dus veel sneller klaar en heb je zekerheid over de resultaten. Wanneer je zelf het wiel gaat uitvinden, zul je ook van a tot z de boel moeten gaan testen en laten testen om te zien of het ook goed werkt. In 99 van de 100 gevallen is dat niet het geval en in dat ene gevalletje dat het wel goed werkt, ben je veel langer bezig. Je verliest dus altijd.
Met het gebruik van bewezen techniek kun jij veel betere applicaties bouwen in veel kortere tijd.
Logica in de database zetten, dus stored procedures gebruiken, dat is erg leuk, maar een hele andere discussie. Dat heeft niks te maken met de keuze van de juiste datatypes voor je data.
Mijn inziens is het kiezen van de juiste veldtypes ook een vorm van logica. Met het gebruiken van het DATE type voor een datumveld creeer je eigenlijk een constraint want de Db bepaald of de gegevens aan het type voldoen. Bovenstaande kan je natuulijk ook met programmacode oplossen.
Vandaar dat ik het genruiken van de juiste veldtypen schaar onder het kopje logica.
Ik ben overigens met je eens dat je zoveel mogelijk gebruik moet maken van de functies die een DB gebruikt ( op het werk doe ik niet anders)
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.
Valt wel mee.
<?php
while ($rows = mysql_fetch_object($result) {
$datum = date("D", $rows->tijd);
if ($datum == 'Mon') {
// Gepost op maandag
} else {
// Gepost op andere dag
}
}
?>
Wat dat betreft niet zo lastig, en na die // Gepost op maandag kan je nog iets verder gaan met date("H", $rows->tijd) enz.. enz..
Maar dat is niet ontopic, mijn punt is: Waarom vinden heel veel mensen date() in MySQL makelijker rekenen? Want ik zie er eerlijk gezegd het übergrote voordeel niet van in.
(/me is nu weg en leest morgen verder)
EDIT 1: Wat ik ook nog wou zeggen, als je van het sql veld int(12) maakt cover je altijd de unix timestamp voor de volgende eeuwen, want die is 10 getalletjes lang =]
Zonder dit soort "logica" kun je de DBMS beter weggooien, je houdt jezelf dan alleen maar voor de gek. Je wilt een DBMS gebruiken, maar alle mogelijkheden van de DBMS weiger je te gebruiken... Tja, csv doet het dan ook wel, wel zo duidelijk.
En wat als je nu eens 25 miljoen records in je database hebt staan (is nog echt niet veel hoor) en alleen die records van een maandagochtend wilt hebben? Ga jij dan eerst alle records ophalen (hoeveel GB hebben we het dan over?) en dan nog eens per record de boel vergelijken? Laat maar vast koffie en pizza's aanrukken, voordat jouw script klaar is, zijn de pizza's al weer koud...
En ga dan ook eens opvragen welke users op maandagochtend tussen 08:00 - 10:00 en vrijdagmiddag tussen 13:00 - 14:00 een topic plaatsen. Zorg dat je ook een slaapzak bij de hand hebt.
Wat ik dus zeggen wil, je gaat geen database opzetten voor het opslaan van een tiental records. Ook draait het niet om het opslaan, maar om het beschikbaar stellen van de data. Opslaan van 1 of enkele records (vrijwel altijd het geval) gaat altijd snel en kan heel eenvoudig zonder enige controle. Maar het beschikbaar stellen van de data, dat is een ander verhaal. En dat is wel waar je de kracht van een database nodig hebt.
Denk groot en denk vooral in meerdere gebruikers die van alles aan het uitspoken zijn.
Het grote voordeel van een datum als datum opslaan? Zoals hier wordt genoemd kun je er talloze functies op uitvoeren.
Wat jij hier laat zien is hetzelfde als naar een parkeergarage gaan, alle auto's eruit rijden en dan alleen de rode gebruiken....(Je haalt alle data op, maar gebruikt maar een klein deel van de data)
Luister maar naar pgFrank, dat lijkt me een wijze man ;-)
Volgens mij ligt het vooral aan de keuze of je de database als (deel van) je applicatie gaat zien, of puur als opslag, als een 'domme' database.
Het voordeel van een applicatie in een database maken is dat je de checks en de berekeningen dicht bij de data hebt. Daardoor is het sneller dan wanneer het wat verder van elkaar af staat - zoals het geval is bij databases en PHP - en is het vrijwel onmogelijk om om de checks heen te komen. Nadeel is dat 'deployment' lastiger is, en ontwikkeling mogelijk ook omdat je werkt met verschillende talen en ondergronden. Vanuit de database heb je niet alle mogelijkheden die bijvoorbeeld PHP je biedt, en PHP heeft niet de mogelijkheid om direct alle data aan te spreken.
Het wordt een ander verhaal wanneer het wat dichter bij elkaar zit. Stel dat je applicatie in C++ o.i.d. is - en belangrijker - maar 1 maal hoeft op te starten en zijn geheugen, z'n state behoudt, dan denk ik dat het in veel gevallen best aan te raden is om een "domme" database te gebruiken. Aangezien je een vertaalslag vrijwel volledig mist kan je direct vanuit je applicatie in je database rommelen en heb je niet de overbodigheid van 2 talen die langs elkaar lopen.
Voor kleinere websites, bijvoorbeeld een simpel CMS waarmee je pagina's kan maken, gebruik ik persoonlijk liever een domme database, en als ik helemaal de vrijheid heb ook nog eentje die niet gebonden is aan tabellen maar aan documenten (bijv. couchdb) waardoor je als het ware een hele vertaalslag in je programmeerwerk kan overslaan. In een ouderwetse database ben je gelimiteerd tot tabellen, kolomemen en regels. Leuk, maar wanneer je een HTML pagina bekijkt, en kijkt naar de elementen die erin zitten is dat niet 1 op 1 te vertalen naar kolommen en regels. Er zit ook nog een hiërarchie in. En dan zit je al weer te klooien met relaties. En aangezien je in een traditionele database en SQL gelimiteerd bent tot het binnentrekken van kolommen en regels zal je in je PHP gedeelte (of in je query met SQL commando's XML functies aanroepen) nog de hiërarchie uit de resultaten moeten destileren. Waarom zou je die hiërarchie niet gewoon in 1 keer kunnen opslaan en via bijvoorbeeld XPath of in het geval van CouchDB gewoon Javascript er in 1 geheel uittrekken. Ik denk dat dit voor vooral kleinere applicaties (en geef toe, de meeste websites zijn kleinschalig) een veel snellere ontwikkelmethode is.
Frank, volgende keer graag ook die quote en reactie in je eerdere bericht plaatsen.
@Wesley
Met een datum kan je veel gemakkelijker rekenen dan een UNIX timestamp. Daarnaast haal je uit je database in principe nooit je timestamp op, maar wil je een datum weergeven. (dat is veel herkenbaarder voor een bezoeker/ gebruiker)
Waarom zou je het er anders inzetten dan dat je het eruit wil halen? Daar kan volgens mij geen goede reden achter zitten. Daarnaast, pgFrank geeft het al aan, kan je met een datum in SQL ook supersnel rekenen. Je laat dan SQL bepalen welke records op een maandag vallen, en alleen deze krijg je terug.
Probeer de dingen in een database zo op te slaan dat ze op een zo eenvoudig mogelijke manier te gebruiken zijn voor de weergave aan een gebruiker. Let hierbij WEL op de juiste datatypes, omdat deze zorgen voor een deel van de controle.
