DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Database vraagje..
Ik heb een database met simpel gezegd
medewerkers (500+/-)
afdelingen (60 +/-)
melding (stuk of 10 +/-)
een meldingen kan voor 1 of meerdere afdeling gelden en dus ook bekeken worden via verschillende afdelingen.
een buitenstaander kan via elke afdeling een melding zien via een medewerker (een melding is verder niet gekoppeld aan een gebruiker, alleen op het moment van bekijken wordt er een getal opgehoogd bij de medewerker.)
Nu wil ik per dag gaan bijhouden hoe vaak een melding is bekeken door een buitenstaander gekoppeld aan de gebruiker en via welke afdeling (dus dat ik van de afgelopen 7 dagen, en als het haalbaar is van de afgelopen maand hoevaak dat is)
nu komt de grap, zo'n melding kan soms wel 50.000 keer op een dag bekeken worden per gebruiker. Hoe krijg ik dat een beetje normaal in de database?
Ik heb een database met simpel gezegd
medewerkers (500+/-)
afdelingen (60 +/-)
melding (stuk of 10 +/-)
een meldingen kan voor 1 of meerdere afdeling gelden en dus ook bekeken worden via verschillende afdelingen.
een buitenstaander kan via elke afdeling een melding zien via een medewerker (een melding is verder niet gekoppeld aan een gebruiker, alleen op het moment van bekijken wordt er een getal opgehoogd bij de medewerker.)
Nu wil ik per dag gaan bijhouden hoe vaak een melding is bekeken door een buitenstaander gekoppeld aan de gebruiker en via welke afdeling (dus dat ik van de afgelopen 7 dagen, en als het haalbaar is van de afgelopen maand hoevaak dat is)
nu komt de grap, zo'n melding kan soms wel 50.000 keer op een dag bekeken worden per gebruiker. Hoe krijg ik dat een beetje normaal in de database?
500*50.000/dag is niks, kun je mooi een tabel mee vullen. Beetje letten op je datatypes (medewerkerID unsigned smallint/2 bytes, afdelingID unsigned tinyint/1 byte, meldingID unsigned mediumint 2 bytes, dag date 3 bytes), zit je op 200 MB aan data per dag. Plus indices die erbij komen. Kan je prima een maand bijhouden.
Of als je de tijdstippen niet interesseer, tabel aanmaken met medewerker|afdeling|melding|views, UNIQUE op de eerste drie kolommen en dan views ophogen via INSERT ... IF EXISTS UPDATE ofzo.
Of als je de tijdstippen niet interesseer, tabel aanmaken met medewerker|afdeling|melding|views, UNIQUE op de eerste drie kolommen en dan views ophogen via INSERT ... IF EXISTS UPDATE ofzo.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
500*50.000 zou inderdaad kunnen, maar is het niet slimmer om per medewerkers (500+/-) per afdelingen (60 +/-) per melding (stuk of 10 +/-) (=maximaal 300.000 entries per dag) een teller bij te houden?quote:Op vrijdag 31 juli 2009 22:10 schreef GlowMouse het volgende:
500*50.000/dag is niks, kun je mooi een tabel mee vullen. Beetje letten op je datatypes (medewerkerID unsigned smallint/2 bytes, afdelingID unsigned tinyint/1 byte, meldingID unsigned mediumint 2 bytes, dag date 3 bytes), zit je op 200 MB aan data per dag. Plus indices die erbij komen. Kan je prima een maand bijhouden.
of is het opvragen en vervolgens ophogen van deze gegevens zwaarder voor de database?
Dat + datum erbij dus, lijkt me het minst zwaarst voor de databasequote:Op vrijdag 31 juli 2009 22:10 schreef GlowMouse het volgende:
Of als je de tijdstippen niet interesseer, tabel aanmaken met medewerker|afdeling|melding|views, UNIQUE op de eerste drie kolommen en dan views ophogen via INSERT ... IF EXISTS UPDATE ofzo.
Oh, die 500 is per afdeling. Dan medewerker|afdeling|melding|datum|views inderdaad. Views zal wel niet meer passen in 2 bytes, 50.000 zit al dicht bij de limiet. Kom je op 11 bytes/rij.
30.000 rijen per dag, 330 kB/dag, goed te doen om jaren bij te houden. Maar 50.000 updates voor elke 30.000 gebruikers is wel een ouch, dat zou me een grotere zorg zijn
http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html
30.000 rijen per dag, 330 kB/dag, goed te doen om jaren bij te houden. Maar 50.000 updates voor elke 30.000 gebruikers is wel een ouch, dat zou me een grotere zorg zijn
http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
300.000 per dag, maar nog acceptabel inderdaad. Opzich wel jammer dat het tijdstip dan niet opgeslagen wordt.. maar ik vrees dat dat een beetje teveel vreet.quote:Op vrijdag 31 juli 2009 22:25 schreef GlowMouse het volgende:
Oh, die 500 is per afdeling. Dan medewerker|afdeling|melding|datum|views inderdaad. Views zal wel niet meer passen in 2 bytes, 50.000 zit al dicht bij de limiet. Kom je op 11 bytes/rij.
30.000 rijen per dag, 330 kB/dag, goed te doen om jaren bij te houden. Maar 50.000 updates voor elke 30.000 gebruikers is wel een ouch, dat zou me een grotere zorg zijn
http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html
Oke laatste vraag voorlopig hoop ik...
Ik heb nu die tabel:
nu wil ik de gegevens opvragen zodat ik een mooie grafiek kan maken.
Nu wil ik natuurlijk bij een grafiek van een gebruiker opvragen bijvoorbeeld alle views per dag per afdeling opvragen ongeacht de melding
het komt er dus op neer dat alle views per dag per gebruiker per afdeling per dag moet optellen... ik denk dat dit met groupby en sum() moet maar echt ver kom ik niet (op veel foutmeldingen na
) iemand die me een eindje op weg kan helpen?
Ik heb nu die tabel:
| 1 |
nu wil ik de gegevens opvragen zodat ik een mooie grafiek kan maken.
Nu wil ik natuurlijk bij een grafiek van een gebruiker opvragen bijvoorbeeld alle views per dag per afdeling opvragen ongeacht de melding
het komt er dus op neer dat alle views per dag per gebruiker per afdeling per dag moet optellen... ik denk dat dit met groupby en sum() moet maar echt ver kom ik niet (op veel foutmeldingen na
) iemand die me een eindje op weg kan helpen?
| 1 2 3 4 5 | FROM log WHERE medewerker_id = '1' GROUP BY `datum`,`melding_id` ORDER BY melding_id,datum |
Krijg nu trouwens geen foutmelding meer en volgens mij klopt het nog ook
(sta versteld van mezelf 
)enige jammere is dat ik nu nog alle meldingen in 1 array krijg en het niet per melding een aparte array terug krijg..
Dan moet je GROUP BY en ORDER BY in dezelfde volgorde zetten, is sneller icm een index op (melding_id, datum, views) (één multicolumn index in deze volgorde dus).
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Ik ben even bezig met een nieuw login systeem, maar loop tegen een klein probleempje aan en alle artikelen via google lijken uit het jaar nul te komen...
Welke data kan je het beste in een cookie zetten om te verifiëren dat iemand ingelogd moet worden? Passwords sowieso niet maar alleen de username(+random data erachter?) lijkt me ook weer niet veilig of ligt dat aan mij?
Welke data kan je het beste in een cookie zetten om te verifiëren dat iemand ingelogd moet worden? Passwords sowieso niet maar alleen de username(+random data erachter?) lijkt me ook weer niet veilig of ligt dat aan mij?
sessie-id should do it. En sessies in een db bijhouden. Zie bv. wat voor cookies wat je van FOK! krijgt.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Als je PHP's eigen sessiesysteem gebruikt wel ja.quote:Op zaterdag 1 augustus 2009 01:32 schreef gieling het volgende:
had ik naar gekeken maar is het niet zo dat de sessieid bij elk bezoek verandert?
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
maar mijn theorie was dan dat bij een volgend bezoek $_COOKIE["session"]!=$result["session"] of maak ik hier een denkfout?
Ligt er net aan hoe je alles instelt en wat $result is enzo. Op FOK! geldt gelukkig wel een gelijkheid.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
$result zou dan de query zijn waar hij de cookie & sessie-id checkt in de database. Als daar een positief result uit zou komen zou je de sessies moeten zetten neem ik aan.
Oh maar wacht.. het sessid in de database is ook die van de vorige keer, dus zou overeen moeten komen met die in de cookie, toch?
Maar moet je je cookie dan elke keer updaten bij elke sessie?
Oh maar wacht.. het sessid in de database is ook die van de vorige keer, dus zou overeen moeten komen met die in de cookie, toch?
Maar moet je je cookie dan elke keer updaten bij elke sessie?
cookies kun je een lifetime meegeven, dan hoef je hem maar 1x in te stellen.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Haai, ik ben inmiddels een stuk verder met mijn scriptjes, echter stuit ik op een nieuw probleem.
Ik heb een multilevel array aangemaakt
Vervolgens wordt in een loop naar dit multi array weggeschreven, echter is het afhankelijk van de input op welke plaatsen er wordt weggeschreven.
Met mijn huidige code krijg ik deze foutmelding:
Undefined offset
Wat er op neerkomt dat de waarde nog niet geset is. Echter is het voor mij niet handig om bovenstaand array al tot in het oneindige te vullen met de waarde 0. Hoe valt om dit probleem heen te werken?
[edit]
Hmm, na nog veel langer gezocht te hebben het antwoord gevonden: gebruik maken van de isSet functie.
[/edit]
[ Bericht 6% gewijzigd door uppie83 op 01-08-2009 14:44:50 ]
Ik heb een multilevel array aangemaakt
| 1 |
Vervolgens wordt in een loop naar dit multi array weggeschreven, echter is het afhankelijk van de input op welke plaatsen er wordt weggeschreven.
Met mijn huidige code krijg ik deze foutmelding:
Undefined offset
Wat er op neerkomt dat de waarde nog niet geset is. Echter is het voor mij niet handig om bovenstaand array al tot in het oneindige te vullen met de waarde 0. Hoe valt om dit probleem heen te werken?
[edit]
Hmm, na nog veel langer gezocht te hebben het antwoord gevonden: gebruik maken van de isSet functie.
[/edit]
[ Bericht 6% gewijzigd door uppie83 op 01-08-2009 14:44:50 ]
ウプピエ 八十三 << u-pu-pi-e hachi-ju-san, ik denk ik zeg het er maar ff bij :P
Als je die waarden alleen gebruikt voor marketing informatie: Niet. Gewoon je statistieken programma voor gebruiken.quote:Op vrijdag 31 juli 2009 22:02 schreef BaggerUser het volgende:
Database vraagje..
Ik heb een database met simpel gezegd
medewerkers (500+/-)
afdelingen (60 +/-)
melding (stuk of 10 +/-)
een meldingen kan voor 1 of meerdere afdeling gelden en dus ook bekeken worden via verschillende afdelingen.
een buitenstaander kan via elke afdeling een melding zien via een medewerker (een melding is verder niet gekoppeld aan een gebruiker, alleen op het moment van bekijken wordt er een getal opgehoogd bij de medewerker.)
Nu wil ik per dag gaan bijhouden hoe vaak een melding is bekeken door een buitenstaander gekoppeld aan de gebruiker en via welke afdeling (dus dat ik van de afgelopen 7 dagen, en als het haalbaar is van de afgelopen maand hoevaak dat is)
nu komt de grap, zo'n melding kan soms wel 50.000 keer op een dag bekeken worden per gebruiker. Hoe krijg ik dat een beetje normaal in de database?
Hmm om een of andere vage reden werkt mijn 'strcasecmp' niet :?
Dit geeft de volgende output:
Kortom hallo en hallo zijn niet hetzelfde |:(
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | function compare($string, $filename){ $stringArray = explode(" ",$string); // Array with loose words of the string $fileArray = file($filename); printArray($stringArray); printArray($fileArray); for($index=0;$index<sizeof($stringArray);$index++){ for($counter=0;$counter<sizeof($fileArray);$counter++){ echo "index: $index en counter: $counter <br>"; echo "$stringArray[$index] => $fileArray[$counter] <br>"; $compare = strcasecmp($stringArray[$index],$fileArray[$counter]); echo "$compare <br>"; if(strcasecmp($stringArray[$index],$fileArray[$counter])==0){ echo "match!!! <br>"; } } } } compare('hallo dit is een test', 'F:\\XXX\\UsbWebserver\\Root\\YYY\\ZZZ\\woorden.txt'); ?> |
Dit geeft de volgende output:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 | 1 => dit 2 => is 3 => een 4 => test 0 => hallo 1 => test index: 0 en counter: 0 hallo => hallo -2 index: 0 en counter: 1 hallo => test -12 index: 1 en counter: 0 dit => hallo -4 index: 1 en counter: 1 dit => test -16 index: 2 en counter: 0 is => hallo 1 index: 2 en counter: 1 is => test -11 index: 3 en counter: 0 een => hallo -3 index: 3 en counter: 1 een => test -15 index: 4 en counter: 0 test => hallo 12 index: 4 en counter: 1 test => test 0 match!!! |
Kortom hallo en hallo zijn niet hetzelfde |:(
ウプピエ 八十三 << u-pu-pi-e hachi-ju-san, ik denk ik zeg het er maar ff bij :P
Bedankt, dat werkt idd.quote:Op zaterdag 1 augustus 2009 23:15 schreef Roönaän het volgende:
Dit komt omdat file() de newlines bewaard. Je zou een array_map met trim kunnen proberen.
[edit]
Inmiddels heeft zich het volgende probleem aangediend. Ik probeer een multilevel array te sorteren op key value, waarbij key - value behouden blijft. Hiervoor heb ik deze functie:
| 1 2 3 4 5 6 7 8 | function sortArray(&$array){ ksort($array); foreach(array_keys($array) as $i){ sortArray($array[$i]); } } ?> |
En uiteindelijk doet dit de truc wel. Ik krijg er echter een shitload aan foutmeldingen bij.
[ Bericht 69% gewijzigd door uppie83 op 02-08-2009 01:22:31 ]
ウプピエ 八十三 << u-pu-pi-e hachi-ju-san, ik denk ik zeg het er maar ff bij :P
Helaas, m'n glazen bol is stuk.quote:
En uiteindelijk doet dit de truc wel. Ik krijg er echter een shitload aan foutmeldingen bij.
