SQL verslavingen..

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Pagina: 1 2 3 volgende »

Wesley

Wesley

25/04/2008 21:42:00
Quote Anchor link
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'.

SanThe.
Gewijzigd op 01/01/1970 01:00:00 door Wesley
 
PHP hulp

PHP hulp

05/10/2022 13:58:28
 
Klaasjan Boven

Klaasjan Boven

25/04/2008 21:49:00
Quote Anchor link
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.....
 
Frank -

Frank -

25/04/2008 22:00:00
Quote Anchor link
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.
 
Klaasjan Boven

Klaasjan Boven

25/04/2008 22:10:00
Quote Anchor link
Frank,

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
 
Wesley

Wesley

25/04/2008 22:14:00
Quote Anchor link
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)
PHP script in nieuw venster Selecteer het PHP script
1
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
 }
}

?>


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
 
Frank -

Frank -

25/04/2008 22:17:00
Quote Anchor link
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.
 
Frank -

Frank -

25/04/2008 22:21:00
Quote Anchor link
Wesley schreef op 25.04.2008 22:14:
Valt wel mee.
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.
Gewijzigd op 01/01/1970 01:00:00 door Frank -
 
Klystr

klystr

25/04/2008 22:55:00
Quote Anchor link
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 ;-)
 
Frank -

Frank -

25/04/2008 22:59:00
Quote Anchor link
klystr schreef op 25.04.2008 22:55:
Luister maar naar pgFrank, dat lijkt me een wijze man ;-)
Wijze woorden zo op de vrijdagavond!
 
Jelmer -

Jelmer -

25/04/2008 23:00:00
Quote Anchor link
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.
 
Robert Deiman

Robert Deiman

25/04/2008 23:06:00
Quote Anchor link
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.
 
Jelmer -

Jelmer -

25/04/2008 23:18:00
Quote Anchor link
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.
 
Robert Deiman

Robert Deiman

25/04/2008 23:24:00
Quote Anchor link
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.
 
Frank -

Frank -

25/04/2008 23:49:00
Quote Anchor link
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.
 
Martijn B

Martijn B

26/04/2008 09:38:00
Quote Anchor link
Frank:
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
 
Crispijn -

Crispijn -

26/04/2008 09:52:00
Quote Anchor link
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
 
Robert Deiman

Robert Deiman

26/04/2008 10:03:00
Quote Anchor link
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) :

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
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    
 
Martijn B

Martijn B

26/04/2008 10:04:00
Quote Anchor link
Het is dan dus?:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
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.
 
Jurgen assaasas

Jurgen assaasas

26/04/2008 10:44:00
Quote Anchor link
Hoeft ook niet in een DATETIME kan ook een DATE zijn.
 
Robert Deiman

Robert Deiman

26/04/2008 11:23:00
Quote Anchor link
@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.
 
Wesley

Wesley

04/05/2008 20:59:00
Quote Anchor link
(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..
 

Pagina: 1 2 3 volgende »



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.