Code Review s Architektem, Round #4: Generování IDs pro offline app rubrika: Programování: .Net
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
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:
Nebo se přihlaste jménem a heslem:
Komentáře