SQL verslavingen..
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'.
SanThe.
SanThe.
Gewijzigd op 01/01/1970 01:00:00 door Wesley
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.....
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)
Groeten
Klaasjan
Quote:
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.
Code (php)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
<?php
while ($rows = mysql_fetch_object($result) {
$datum = date("D", $rows->tijd);
if ($datum == 'Mon') {
// Gepost op maandag
} else {
// Gepost op andere dag
}
}
?>
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 =]
Gewijzigd op 01/01/1970 01:00:00 door Wesley
Wesley schreef op 25.04.2008 22:14:
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...Valt wel mee.
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.
Gewijzigd op 01/01/1970 01:00:00 door Frank -
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 ;-)
klystr schreef op 25.04.2008 22:55:
Wijze woorden zo op de vrijdagavond!Luister maar naar pgFrank, dat lijkt me een wijze man ;-)
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.
mod_modus:
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.
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.
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.
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.
Quote:
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.
Gewijzigd op 01/01/1970 01:00:00 door Martijn B
http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html
DAYOFWEEK() kan handig zijn voor je
In het geheel (DAYOFWEEK() 2 betekend maandag) :
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
SELECT
column
FROM
table
WHERE
DAYOFWEEK(datum) = 2
AND
HOUR(datum)
BETWEEN
6
AND
12
column
FROM
table
WHERE
DAYOFWEEK(datum) = 2
AND
HOUR(datum)
BETWEEN
6
AND
12
Code (php)
1
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.
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.
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..