[JS+MySQL] Postpone database update

[Karasu]

Ik heb een redelijk eenvoudig probleem, maar ik kan maar niet inzien hoe ik het best uitwerk.

Ik heb een pagina met knoppen die je kan aan/uit zetten. De initiële staat van de knoppen wordt uit de database ingeladen (via int -> base2, leek me efficiëntst) en in een javascript array opgeslagen.

De gebruiker kan op de knoppen klikken, waardoor een script ze gaat aan/uit zetten in de array én een url aanpast van een iFrame zodat de database bij elke verandering wordt geüpdate. (Hierdoor moet de gebruiker bij het sluiten van de pagina

code:

toggle(id) {
  update js array en wissel knop;
  mysql_query(update db met nieuwe hash van alle waarden); }

Aangezien een gebruiker al heel snel op de knoppen kan klikken, kan het zijn dat de database heel vaak moet ge-update worden.

Mijn oplossingen:
- Schrijf pas na enkele seconden als er aanpassingen zijn gebeurd
- Schrijf pas weg als de gebruiker de pagina verlaat (onunload event)

Probleem bij het tweede is dat bij refreshen de popup niet snel genoeg de database kan updaten en de oude data wordt ingeladen! Iemand een idee?

[ufear]

Wat denk je van gewoon een "SAVE" knop zodat gebruikers ook een idee hebben wanneer hun veranderingen worden doorgevoerd?

Of inderdaad een timeout van X seconden instellen, zodra die passeert even de UI blokkeren, update doorvoeren en dan de huidige staat opnieuw inladen (of niet..). Maar dan nog zou ik als gebruiker nog graag een knop zien om de wijzigingen te bevestigen.

[Verwijderd]

Nog een oplossing zou zijn om de state op te slaan in een sessie var en die dan, 'save' knop te klikken, alles in een keer door te voeren in de DB

Lijkt me ook niet altijd gewenst namelijk om wijzigingen meteen door te voeren in de database

[ Voor 24% gewijzigd door Verwijderd op 22-12-2010 09:42 ]

[Karasu]

Tja, zo zal het dan moeten worden. Ik ga wat feedback vragen aan de testers. Als er toch nog ideeën komen zijn ze zeer welkom.

@Ufear: opslaan gaat zo snel dat het wel gebeurt is tussen twee veranderingen. UI blokkeren en opnieuw inladen is hier overbodig. Om sneller te werken gaan alle states lokaal in JS worden bijgehouden.
@Thioz: Hier is dat geen probleem. Als er een foute knop wordt ingedrukt kan die meteen nog eens klikken om te corrigeren. Het heeft geen negatief gevolg, behalve meer requests naar de DB.

[storeman]

Je zou ook nog kunnen overwegen data op te slaan in de LocalStorage van de browser (nieuwe browsers ondersteunen dit, een fail-over zou je met een Cookie kunnen realiseren).

Ik heb geen idee of dit van toepassing is op jou probleem, maar ik moest er even aan denken toen ik je topic las.

[Janoz]

Ik vermoed dat je je oplossing in de verkeerde richting aan het zoeken bent. Die update comando's zelf zijn het probleem niet. Daar moet je server makkelijk tegen kunnen. Je aanpak zorgt ervoor dat er race problemen op kunnen treden. IMHO kun je dus beter je aanpak wijzigen. Je huidige aanpak heeft twee problemen.
1: Het wijzigen van 1 van je vinkjes update de waarden val alle vinkjes
2: Er wordt getoggled waardoor 2x uitzetten resulteert in het weer aanzetten van het vinkje

Ikzelf heb in een applicatie een zeflde soort functionaliteit. Ten eerste is bij mij een update van de waarde van 1 vinkje een atomaire actie die geen invloed heeft op de overige vinkjes. Ten tweede stuur ik ook de nieuwe waarde van het vinkje mee waardoor de wijziging die op het scherm plaatsvindt ook daadwerkelijk de wijziging is die je naar de server stuurt.

Wanneer je die twee aanpassingen doet heb je een robuuster systeem waardoor je niet aan de slag hoeft met ingewikkelde (en dus foutgevoelige) delayed acties en afhankelijk bent van events die misschien wel helemaal niet afgaan.

[Karasu]

@Janoz Ik had geen zin om in mijn database honderden kolommen te gebruiken voor 1/0. Nu heb ik de DB kunnen kleiner maken door enkele honderd tesamen te steken in bits (2^index). Bij het updaten kan ik niet anders dan de volledige waarde te herschrijven. Ik dacht toch dat die manier van opslaan voordeel heeft.
Onderandere omdat ik de kans geef tot 15 vinkjes tegelijk te toggelen.

Heb jij het dan ook met een iFrame gedaan? Dat leek me de beste manier. Maar dan denk ik dat je frame wat vertraging heeft moest je snel enkele vinkjes veranderen. Al je update commando's moeten ook volledig doorgevoerd zijn eer je verder kan gaan.

Voor geïnteresseerden ziet mijn pagina er nu zo uit: http://img839.imageshack.us/img839/6366/prevq.png

[NMe]

Karasu schreef op woensdag 22 december 2010 @ 16:46:
@Janoz Ik had geen zin om in mijn database honderden kolommen te gebruiken voor 1/0. Nu heb ik de DB kunnen kleiner maken door enkele honderd tesamen te steken in bits (2^index). Bij het updaten kan ik niet anders dan de volledige waarde te herschrijven.

Je hoeft niet de hele waarde te overschrijven? Je kan toch gewoon een bitwise AND doen op de waarde van je vinkje dat je naar links shift tot op de positie waar je hem hebben wil? Met andere woorden: $waarde = $waarde | ($checkboxwaarde << 5) voor het zesde bit? Dollartekens even om aan te geven dat ik variabele waarden bedoel.

Ik dacht toch dat die manier van opslaan voordeel heeft.
Onderandere omdat ik de kans geef tot 15 vinkjes tegelijk te toggelen.

Wat doe je als je meer dan 64 bits wil togglen, oftewel: als je meer dan 64 vinkjes nodig hebt? Naast 100 kolommen is de volgende optie om gewoon een aparte tabel ervoor te maken.

[ Voor 4% gewijzigd door NMe op 22-12-2010 16:58 ]

[Precision]

jQuery en ajax? Ik zou eerst de status in een sessie opslaan (in een array/(dto) object). Via een GET form stuur je alles door naar de pagina die dan vergelijk wat er anders is. En elke 5 sec doorsturen naar de databank.
EDIT: Heb de ts nog eens gelezen, je gaat met m'n oplossing niets kunnen aanvangen, maar ik laat het staan je weet nooit je er een ingeving mee krijgt.

[ Voor 26% gewijzigd door Precision op 22-12-2010 17:09 ]

[Janoz]

Karasu schreef op woensdag 22 december 2010 @ 16:46:
@Janoz Ik had geen zin om in mijn database honderden kolommen te gebruiken voor 1/0. Nu heb ik de DB kunnen kleiner maken door enkele honderd tesamen te steken in bits (2^index).

In mijn geval ging het om een lijst, daar hoorden de vinkjes niet bij 1 record.

Bij het updaten kan ik niet anders dan de volledige waarde te herschrijven.

Niet waar. Zie de reactie van NMe. Mysql ondersteund dit gewoon waardoor je een UPDATE query kunt maken die een enkele bit aanpast, onafhankelijk van de waarde van de andere bits.

Ik dacht toch dat die manier van opslaan voordeel heeft.

Dat ligt aan de gestelde eisen. Performance technisch gezien zou het misschien beter kunnen zijn, maar het maakt het werken met de aparte velden wel weer een stuk lastiger.

Onderandere omdat ik de kans geef tot 15 vinkjes tegelijk te toggelen.

Maar er is ook een kans dat er maar 1 veranderd, of 4.

Heb jij het dan ook met een iFrame gedaan? Dat leek me de beste manier. Maar dan denk ik dat je frame wat vertraging heeft moest je snel enkele vinkjes veranderen. Al je update commando's moeten ook volledig doorgevoerd zijn eer je verder kan gaan.

Ik heb het met een simpel ajax dingetje gedaan. Omdat mijn updates onafhankelijk van elkaar zijn maakt het niet uit in welke volgorde ze uitgevoerd worden* en de database zorgt er voor dat de aanpassingen aan de database iig niet gelijktijdig uitgevoerd worden. In mijn geval maakte het dus ook niet uit of het doorvoeren binnen een een miliseconde ging, of dat het 3 seconden duurde. Daar had de gebruiker helemaal geen last van.


* wanneer updates op hetzelfde veld in de verkeerde volgorde aankomen dan gaat het natuurlijk wel mis, maar zolang de laatst binnengekomen ook de laatst verstuurde is komt dat allemaal weer goed.

[NMe]

Janoz schreef op woensdag 22 december 2010 @ 19:25:
[...]

Niet waar. Zie de reactie van NMe.

Mja, alleen zie ik net dat ik het verkeerd opschreef. Ik noemde een AND maar gebruikte een OR en beiden zijn niet afdoende voor het wijzigen van een bit ongeacht de oude en nieuwe waarde. Volgens mij kan je dan het beste eerst ANDen met het negatieve bitmask van een 1 die je even ver naar links shift als de checkboxwaarde en dan ORen met de naar links geshifte stand van de checkbox.

De reden dat een enkele AND of OR niet genoeg is, is natuurlijk dat je met een AND een negatieve bit niet postief kan maken en met een OR een positief bit niet negatief terwijl XOR alleen kan togglen.

[Janoz]

Met een AND kun je een bit gegarandeerd op false zetten en met OR kun je een bit gegarandeerd op true zetten

Bij OR gebruik je gewoon het door jou aangehaalde bitmaask. Bij AND gebruik je het inverse daarvan.

[NMe]

Janoz schreef op woensdag 22 december 2010 @ 21:10:
Met een AND kun je een bit gegarandeerd op false zetten en met OR kun je een bit gegarandeerd op true zetten

Bij OR gebruik je gewoon het door jou aangehaalde bitmaask. Bij AND gebruik je het inverse daarvan.

Ah ja, dat kan ook natuurlijk, simpele check of het 1 of 0 moet worden en op basis daarvan je operator kiezen. Wat ik bedoelde was dit: als je het 5e bit wil instellen op een waarde zonder te checken wat de oude of de nieuwe waarde is, dan kun je dit doen:

10111010          <-- oude waarde
11101111 &        <-- bitmask met alles op 1 behalve de bit die je wil instellen
--------
10101010
00010000 |        <-- bitmask met alles op 0 en eventueel de bit die je wil instellen op 1
--------
10111010          <-- nieuwe waarde/uitkomst

Maar die simpele if is waarschijnlijk handiger ja.

[RobIII]

Of we laten heel die bitlogic voor wat 't is want normaliseren zou hier key moeten zijn. Het is misschien wat compacter in opslagruimte maar daar heb je zo'n beetje alles mee gehad. Het queryen en updaten wordt er niet simpeler op, de code eromheen wordt er niet leesbaarder en onderhoudbaarder op en voor een koppeltabelletje hoef je 't niet te laten; een RDBMS wordt daar echt niet warm of koud van. En dan heb je nog de beperking dat je max. x bits aan opties aan of uit kunt zetten tenzij je weer bitfields gaat verdelen over meerdere kolommen; dit is een smeulende puinhoop waiting to happen. Ik zie geen enkele reden om alles in een "bitfield" te (willen) proppen.
En 't verbaast me dat niemand dat nog gezegd heeft

[ Voor 4% gewijzigd door RobIII op 22-12-2010 22:06 ]

[Janoz]

NMe schreef op woensdag 22 december 2010 @ 22:01:
Ah ja, dat kan ook natuurlijk, simpele check of het 1 of 0 moet worden en op basis daarvan je operator kiezen.

Geen check. Zoals ik al eerder aangaf moet je geen toggle actie naar de server sturen, maar de nieuw gewenste waarde.


Verder helemaal eens met Rob.

[NMe]

RobIII schreef op woensdag 22 december 2010 @ 22:03:
En 't verbaast me dat niemand dat nog gezegd heeft

* NMe wijst naar NMe in "\[JS+MySQL] Postpone database update"

[RobIII]

NMe schreef op woensdag 22 december 2010 @ 22:58:
[...]

* NMe wijst naar NMe in "\[JS+MySQL] Postpone database update"

offtopic:
Moet je 't voortaan maar wat minder onopvallend neerzetten

[Karasu]

@NMe Een UPDATE request naar de database is van dezelfde grootteorde. Een waarde schrijven is zelfs lichtjes efficiënter dan een waarde aanpassen denk ik.

Maar ja, momenteel kan ik wel tot 64 booleans bijhouden in 1 kolom. Voor alles > 32 gebruik ik nu bc* in php. Ik kan gerust twee kolommen gebruiken met wat extra lijntjes code. Of denk je dat ik beter een tabel gebruik met ~350 boolean kolommen? (ik kan gerust in 4 types onderverdelen, die elk anders in 2*64 passen)

EDIT: oeps, had nog niet volledig gerefreshed. Ffe nieuwe posts lezen
EDIT2: Goed, ik ga eens zien hoe ik met die kolommen ga werken. Wat voor methode gebruikte eigenlijk om de database aan te roepen met ajax? Dat zou m'n oorspronkelijk probleem misschien al wat kunnen helpen.

[ Voor 23% gewijzigd door Karasu op 23-12-2010 03:43 ]

[Janoz]

Ajax is helemaal niet ingewikkeld. Sterker nog, ik denk dat het simpeler is dan je huidige iframe oplossing. Zeker omdat de huidige actie enkel een actie is waarbij je iets naar de server moet sturen en helemaal niks met het antwoord hoeft te doen.

[RobIII]

Karasu schreef op donderdag 23 december 2010 @ 03:34:
Maar ja, momenteel kan ik wel tot 64 booleans bijhouden in 1 kolom. Voor alles > 32 gebruik ik nu bc* in php. Ik kan gerust twee kolommen gebruiken met wat extra lijntjes code.

Daar begint 't al... stap hier van af.

Karasu schreef op donderdag 23 december 2010 @ 03:34:
EDIT2: Goed, ik ga eens zien hoe ik met die kolommen ga werken.

Je wil geen kolommen, je wil rijen Lees je in in normaliseren en gebruik een koppeltabel.

[ Voor 44% gewijzigd door RobIII op 23-12-2010 09:39 ]

[Karasu]

Rijen? Bedoel je dan een tabel [ UserID | BooleanID ] ? Als een element aanwezig is is het een '1' en anders niet.

Met kolommen bedoelde ik [ UserID | Boolean1 | Boolean2 | Boolean3 | .. ]. Een koppeltabel is niet nodig in beidde gevallen.

[RobIII]

Karasu schreef op donderdag 23 december 2010 @ 14:21:
Rijen? Bedoel je dan een tabel [ UserID | BooleanID ] ?

Jep; dat is nou een koppeltabel

Karasu schreef op donderdag 23 december 2010 @ 14:21:
Als een element aanwezig is is het een '1' en anders niet.

Dat is een optie. Een andere optie is [UserID | Key | Value] (of, in jouw termen, [UserID | BooleanID | Waarde]). Waarbij je van de eerste 2 velden weer mooi een compound key kunt maken.

Karasu schreef op donderdag 23 december 2010 @ 14:21:
Met kolommen bedoelde ik [ UserID | Boolean1 | Boolean2 | Boolean3 | .. ].

En dat is handig als je nog eens een waarde erbij wil...

Karasu schreef op donderdag 23 december 2010 @ 14:21:
Een koppeltabel is niet nodig in beidde gevallen.

Nogmaals: lees eens iets over normaliseren

[ Voor 3% gewijzigd door RobIII op 23-12-2010 14:37 ]

[Karasu]

RobIII schreef op donderdag 23 december 2010 @ 14:29:
Dat is een optie. Een andere optie is [UserID | Key | Value] (of, in jouw termen, [UserID | BooleanID | Waarde]). Waarbij je van de eerste 2 velden weer mooi een compound key kunt maken.

Zou je echt voor een boolean een kolom Value erbij halen? Je tabel heeft dan sowiso N * 350 * 3 elementen. Anders is het meer N * 350 / 2. Héél groot verschil in ruimte.

RobIII schreef op donderdag 23 december 2010 @ 14:29:
En dat is handig als je nog eens een waarde erbij wil...

Ik heb ~350 booleans, ja dus.

RobIII schreef op donderdag 23 december 2010 @ 14:29:
Nogmaals: lees eens iets over normaliseren

Ik heb een vak databases gevolgd aan d'unief.

[RobIII]

Karasu schreef op donderdag 23 december 2010 @ 14:52:
Zou je echt voor een boolean een kolom Value erbij halen? Je tabel heeft dan sowiso N * 350 * 3 elementen. Anders is het meer N * 350 / 2. Héél groot verschil in ruimte.

Als je je daar al zorgen om maakt... Een RDBMS draait z'n hand echt niet om voor een paar miljoen records en de ruimte voor zo'n tabel is ook verwaarloosbaar...

Karasu schreef op donderdag 23 december 2010 @ 14:52:
Ik heb ~350 booleans, ja dus.

De kolommen nemen dan per definitie al ruimte in. Je haalt je eigen argument nu onderuit En waar ik op doelde: als je nu nog 10 waardes erbij wil moet je je database (en software) gaan aanpassen wat geheel onnodig is als je gewoon een koppeltabel gebruikt.

Karasu schreef op donderdag 23 december 2010 @ 14:52:
Ik heb een vak databases gevolgd aan d'unief.

Dus? Wat is de relevantie hier precies? Ik heb hierop eigenlijk een keuze uit 2 mogelijke responses:
a) Dan weet je wat normaliseren is en vraag ik me af waarom je 't niet doet
b) Dan heb je zitten slapen of ze hebben 't niet goed uitgelegd.

You pick one

[ Voor 48% gewijzigd door RobIII op 23-12-2010 15:03 ]

[NMe]

Zeker als je inderdaad 350 waardes wil opslaan is een koppeltabel je enige fatsoenlijke oplossing.

[ReenL]

Rows gebruiken!

Ik heb een vak databases gevolgd aan d'unief.

Dan weet je dus ook dat je huidige oplossing wel werkt maar niet theoretisch het best is, omdat je het maximaal aantal booleans alleen kunt aanpassen door een ALTER TABLE.

Om je een idee te geven. MySQL maakt eerst de nieuwe tabel, en gaat daarna rij voor rij die de oude data in de nieuwe tabel proppen, pas als alles klaar is verwijder mysql de oude tabel. De performance van je applicatie tijdens die update daalt dus naar 0 omdat dit schijf en lees acties zijn van je slome harde schijf. Daarnaast heb je 2x de schijfruimte nodig om een tabel te kopieren (hoewel dat tegenwoordig niet zo'n probleem meer is). En de table is gedurende die tijd gelockt.

Ook wordt je performance er niet beter op omdat je geen index aan kunt maken op je kolomwaardes. Mocht je de mensen zoeken die checkbox "X" aangevinkt hebben.
[/docentmodus]

De reden dat je alles in kolom wilde proppen is dat je met 1 actie meerdere booleans op false zet, je kunt dit oplossen door 2 typen ajax request. Een om een enkele value te veranderen en een om de "master" checkbox te veranderen.

Php (of andere serverside taal) kijkt vervolgens naar het type request, als het een "master" checkbox is, dan vertaalt hij dat naar de individuele checkboxen.

Anders is het meer N * 350 / 2. Héél groot verschil in ruimte.

Schijfruimte is goedkoop tegenwoordig. Refactoren / lange tijd offline zijn niet.