Code Review s Architektem, Round #4: Generování IDs pro offline app rubrika: Programování: .Net

2 Jaroslav Urban
položil/-a 20.5.2017

Zdravim,
měl bych jeden případ z praxe, třeba ho již někdo řešil ku vlastní spokojenosti. Tak ať neopakuji co už bylo vymyšleno.

Scenář

  • mobilní apka načte data z API, pracuje s nimi a pak je nahrne na API.
  • mobilní apka pak z daty pracuje a při tom vytváří i nové záznamy a tady se dostáváme k jádru pudla, jelikož API používá int jako PK a většinou jako autoincrement.
  • z hlediska optimalizace se data načítají většinou jako bulk, tedy žádné rest api. Protiargumentem pro to více využít rest přístup je, že uživatel může všechny změny zahodit nabo udělat pár undo a taky jsme nechtěli aby se po každé drag&drop akci musela volat api a vytvářet nová záznám
  • ios apka se má používat na iPadu v lokální síti

Problém

  • jak na generování ID

Řešení A

  • předělat db, endpointy a použít GUID/UUID

Pros

  • id lze bezpečně generovat i v apce
    Cons
  • guid je mnohem náročnějsí na pamět, místo
  • museli bychom měnit výrazně db, endpointy

Řešení B

  • mít endpoint přes který by si apka alokovala nějaký range IDs.
  • alokovaná IDs by se pak používala v apce pro ukládání a na API db by se vytvářeli empty záznámy

Pros

  • moc nevím
    Cons
  • problém s referenční integritou např. nenulové fieldy, fk a podobně
  • defragmentace IDs

Řešení C

  • použít kombinaci dvou rozsahů pro id. Id co bude vracet API, které bude kladný Int a ID, které bude vracet apka pro nové záznamy bude záporný Int. API pak bude vědět, že pokud ID bude negative, tak musí vytvořit nový záznam

Pros

  • není nutné nějak měnit strukturu rest objektů, ani db
    Cons
  • nutno mít extra proces na procházení requestů a vytváření nových záznamů
  • podle mě se tohle neobejde bez toho, že si apka musí refrešnout data

Pro jakou implementaci byste se rozhodli a proč? Případně, navrhli byste jinou?

V případě nejasností se hlaste, pokusím se případně nějaký komentář, či vysvětlení. Děkuji za vaše případné příspěvky. JU

Komentáře

  • Honza Břešťan : Musi ta aplikace vubec znat nejaka ID pred tim, nez jsou nove vytovrene objekty prijaty serverem? Pripadne bude zatez tak velka nebo disconnecty tak dlouhe, aby nesla pouzit optimistic concurrency? Stahl jsem zaznamy s max ID 150, potrebuju vytvorit novy, tak ho tam poslu s ID 151. Bud ho server prijme jak je, nebo ho muze odmitnout s tim, ze 151 uz existuje a mam si refreshnout data, nebo ho server prijme, ale da mi vedet, ze skutecne nove ID je 152. Pokud ani jedno z toho nedava smysl, tak bych volil GUID - ale ne jako PK v DB (to se vubec nema dostat na nejake API), ale jako externi/sekundarni identifikator 20.5.2017
  • Jaroslav Urban : @HonzaBrestan ten scenar s tim ze by apka zjistovala jaky byl posledni zaznam, je nerealny. pri te editaci dochazi ke zmenam na vice entitach a zmen je vice. to by strasne trvalo a navic by tam byla asi nekolik dotazu na server. S sekundarnim identifikatorem, nevimdim v tom prinos oproti tomu, ze bys pouzil zpusob C. Muzes nejak vysvetlit, co jsi mel na mysli? 21.5.2017
odkaz
3 rs
odpověděl/-a 20.5.2017

za me A.
Pred nakym casem jsem se rozhodnul ze od ted uz budu vzdy pouzivat UUID misto intu / sekvenci / autoincrementu a bylo to jedno z nejlepsich rozhodnuti co jsem udelal. Z dlouhodobeho hlediska to resi spoustu problemu, zjednodusuje testovani a je to proste spravne. Pokud se na ID divam jako na identifikator objektu / entity tak proste vytvareni objektu bez ID je spatne je to nevalidni objekt. Potom musim prave resit situaci kdy na nej nejsem schopen nic navazat musim mu neco umele vnucovat zhorsuje to testovani..

Oproti tomu nevyhody UUID vyssi pametova narocnost jsem nak zasadne nezaznamenal, u embeded systemu by to asi byl problem ale vsude jinde bonusy jednoznacne prevazuji nad nevyhodami. V PostgreSQL mam pro UUID nativni podporu v mysql je to trosku narocnejsi ale taky se da

Komentáře

  • podhy : paměťovou náročnost UUID poznáte ve chvíli kdy potřebujete joinovat miliony záznamů (osobní zkušenost) a pak jde výkon rapidně dolu. UUID použít jen tam kde má smysl....sám používám občas hybridní přístup, kde pro náročné věci zvolím sekvenci a tam kde na tom nesejde používám UUID kvůli jeho některým výhodám 20.5.2017
  • rs : Netvrdim ze tam rozdil neni ale co jsem googlil a testoval viz treba toto srovnani: http://www.cybertec.at/int4-vs-int8-vs-uuid-vs-numeric-performance-on-bi... tak rozdil neni natolik vyrazny aby mi stalo za to jej resit. Samozrejme pokud ma tabulka prirozeny primarni klic (napriklad kod meny u ciselniku men) tak je blbost tam davat UUID obecne ciselniky co se nemeni a jsou +- konstantni tak tam davam z pohodlnosti taky sem tam integer. 20.5.2017

Pro zobrazení všech 5 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.