A külön adatbázis mellett szerintem az szól, hogy az userek nem tudnak egymás levelezési és spam megjelölési szokásaiba belerondítani és talán az adatbázis is kisebb.
hat kisebb nem tudom, hogyan lesz, ha egy kozos tokent 1000x tarolsz el :-)
A kozos / kulon tokendb dilemma kapcsan azt kell megnezni, mennyire hasonlo a userek izlese spam tekinteteben, azaz mennyire valoszinu, hogy ugyanazt a levelet mindenki hamnek vagy spamnek gondolja majd? Ha sanszos (pl. 1 cegrol van szo), akkor mehet a shared db, mert az gyorsabban konvergal (viszont valoban a kozepebe rondithat egy stupid vagy rosszindulatu user, ha elkezd pl. viagras leveleket ham-kent tanitani).
Ha fele usered kinai, fele kubai, fele magyar es fele norveg, akkor inkabb sajat db mindenkinek. Ill. a legszebb az lenne (ezt most nem tudom, hogy tamogatja-e az SA), ha csoportokat lehetne kepezni, azaz a kinaiak egy csoportba, stb. Es akkor egy gyakori tokent nem kene 1000x tarolnod, hanem csak 4x.
(Mondjuk egy jobbfele statisztikai szuro, amelyik foallasban dolgozik tokenekkel az olyat is tud, hogy csinalsz egy kozos token halmazt olyan levelekbol, amelyeket mindenki hamnek vagy spamnek tekint [uid=0], majd megengeded, hogy a userek tanitsak a token adatbazist ugy, hogy ezek az extra tokenek csak a sajat leveleinek kiertekelesekor kapnak szerepet)
De ha azt is beleszamolod, hogy a Bayes db mennyire hangsulyos egy alapvetoen szabalyalapu spamszuronel, akkor lehet eleg indulaskent egy shared token halmaz is...
Továbbá mi történik, ha a közös adatbázis nagyra felhízik? Nem lassítja a kiértékelést? Nem lehet kiűríteni a régi mintákat?
ha berkeley db-ben tarolod a tokeneket, akkor igen. Egy hataron (mereten) tul azt mondjak (akik mar lattak ilyet), hogy valoban lassabb egy nagy meretu db file-lal dolgozni. Bar az SA amugy is doglassu, szoval ki tudja, mennyit oszt vagy szoroz ez a plusz terheles... Ha tudod, tedd a token halmazt is mysql-be (ne myisam, hanem innodb vagy xtradb legyen inkabb), az jol szol, ha jol megtekered a mysql valtozokat...