[SQL] Query op een query uitvoeren

[hell4you]

edit: Het betreft MySQL 5.x (sorry voor de titel)

Ik heb werkelijk alle mogelijke combinaties geprobeerd maar ik kom er niet meer uit

De tabel (voorbeeld):

meetID	meetwaarde	meetsoort	tijdstip
1	5.23	licht	2008-03-27 18:04:06
2	5.44	licht	2008-03-27 18:05:06
3	5.44	licht	2008-03-27 18:06:06
4	21	temp	2008-03-27 18:06:25
5	5.03	licht	2008-03-27 18:07:06

meetID: INT, auto_increment en primary key
meetwaarde: DOUBLE
meetsoort: TEXT
tijdstip: TIMESTAMP, current_timestamp

Nu wil ik de regel met meetID 3 eruit vissen, als zijnde de MAX meetwaarde voor de meetsoort "licht" met "tijdstip" als de hoogste waarde. De bedoeling is dat ik weergeef wanneer voor het laatst de hoogste meetwaarde is gemeten.
Belangrijk is dat tijdstip dus gekoppeld blijft aan de MAX meetwaarde.

Queries die wellicht van pas komen:

code:

SELECT
  MAX(`meetwaarde`),
  `tijdstip`,
  `meetID`,
  `meetsoort`
FROM `meting` 
WHERE `meetsoort` = 'licht'
GROUP BY `meetsoort`;

code:

SELECT
  MAX(`tijdstip`),
  `meetwaarde`,
  `meetsoort`
FROM `meting`
WHERE `meetsoort` = 'licht'
GROUP BY `meetwaarde`;

In principe moet ik deze 2 queries dus combineren op de een of andere manier

[ Voor 2% gewijzigd door hell4you op 27-03-2008 23:58 . Reden: titel correctie ]

[DirkT]

SELECT * FROM meting WHERE meetsoort='licht' ORDER BY meetwaarde DESC, tijdstip DESC LIMIT 1

[hell4you]

ok.. hij is goed... hij is heel goed

ik wist dus niet dat je op 2 dingen kon sorteren
tnx! dit had ik nodig, haha.. dat het zo simpel kan zijn

[Verwijderd]

Even een paar dingen:

1. Let op indexes hier. Ik weet dat SQL Server indexes kan sorteren in een gewenste volgorde wat het zoeken en sorteren in de gewenste richting dus sneller maakt. Hoe MySQL dit doet weet ik niet, maar deze kan in ieder geval indexeren. Ik zie aan je gegeven data dat je na een paar weken nogal wat records hebt, dus indexeren is zeker belangrijk. Ik kan niet zien of je dat wel of niet doet, maar ik zeg het maar even.

2. Meetwaarde is een double omdat er een temperatuur en een waarde voor lichtintensiteit in kan, maar schaalt dit lekker? Stel dat je meetwaarde een keer niet een getal is, maar bijvoorbeeld een foto. Ik zou dit doen:

Id | MeetType | Temperatuur | Lichtintensiteit | Tijdstip

Hier geef je dus in MeetType mee de soort meting, bijvoorbeeld 0 voor temperatuur en 1 voor lichtintensiteit, en kijk je vervolgens naar de goede kolom. De velden die niet van toepassing zijn, zijn dan uiteraard NULL. Het hele idee van inheritance met tabellen is ook op dit principe gebaseerd en is stukken schaalbaarder.

3. Waarom gebruik je een timestamp voor het tijdstip? Het klinkt logisch maar dat is het niet. Die timestamp is namelijk van je database server op het moment dat je record toegevoegd of gewijzigd wordt. Ik denk dat je het tijdstip wilt hebben dat de meting plaatsvond, dus moet je een gewoon date/time veld hebben en het betreffende tijdstip meegeven.

[curry684]

Verwijderd schreef op vrijdag 28 maart 2008 @ 00:46:
2. Meetwaarde is een double omdat er een temperatuur en een waarde voor lichtintensiteit in kan, maar schaalt dit lekker? Stel dat je meetwaarde een keer niet een getal is, maar bijvoorbeeld een foto. Ik zou dit doen:

Id | MeetType | Temperatuur | Lichtintensiteit | Tijdstip

Hier geef je dus in MeetType mee de soort meting, bijvoorbeeld 0 voor temperatuur en 1 voor lichtintensiteit, en kijk je vervolgens naar de goede kolom. De velden die niet van toepassing zijn, zijn dan uiteraard NULL. Het hele idee van inheritance met tabellen is ook op dit principe gebaseerd en is stukken schaalbaarder.

Hoewel ik het met je eens ben dat de gegeven tabelstructuur niet optimaal is vind ik het alternatief dat je hier biedt ook wel weer aardig zot om eerlijk te zijn. Jij weet niet wat de applicatie aan het meten is, maar het kan gezien de business case volstrekt valide zijn om aan te nemen dat enkel doubles gemeten worden, dat zijn normaal namelijk 'metingen'. Een foto is een waarneming en zou ik zeker niet in dezelfde tabel opslaan als meetwaardes. Daarnaast overtreedt je natuurlijk ieder basisbeginsel van normalisering als je een switch in je tabel inbouwt voor welke van zijn kolommen relevant gaan zijn. De gegeven opzet met 'waardetype' en 'waarde' is in beginsel een hele nette oplossing.

In dat oogpunt is het jammer dat je geen commentaar geeft op iets wat wel absoluut een brute fout is in het design: namelijk dat meetsoort een TEXT is of all things. Text is brak sorteren, indexeren en opslaan, en dus een ramp voor je performance tenzij je hem nodig hebt. Omdat er hier enkel waardes van een paar letters nodig zijn zou een varchar(32) oid al stukken performanter zijn. Zelfs dat is echter al een normalisatiefout, omdat het veld namelijk een discrete set aan waardes kan bevatten. Dit dien je dus best case te doen met een externe tabel 'meettypes' waar je middels een foreign key naar linkt, of desnoods via MySQL's ENUM type als de collectie meettypes een design-time constante is.

3. Waarom gebruik je een timestamp voor het tijdstip? Het klinkt logisch maar dat is het niet. Die timestamp is namelijk van je database server op het moment dat je record toegevoegd of gewijzigd wordt. Ik denk dat je het tijdstip wilt hebben dat de meting plaatsvond, dus moet je een gewoon date/time veld hebben en het betreffende tijdstip meegeven.

Belangrijk deel van wat je hier zegt is onzin, defaults kun je namelijk overriden. Een timestamp met DEFAULT CURRENT_TIMESTAMP is in beginsel de perfecte oplossing hiervoor tenzij je goede reden hebt om tijdsverschillen tussen meetapplicatie en database te elimineren, wat ik me eventueel kan voorstellen als dit een wetenschappelijke applicatie is, en in dat geval moet je vanuit je inderdaad vanuit de applicatie de meettijd meegeven. Gezien het tijdsverschil van 1 minuut tussen meetwaardes lijkt me dat een nutteloze optimalisatie tegenover de 0.0005 seconde query overhead die op dit soort dingen speelt. Het UPDATE-gedrag kun je overriden indien gewenst, maar ik denk dat je je sowieso moet afvragen waar je mee bezig bent als je updates gaat doen in een insert-only tabel van meetwaarden.

[hell4you]

lol mensen, het gaat hier over een opdracht voor school

ik bedoel.. we hebben een opstelling... een lichtsensor, een temperatuursensor en een luchtvochtigheidssensor die we uit moeten kunnen lezen en in de DB moeten kunnen storen (en weer uit moeten kunnen lezen)...

feit is dat die meetwaardes maar eenmalig worden bewaard, nooit ge-edit... (dus timestamp blijft het moment van toevoegen, wat direct na de meting gebeurt)

Ik geef zelf ook toe dat het optimaler kán... maar of dat hier nou nodig is...

[curry684]

Gathering of Tweakers is een discussieforum over computergerelateerde en andere technische onderwerpen, geen helpdesk. Tis dan ook uitermate jammer dat de eerste reply op dit topic stomweg een query terugmept die je kunt copy/pasten zonder dat je er een ruk van leert. Je hebt de moeite genomen om hier een topic te plaatsen, waarna drukke en dure mensen zoals ikzelf een half uur een antwoord hebben getypt in de overtuiging jou iets nuttigs bij te brengen, en dan vind ik "joh da's allemaal niet nodig tis maar een flutopdraggie voor school" niet echt een charmant antwoord.

Waarom stop je het uberhaupt in een database? Je had ook een comma-separated file kunnen pakken, stukken simpeler dan gemekker met SQL en hardstikke performant op tail-insert-only scenario's. Blijkbaar had je een goede reden om een database te nemen om je data in op te slaan, waarom neem je dan niet de hints ter harte die je krijgt? Op z'n allerminst zijn het hele nuttige dingen om mee te nemen voor toekomstige dingen die je in een database gaat stoppen. En daarnaast is het wijzigen van je TEXT-veld in een ENUM-veld ook welzeker 30 seconden werk voor een stevige performance-winst, betere error-checking en een nettere datastructuur die je wellicht nog een leuker cijfer oplevert ook als je dat onderbouwt in je onderzoeksverslag/scriptie/artikel/whatever.

[Twazerty]

Database moeten we gebruiken omdat dat in de opdracht staat. Verder is de reactie van hell4you n beetje zijn stijl (gok ik). Hij heeft dit niet gebruikt als helpdesk kan ik je vertellen. Hij is hier best lang mee bezig geweest. Gezocht en gezocht maar kwam er niet uit. Ik ga nog eens goed bekijken wat hierboven nu gepost is want het is voor mij nog n beetje abra.

[ Voor 51% gewijzigd door Twazerty op 28-03-2008 02:44 ]

[hell4you]

curry684 schreef op vrijdag 28 maart 2008 @ 02:35:
Gathering of Tweakers is een discussieforum over computergerelateerde en andere technische onderwerpen, geen helpdesk.

Dit is mij al lang duidelijk, en zoals Twazerty dit al probeert duidelijk te maken... ik heb hier lang genoeg op gezeten. Het ontbrak mij gewoon aan kennis (ik wist niet meer waar ik op moest zoeken namelijk). Wat blijkt achteraf: er blijkt een hele simpele oplossing voor te zijn. Zou dit dan tot een discussie omgevormd moeten worden zodat ik er zelf achter kom dat je meerdere ORDER BY waardes kan gebruiken in een query??

curry684 schreef op vrijdag 28 maart 2008 @ 02:35:
Tis dan ook uitermate jammer dat de eerste reply op dit topic stomweg een query terugmept die je kunt copy/pasten zonder dat je er een ruk van leert. Je hebt de moeite genomen om hier een topic te plaatsen, waarna drukke en dure mensen zoals ikzelf een half uur een antwoord hebben getypt in de overtuiging jou iets nuttigs bij te brengen, en dan vind ik "joh da's allemaal niet nodig tis maar een flutopdraggie voor school" niet echt een charmant antwoord.

Ik heb hier wel dégelijk iets van geleerd, begrijp me niet verkeerd, maar die SQL query daarboven vergeet ik dus nooit meer. Daarnaast is het zeker niet mijn bedoeling nonchalant over te komen jegens alle posters hier. Integendeel zelfs. Ik waardeer de moeite van elke post, iets waar ik zeker niet mee wil spotten.

curry684 schreef op vrijdag 28 maart 2008 @ 02:35:
Waarom stop je het uberhaupt in een database? Je had ook een comma-separated file kunnen pakken, stukken simpeler dan gemekker met SQL en hardstikke performant op tail-insert-only scenario's. Blijkbaar had je een goede reden om een database te nemen om je data in op te slaan, waarom neem je dan niet de hints ter harte die je krijgt? Op z'n allerminst zijn het hele nuttige dingen om mee te nemen voor toekomstige dingen die je in een database gaat stoppen. En daarnaast is het wijzigen van je TEXT-veld in een ENUM-veld ook welzeker 30 seconden werk voor een stevige performance-winst, betere error-checking en een nettere datastructuur die je wellicht nog een leuker cijfer oplevert ook als je dat onderbouwt in je onderzoeksverslag/scriptie/artikel/whatever.

Dat ik het in een database stop is nou eenmaal de opdracht van school. Alleen de nadruk van de opdracht ligt totaal niet op de database. Het gaat om het uitlezen van de sensoren. De punten zijn dus niet te halen met fancy database structuren en nette response tijden. Ik kan de zaken wel allemaal aan gaan passen, maar dit zou ik dan doen puur en alleen voor de mensen die hierboven hebben gepost. Daarnaast vereist dat ook nog eens extra Java kennis, de programmeertaal die wij hiervoor gebruiken (ik zou niet weten hoe je met SQL ENUM's moet werken in java)

Dit wil allemaal niet zeggen dat ik het niet uit kan gaan zoeken, alleen deze zaken leer ik volgend blok/jaar wel weer.

[curry684]

Nounou hoeft niet meteen zo diep in de verdediging te schieten, alles wat ik wil zeggen is dat het niet netjes is om te zeggen "ach dat hoeft allemaal niet" als er hele nuttige en belangrijke verbeteringen worden gesuggereerd aan wat je voorstelt En dingen die je volgend blok/jaar wel leert kun je ook nu vast oppikken waar mogelijk, heb je volgend blok/jaar meer tijd over voor andere dingen uit te zoeken die dan langskomen.

Enums in Java heb je in principe geen last van: je praat met Java via JDBC tegen MySQL aan, en pompt enkel queries over de lijn. Omdat je in MySQL gewoon strings enumereert zie je dus query-technisch geen verschil ten opzichte van je huidige situatie, je blijft gewoon de string 'licht' inserten en selecten. In MySQL intern echter definieer je het veld als een enum van de waarden 'licht' en 'temperatuur', waardoor je een foutmelding krijgt als je een andere string er (per ongeluk) in zet, en MySQL het intern kan optimaliseren tot integers 0 en 1, wat onnoemelijk veel performanter is dan text-velden (zoals gezegd heel fout om die te gebruiken) of ook varchars.

[Verwijderd]

curry684 schreef op vrijdag 28 maart 2008 @ 01:39:
Hoewel ik het met je eens ben dat de gegeven tabelstructuur niet optimaal is vind ik het alternatief dat je hier biedt ook wel weer aardig zot om eerlijk te zijn. Jij weet niet wat de applicatie aan het meten is, maar het kan gezien de business case volstrekt valide zijn om aan te nemen dat enkel doubles gemeten worden, dat zijn normaal namelijk 'metingen'. Een foto is een waarneming en zou ik zeker niet in dezelfde tabel opslaan als meetwaardes. Daarnaast overtreedt je natuurlijk ieder basisbeginsel van normalisering als je een switch in je tabel inbouwt voor welke van zijn kolommen relevant gaan zijn. De gegeven opzet met 'waardetype' en 'waarde' is in beginsel een hele nette oplossing.

Meetresultaten zijn inderdaad vaak in de vorm van "doubles", maar ik wil maar zeggen dat een double niet heilig is voor meetwaarden. Wat dacht je van een geldbedrag op een bepaald tijdstip. Of een meting die uitgedrukt wordt in twee getallen. Waar het mij om gaat is dat ik van mening ben dat je niet meerdere eenheden in dezelfde kolom op moet slaan.

Heb je nooit van O/R mapping en table inheritance gehoord? In een beetje applicatie heb je een data access layer en voer je buiten je data access layer niet direct queries uit op je database. O/R mapping libraries als Linq-to-SQL en Hibernate ondersteunen table inheritance waarmee je aan de hand van een discriminator (MeetType) kolom classes van elkaar onderscheid. Zo krijg je een abstract class Meting, en derived classes als TemperatuurMeting en LichtMeting. Dit is ook heel eenvoudig om zelf te maken. Dat de meeste velden in een rij NULL zijn maakt niemand wat uit omdat je daar als het goed is nooit direct mee te maken hebt. Voordeel hiervan is dat je oneindig veel meettypen kan toevoegen en voor elke meettype kolommen kan maken die relevant zijn.

curry684 schreef op vrijdag 28 maart 2008 @ 01:39:
Belangrijk deel van wat je hier zegt is onzin, defaults kun je namelijk overriden. Een timestamp met DEFAULT CURRENT_TIMESTAMP is in beginsel de perfecte oplossing hiervoor tenzij je goede reden hebt om tijdsverschillen tussen meetapplicatie en database te elimineren, wat ik me eventueel kan voorstellen als dit een wetenschappelijke applicatie is, en in dat geval moet je vanuit je inderdaad vanuit de applicatie de meettijd meegeven. Gezien het tijdsverschil van 1 minuut tussen meetwaardes lijkt me dat een nutteloze optimalisatie tegenover de 0.0005 seconde query overhead die op dit soort dingen speelt. Het UPDATE-gedrag kun je overriden indien gewenst, maar ik denk dat je je sowieso moet afvragen waar je mee bezig bent als je updates gaat doen in een insert-only tabel van meetwaarden.

Nu ga je er voor het gemak maar even vanuit dat je database lokaal staat, dat die database niets te doen heeft en meetwaarden direct in de database gezet worden. Erg kort door de bocht als je het mij vraagt. Stel dat je de MySQL database op een webserver gebruikt en elk uur een insert doet. Goed, mijn punt is denk ik helder. Timestamp is hier totaal niet voor bedoeld.

[TeeDee]

Als ik even bewust één stuk uit je reactie haal om me even af te vragen of ik goed begrijp wat je hier nu zegt:

Voordeel hiervan is dat je oneindig veel meettypen kan toevoegen en voor elke meettype kolommen kan maken die relevant zijn.

Op deze manier pas je dus je datamodel/database aan als er een nieuw type meting komt?

Als dat inderdaad is wat jij zegt vraag ik me openlijk af wat er door je hoofd gegaan moet zijn toen dit bedacht is.

Wat is er mis met: Meetwaarde | MeetType

Ook [MeetWaarde | MeetType] kan je imo prima in je DAL afregelen om alsnog uiteindelijk tot een class Meting waar een LichtMeting en/of een TemperatuurMeting van erft te komen.

[hell4you]

ja idd, dat heb ik nu ook, althans... de Meting is nu één klasse want LichtMeting en/of een TemperatuurMeting en/of een LuchtvochtigheidsMeting hebben allemaal dezelfde waardes (diegene in de tabel dus)

[ Voor 0% gewijzigd door hell4you op 28-03-2008 13:42 . Reden: nadruk op "één" ]

[Verwijderd]

TeeDee schreef op vrijdag 28 maart 2008 @ 13:36:
Op deze manier pas je dus je datamodel/database aan als er een nieuw type meting komt?

Als dat inderdaad is wat jij zegt vraag ik me openlijk af wat er door je hoofd gegaan moet zijn toen dit bedacht is.

Wat is er mis met: Meetwaarde | MeetType

Ook [MeetWaarde | MeetType] kan je imo prima in je DAL afregelen om alsnog uiteindelijk tot een class Meting waar een LichtMeting en/of een TemperatuurMeting van erft te komen.

Tja... Wat is er mis met: Name | Value. Dat is precies dezelfde loze vraag. Nee, in veel gevallen weinig mis mee, maar soms wil je wat meer. Als je mijn berichten had gelezen dan heb ik het over de mogelijkheid om andere eenheden of eventueel meerdere meetwaarden ook op te kunnen slaan. Ik zie het probleem niet. Als je je applicatie gereed maakt om meerdere soorten meettypen te ondersteunen, waarom zou je de database dan niet willen veranderen?

[curry684]

Verwijderd schreef op vrijdag 28 maart 2008 @ 13:08:
[...]

Meetresultaten zijn inderdaad vaak in de vorm van "doubles", maar ik wil maar zeggen dat een double niet heilig is voor meetwaarden. Wat dacht je van een geldbedrag op een bepaald tijdstip. Of een meting die uitgedrukt wordt in twee getallen. Waar het mij om gaat is dat ik van mening ben dat je niet meerdere eenheden in dezelfde kolom op moet slaan.

En ik ben sterk van mening dat de oplossing erger is dan de kwaal. In jouw ideale wereld heeft een tabel waarin je van 100 locaties de temperatuur meet dus 103 kolommen: 100 keer 'temperatuur<nummertje>', een LocatieId, een MetingId en een MetingTijd. Iedere basisscholert kan je vertellen dat je dan zowat iedere normalisatieregel overtreedt. En realiseer je voordat je nu terug gaat zeggen 'maar nu heb je het overal allemaal temperaturen' dat ik daarop ga antwoorden 'maar waarom is dat anders dan een tabel met allemaal floating point meetwaarden'. Noem de tabel voor mijn part 'FloatMeetwaarde' en je bent weer helemaal zuiver, met 4 kolommen, in NV3.

Heb je nooit van O/R mapping en table inheritance gehoord?

Ja hoor, ik gebruik een eventuele abstractielayer alleen niet als excuus om slechte databases te ontwerpen 'omdat je ze toch niet ziet'. Table inheritance is een concept uit OODBMS'en, en dat kun je wel emuleren bovenop een RDBMS zoals MySQL, maar dan moet je niet direct iedere regel van RDBMS'en het raam uitgooien. Want in the end gaat je data nog steeds in RDBMS'en en moet je het er met relationele queries uithalen.

Nu ga je er voor het gemak maar even vanuit dat je database lokaal staat, dat die database niets te doen heeft en meetwaarden direct in de database gezet worden. Erg kort door de bocht als je het mij vraagt. Stel dat je de MySQL database op een webserver gebruikt en elk uur een insert doet. Goed, mijn punt is denk ik helder. Timestamp is hier totaal niet voor bedoeld.

Nee, je punt is me eigenlijk totaal niet helder? Timestamp is bedoeld om het moment vast te leggen dat iets in de database wordt vastgelegd. Zelfs als je een enorm traag LAN hebt uit 1984 en de databaseserver op een 486 draait is de overhead van connectie, query compilation en execution nog steeds absoluut verwaarloosbaar tegenover de meetinterval van 1 minuut of in jouw geval 1 uur. En dus voldoet timestamp perfect zolang je niet als requirement in je business case hebt staan dat de opgeslagen tijd tot op de milliseconde correct is ten opzichte van de gemeten waarde. In dat geval moet inderdaad zoals ik reeds heb bevestigd de applicatie de timestamp leveren.

[ Voor 4% gewijzigd door curry684 op 28-03-2008 14:53 ]

[TeeDee]

Verwijderd schreef op vrijdag 28 maart 2008 @ 14:39:
[...]
Tja... Wat is er mis met: Name | Value. Dat is precies dezelfde loze vraag.

Name | Value is in essentie hetzelfde ja. En voldoet prima in de scope van deze discussie.

Nee, in veel gevallen weinig mis mee, maar soms wil je wat meer. Als je mijn berichten had gelezen dan heb ik het over de mogelijkheid om andere eenheden of eventueel meerdere meetwaarden ook op te kunnen slaan.

Als je je DB fatsoenlijk wil normaliseren en je wil meerdere types metingen gebruiken ontkom je er imo niet aan om met koppeltabellen aan de slag te gaan. Waar je natuurlijk altijd voor moet waken is een tabel in een tabel.

Ik zie het probleem niet. Als je je applicatie gereed maakt om meerdere soorten meettypen te ondersteunen, waarom zou je de database dan niet willen veranderen?

Dus er komt een nieuw type meting bij. Volgens jouw methodiek ga je dus je tabel opnieuw aanpassen? Een week later: hoppa, nieuwe type meting. En weer je tabel aanpassen? En de mogelijkheid creëren om je applicatie te breken.

Nu zijn er natuurlijk wat kreten te verzinnen als YAGNI, Agile etc. etc.maar iets elementairs als een genormaliseerde DB vind ik niet onder Agile Development vallen.

[Verwijderd]

curry684 schreef op vrijdag 28 maart 2008 @ 14:51:
En ik ben sterk van mening dat de oplossing erger is dan de kwaal. In jouw ideale wereld heeft een tabel waarin je van 100 locaties de temperatuur meet dus 103 kolommen: 100 keer 'temperatuur<nummertje>', een LocatieId, een MetingId en een MetingTijd.

Nee, dan begrijp je me verkeerd. Ik ben van mening dat je niet meerdere eenheden in één kolom moet willen opslaan. Als je dat wel wil, dan vraag ik me sterk af waarom je dan voor een database gekozen hebt.

Op 100 verschillende locaties meten, noem ik 100 verschillende metingen van het type Temperatuur. Dus: 100 rijen met de temperatuurkolom gevuld. Er komt dan inderdaad wel een kolom met locatie bij.

Ik zeg niet dat een float gebruiken voor elk type meting fout is, ik zeg alleen dat ik zelf een nettere oplossing zou kiezen.

curry684 schreef op vrijdag 28 maart 2008 @ 14:51:
Ja hoor, ik gebruik een eventuele abstractielayer alleen niet als excuus om slechte databases te ontwerpen 'omdat je ze toch niet ziet'. Table inheritance is een concept uit OODBMS'en, en dat kun je wel emuleren bovenop een RDBMS zoals MySQL, maar dan moet je niet direct iedere regel van RDBMS'en het raam uitgooien. Want in the end gaat je data nog steeds in RDBMS'en en moet je het er met relationele queries uithalen.

Tja, wat noem je emuleren. Het is een klassiek probleem dat programmeertalen object georienteerd zijn maar databases niet. Om kans op fouten te voorkomen werk ik het liefst met databases in de vorm van objecten met de inheritance, visibility, serialization en relaties zoals je gewend bent met ieder ander object. Wat jij emuleren noemt, noem ik het vertalen van een platte tabel naar een klassenstructuur. Dat MySQL niet native objecten aanlevert, is voor mij geen reden om dan ook maar niet je database uit te drukken in objecten. Maargoed, dat is een kwestie van smaak.

curry684 schreef op vrijdag 28 maart 2008 @ 14:51:
Nee, je punt is me eigenlijk totaal niet helder? Timestamp is bedoeld om het moment vast te leggen dat iets in de database wordt vastgelegd. Zelfs als je een enorm traag LAN hebt uit 1984 en de databaseserver op een 486 draait is de overhead van connectie, query compilation en execution nog steeds absoluut verwaarloosbaar tegenover de meetinterval van 1 minuut of in jouw geval 1 uur. En dus voldoet timestamp perfect zolang je niet als requirement in je business case hebt staan dat de opgeslagen tijd tot op de milliseconde correct is ten opzichte van de gemeten waarde. In dat geval moet inderdaad zoals ik reeds heb bevestigd de applicatie de timestamp leveren.

We hebben het hier over metingen. Of er een milliseconde of een seconde vertraging in de lijn en verwerking zit maakt dan voor mij niet meer uit. Ik zou in dit geval alleen al uit principe de datum van de meting meegeven en dan het daarvoor bedoelde type datetime gebruiken. Sowieso wil je in dit geval niet afhankelijk van de tijd op de server zijn, omdat je de meting lokaal uitvoert.

Waar jij geen rekening mee houdt is dat de database eruit kan liggen. Daarom noemde ik ook als voorbeeld elk uur een insert (waar ik een insert van alle metingen van het afgelopen uur mee bedoelde). Metingen lopen asynchroon met het opslaan in een database. Als de database niet bereikbaar is en een uur later wel, dan moet de tijd van de meting nog steeds kloppen. Daarom: expliciet de tijd van de meting meegeven.

TeeDee schreef op vrijdag 28 maart 2008 @ 15:00:
[...]
Name | Value is in essentie hetzelfde ja. En voldoet prima in de scope van deze discussie.

Mee eens.

TeeDee schreef op vrijdag 28 maart 2008 @ 15:00:
Dus er komt een nieuw type meting bij. Volgens jouw methodiek ga je dus je tabel opnieuw aanpassen? Een week later: hoppa, nieuwe type meting. En weer je tabel aanpassen? En de mogelijkheid creëren om je applicatie te breken.

Als er een nieuw type meting bij komt, dan pas je inderdaad je tabel aan. Dat is ook heel erg logisch. En daar breek je júist je applicatie niet mee.

[ Voor 10% gewijzigd door Verwijderd op 30-03-2008 17:33 ]

[curry684]

Verwijderd schreef op zondag 30 maart 2008 @ 17:30:
[...]

Tja, wat noem je emuleren.

Doen alsof je iets bent zonder het te zijn. Zoals een RDBMS die je middels een emulation wrapper als OODBMS gebruikt.

Dat MySQL niet native objecten aanlevert, is voor mij geen reden om dan ook maar niet je database uit te drukken in objecten. Maargoed, dat is een kwestie van smaak.

Je gaat het punt voorbij. Ik zeg nergens dat je niet middels een emulatielaag een OODBMS van je RDBMS mag maken- zolang er geen fatsoenlijk OODBMS op de markt is heb je niet veel keuze feitelijk. Dat zie ik echter nog steeds niet als excuus om je onderliggende RDBMS kut in te richten, pardon the word.

[...]

We hebben het hier over metingen. Of er een milliseconde of een seconde vertraging in de lijn en verwerking zit maakt dan voor mij niet meer uit. Ik zou in dit geval alleen al uit principe de datum van de meting meegeven en dan het daarvoor bedoelde type datetime gebruiken. Sowieso wil je in dit geval niet afhankelijk van de tijd op de server zijn, omdat je de meting lokaal uitvoert.

We hebben het hier over een schoolapplicatie die 1 meting per minuut uitvoert. Ik heb in dit topic reeds enkele malen de term 'business case' aangehaald, en daarbij het vermoeden geuit dat ik niet denk dat milliseconde-precisie in de opslag van de metingen onderdeel is daarvan.

Waar jij geen rekening mee houdt is dat de database eruit kan liggen. Daarom noemde ik ook als voorbeeld elk uur een insert (waar ik een insert van alle metingen van het afgelopen uur mee bedoelde). Metingen lopen asynchroon met het opslaan in een database. Als de database niet bereikbaar is en een uur later wel, dan moet de tijd van de meting nog steeds kloppen. Daarom: expliciet de tijd van de meting meegeven.

Uhm ja, kerel... ik heb zelfs bij alle multinationals waar ik heb gewerkt nog nooit de requirement meegemaakt dat alle externe transactions buffered moesten worden in cache opdat in geval van database failure de applicatieservers transparant door kunnen werken waarna ze vervolgens zodra ze detecteren dat de database terug aanwezig is alsnog alle transacties kunnen flushen. En weet je waarom? Omdat het onzinnig is.

Stel dat we dit zouden bouwen. Dan zou je dus logischerwijs ook af moeten vangen dat een van de applicatieservers uit je pool uitvalt, want anders komt na het uur downtime van je DB-server ineens maar 75% van de openstaande transacties aan, uitgaande van 4 appservers. Dus moet je op je appservers zorgen dat alle data die ze processen in een transaction log komt te staan, zodat deze onafhankelijk wordt van de master database. Deze transaction log moet vervolgens op een bruikbare manier queryable en replayable zijn, en bovendien moet je voorzien in clustered uitwisseling van data tussen alle applicatieservers omdat ze anders alsnog binnen een minuut nutteloos zijn bij gebrek aan verse data uit de database. Eigenlijk ben je dus in je appservers een distributed database aan het bouwen zodat je die kunt repliceren naar je master DB. Lijkt je een beetje overkill wellicht? Het is ook een volstrekt van de pot gerukt concept, want voor dit soort gevallen cluster je je database en zorg je ervoor dat ie dermate dik in de PSU's, harde schijven en netwerkverbindingen zit dat ie fysiek vrijwel onmogelijk uit kan vallen. Tig keer goedkoper dan zotte software te schrijven die een database voor je database emuleert.

Needless to say lijkt een en ander me ook lichtelijk buiten de scope van de opdracht van de topicstarter.

[Verwijderd]

curry684 schreef op zondag 30 maart 2008 @ 18:35:
Doen alsof je iets bent zonder het te zijn. Zoals een RDBMS die je middels een emulation wrapper als OODBMS gebruikt.

Welkom in de praktijk

curry684 schreef op zondag 30 maart 2008 @ 18:35:
Ik zeg nergens dat je niet middels een emulatielaag een OODBMS van je RDBMS mag maken- zolang er geen fatsoenlijk OODBMS op de markt is heb je niet veel keuze feitelijk. Dat zie ik echter nog steeds niet als excuus om je onderliggende RDBMS kut in te richten, pardon the word.

Tja, define kut, pardon the word. Het hangt nogal van de situatie, ervaring en wensen in de toekomst af hoe je het een en ander in wilt richten. In dit geval zou, zoals ik al aangaf, name/value al prima geweest zijn.

curry684 schreef op zondag 30 maart 2008 @ 18:35:
Uhm ja, kerel... ik heb zelfs bij alle multinationals waar ik heb gewerkt nog nooit de requirement meegemaakt dat alle externe transactions buffered moesten worden in cache.....

Over emuleren gesproken
Ik heb die situatie toevallig wel meegemaakt, ook met metingen. Een van de eerste dingen die we vastlegden in het technisch ontwerp voor de meetmachine was het asynchroon verzenden van meetresultaten naar de server. Waarom? Niet omdat het onzinnig is. Integendeel. Het meten moet altijd doorgaan en mag niet onderbroken worden. Voilà, de queue ofwel cache. Granted, met elke minuut een meting heb je in principe tijd zat om de data in de database te krijgen. Maarja, dat is geen reden om dergelijke onnodige risico's te nemen. Uiteraard is dit afhankelijk van je business case.

curry684 schreef op zondag 30 maart 2008 @ 18:35:
Stel dat we dit zouden bouwen [...] database voor je database emuleert.

Needless to say ga je hier het punt voorbij. Ik denk dat het doel van dit verhaal was om aan te geven hoe overbodig het is om meetresultaten lokaal te cachen, voordat deze naar een externe server gestuurd worden. Je hebt me met je verhaal nog niet overtuigd.

curry684 schreef op zondag 30 maart 2008 @ 18:35:
Needless to say lijkt een en ander me ook lichtelijk buiten de scope van de opdracht van de topicstarter.

Zeker.