Dotaz: Unikátní username v doméně a napříč doménami

Mám aplikaci, do které se uživatel musí přihlásit a chci mít unikátní uživatelská jména - udělám unikátní klíč nad sloupcem username a jsem spokojený.

Přijde požadavek, že se uživatelé budou řadit do domén a v rámci domény budou unikátní - rozšířím unikátní klíč na id domény a jsem spokojený.

Přijde požadavek na sdílení jmenného prostoru domén s id 1 a 2 (username v doméně 1 se nesmí vyskytnout v doméně 2 a naopak). Zatnu zuby a vytváření nového uživatele vyřeším následujícím kódem a doufám, že bude INSERT dostatečně atomický (nejsem v transakci).

INSERT user (domain_id, username, password) SELECT 1, 'kdosi', 'bla bla' FROM user WHERE domain_id IN (1, 2) AND username = 'kdosi' HAVING COUNT(*) < 1; SELECT user_id FROM user WHERE username = 'kdosi' AND domain_id = 1 AND password = 'bla bla';

Jenže username je možno editovat - existuje podobná finta i na update? Nějaké jiné řešení?

Děkuji za každou radu či odkaz.

Odpovědi

[Josef Kufner]

Ta finta se jmenuje transakce. Začneš transakci, v klidu si selectem zkontroluješ, co potřebuješ, uděláš update a commitneš transakci. Pokud by kontroly selhaly, uděláš rollback. K tomu můžeš ještě přidat zámky (SELECT ... FOR UPDATE).

[Ja]

Transakce by mi to spíš pokazila - zahájím transakci, zkontroluju co potřebuju, updatnu... a protože to je v transakci, tak nevidím jiný update, který proběhl během mé transakce a protože to nehlídá žádný klíč, tak to projde a commitne. Jestli jde v MySql upravit izolovanost transakce natolik, abych viděl i nové updaty vně transakce nevím.

[Jendа]

Hm a nejde to locknout?

[Sten]

SELECT FOR UPDATE a jiná transakce při snaze změnit stejné řádky musí počkat

[Josef Kufner]

Myslím, že bude muset zamknout celou tabulku, neboť jinak by mu tam mohl někdo vložit duplicitního uživatele.

[Lyco]

Uh, cože? InnoDb má samozřejmě gap locking, když udělám SELECT * FROM users WHERE id = 123 FOR UPDATE; tak i když uživatel s id = 123 neexistuje, tak dokud necommitnu, nemůže ho nikdo vložit.

Zamykat celou tabulku je nesmysl, to je hrozný zabiják výkonu.

[Filip Jirsák]

Unikátní klíč nad hodnotou, která bude rovna username pro domény 1 a 2 a NULL pro ostatní. Může to být funkční index, může to být index nad počítaným sloupcem - záleží, co umí vaše databáze.

[Ja]

Omlouvám se, zásadní chyba - nenapsal jsem, že jde o MySql.

Taky mne napadlo, že bych mohl zavést nějaký domaingroup_id a udělat unikátní klíč nad username a domaingroup_id, jen jsem doufal v nějaké snazší řešení bez zásahu do databázového modelu, ale čím víc o tom přemýšlím, tím víc mi to připadá jako nejlepší řešení. Děkuji, že jste mi to potvrdil.

[pavlix]

Nebylo by lepší se té MySQL prostě zbavit?

[Ja]

To by asi neprošlo - už přechod z verze 5.0 na aktuální nám zabral přes 300 člověkohodin, natož změna na něco jiného.

[pavlix]

Potom to zjevně byly vyhozené peníze, jestliže jste přešli na novou verzi software, který vám neposkytuje to, co byste potřebovali, ať už ho dostatečně neovládáte nebo má reálná omezení.

[Filip Jirsák]

I s MySQL to ale řešení má, ne? Přidat do tabulky sloupec, který bude plněný triggerem při insertu a updatu (doplní jméno uživatele pro příslušné domény, pro ostatní doplní null), a nad tímto sloupcem vytvořit unikátní index. Není to úplně čisté řešení, protože se do schématu musí přidat "zbytečný" sloupec, ale nejspíš to bude jednodušší, než měnit databázi.

[pavlix]

I s MySQL to ale řešení má, ne?

Nepsal jsem nic o tom, že by nemělo mít.

[Ja]

Myslím, že to vyhozené peníze nebyly - aplikace teď snese několikanásobně větší zátěž. Zatím tu (na fóru) nikdo nezmínil, jak to řešit v něčem jiném, pouze tu padl abstraktní návrh použít "něco jiného".

Zatím mi připadá nejlogičtější zavést pojem jakési skupiny domén a místo domain_id zahrnout do klíče id té skupiny - řekl bych, že to nejlíp vystihuje podstatu řešeného problému. Zamykání či ten trik s having v mém dotazu na mne teď působí jako zbytečná obezlička.

[pavlix]

Zatím mi připadá nejlogičtější zavést pojem jakési skupiny domén a místo domain_id zahrnout do klíče id té skupiny - řekl bych, že to nejlíp vystihuje podstatu řešeného problému.

Dost možná to vystihuje i princip toho problému.

[kuka]

Nejjednodussi je zamknout celou tabulku a pak si v ni udelat kontrolu podle libovolnych business pravidel. Bezne se to pro tento typ operaci pouziva, protoze se obvykle vyskytuji v porovnani s ostatnimi minimalne (novy uzivatel, zruseni, prejmenovani). Samozrejme pokud by slo o aplikaci, kde se zaklada z webu tisic uzivatelu denne, idealni by to nebylo.

[Logik]

Pokud nejde zamknout celou tabulku, tak bych doporučoval nejjednodušší řešení - dát do tabulky ještě jeden sloupec "efektivní doména" a udělat složenej klíč nad ní..... Vyplňovat se může trigerem nebo aplikační logikou.

[Logik]

Koukám, že sem těsně druhej, že tu už todle řešení je