[wouso-dev] în legatură cu Static Login...

[Alex Eftimie]

2009/11/30 Niflostancu <niflostancu at gmail.com>:
> Salutări,
> Am vrut să mă apuc de task-ul [0] şi am dat peste problema că IDurile
> utiliatorilor corespund cu cele de pe LDAP.
> Aici pot gândi două soluţii (sunt foarte tehnic, sper să se înţeleagă
> ceva :D ):
>
> 1) Atribui un ID nefolosit utilizatorului "static", dupa cum scrie pe wiki [1].
> Dezavantaje: În cazul în care IDurile utilizatorilor din LDAP vor urca
> foarte mult şi vor intra peste cele atribuite static, va ieşi urât...
> şi IDul trebuie generat manual in fişierul static...
>
> 2) Detaşăm IDul din tabela cu utilizatori de IDurile din LDAP (nu vor
> mai fi aceleaşi)...
> O să facem interogare după numele de utilizator, care ar trebui să fie
> unic... o să fie un pic mai lentă (dacă nu sunt indecşii creaţi), dar
> se va face doar în timpul login-ului...
> La primul login, generăm IDul prin auto_increment şi creăm intrare în tabel...
> Utilizatorii actuali au IDul deja generat, identic cu cel din LDAP,
> dar nu mai contează... auto_increment-ul ar trebui să continue de la
> ultimul.
> Aşa o să amestecăm utilizatorii "reali" cu cei "statici", nu ştiu daca
> să trec la dezavantaje lucrul ăsta... se poate vedea simplu dacă este
> utilizator din LDAP sau static, când o fi nevoie.
> Nu văd nimic greşit în această metodă, de aceea vă cer părerea daca
> pot să procedez aşa.

Analiza ta este bună, dar pierde din vedere câteva aspecte:

- în condiții normale, id-urile din LDAP nu evoluează; câți studenți
există la începutul anului... cam aceiași rămân tot semestrul; nu
există posibilitatea să se mai înscrie, let say, încă 10.000;
- numărul de conturi statice este undeva în jurul a 10, maxim 20 -
aceste conturi nu "supraviețuiesc" unui nou semestru;
- deși pare o soluție ieftină, folosirea de id-uri externe (cele din
LDAP) are avanteje; de exemplu: atunci când am dorit spargerea tabelei
utilizatori în două tabele disjuncte, "users" și "users_senior",
faptul că id-urile unice "veneau" de afară, a făcut lucrurile banale
(folosind id-uri generate de noi și auto_increment ar fi rezultat în
conflicte de id-uri, rezolvabile prin duplicarea altor tabele de
asemenea - sper că se înțelege ce vreau să spun); exemplul doi: într-o
viitoare "mai bună" integrare cu site-ul cs.curs.pub.ro, vom putea
pune legături către profilul utilizatorilor din WoUSO, doar
cunoscându-le id-ul;
- chiar dacă singurul rău pe care îl văd în generarea de id-uri propri
este faptul că nu știu clar cum va evolua asta în timp (complexitatea
adăugată este doar la login, căutare după nume în loc de id,
insignifiantă de altfel), având în vedere că numerele sunt cele de la
liniuțele de mai sus, sugerez alegerea soluției simple, bazată în
continuare pe id-uri externe și statice.

As a side note, select max(id_user) este 13626. Dacă
min_static=50.000, what could go wrong?

Notă: singura mea experiență cu baze de date, în afară de cea de la
curs, a fost în cadrul unui stagiu de practică; s-ar putea să mă înșel
în analiza de mai sus.

Notă doi: când nu știu ce tehnică să abordez, KISS (keep it simple)
funcționează întotdeauna.

Spor!

-- 
Alex Eftimie