Datový model rozšiřovaný uživatelem
34 views
Skip to first unread message
Vladimir Macek
Mar 19, 2016, 4:52:06 PM3/19/16
to djan...@googlegroups.com
Rád bych se poradil.
Situace:
Představte si, že máte pro nový týmový projekt CSV s 2000+ důležitými
záznamy třeba o 10 sloupcích. Sloupce mají různé datové typy a data se
NEbudou měnit. Ýzy, vytvoříme model Record o 10 sloupcích, data nalejeme,
máme pohodlnou editaci Django adminem atp.
Jenže, ty záznamy se musejí jeden za druhým projít a provést rešerši,
jednání atp. a výsledky těchto lidských úkonů budete chtít komplet
evidovat, pro jednotlivé záznamy. Najmete na to člověka, což není
programátor a migrace db mu nic neříkají.
Ale musí mít možnost přidávat nové sloupce a efektivně zapisovat zjištěná
data. Předem nevíte, jaké sloupce to budou. Zjednodušme to, že hodnoty
stačí text.
Navíc, u některých sloupců potřebujete možnost výběru ze sady
předdefinovaných variant. To aby pracovník nemusel vypisovat pokaždé text,
jen si rychle vybral z možností a zamezilo se překlepům. Sadu možností má
mít právo rozšiřovat. On se bude spolupodílet na vytváření datového modelu,
který není předem známý.
Tento proces má konec. Po skončení prací můžeme Record obohatit o zjištěné
sloupce migrací.
Nice to have: Uvítáte možnost zabránit tomu, aby pracovník B nevratně
přepsal údaje uložené pracovníkem A.
Pozn.: Celkovým výsledkem má být tabulka obohacených záznamů a bude to v
djangovském projektu. Ale proces získávání dat ze světa nemusí probíhat v
Djangu. Jen mi přijde, že při tomto množství záznamů a možnostech Django
admina bude praktické v Djangu rovnou začít a mít rovnou použitelnou tabulku.
Nápad na řešení:
Model Key s charfieldem 'key'. Pracovník bude mít právo přidávat nové
objekty Key a mazat ty, na které nic neodkazuje. RecordAdmin bude mít oněch
původních 10 read-only fieldů, ale pod ním bude ActivityAdminInline s FK na
Key.
Pracovník zjistí nějaký údaj o Recordu. Tak vybere z roletky v inlinu klíč,
doplní textovou hodnotu a odešle. Případně přidá nový Key ("sloupec").
Jak byste řešili tu konkurenci? Mně napadlo znemožnit pracovníkovi editaci
už odeslaných aktivit a že se za platnou brala jen ta poslední.
Na takovéty dynamicky přidávané ChoicesFieldy si ale žádné řešení neuvedomuju.
Chtěl bych to samozřejmě nahozené rychle s minimem programování a hacků.
Nějaké tipy?
Díky!
V.
Situace:
Představte si, že máte pro nový týmový projekt CSV s 2000+ důležitými
záznamy třeba o 10 sloupcích. Sloupce mají různé datové typy a data se
NEbudou měnit. Ýzy, vytvoříme model Record o 10 sloupcích, data nalejeme,
máme pohodlnou editaci Django adminem atp.
Jenže, ty záznamy se musejí jeden za druhým projít a provést rešerši,
jednání atp. a výsledky těchto lidských úkonů budete chtít komplet
evidovat, pro jednotlivé záznamy. Najmete na to člověka, což není
programátor a migrace db mu nic neříkají.
Ale musí mít možnost přidávat nové sloupce a efektivně zapisovat zjištěná
data. Předem nevíte, jaké sloupce to budou. Zjednodušme to, že hodnoty
stačí text.
Navíc, u některých sloupců potřebujete možnost výběru ze sady
předdefinovaných variant. To aby pracovník nemusel vypisovat pokaždé text,
jen si rychle vybral z možností a zamezilo se překlepům. Sadu možností má
mít právo rozšiřovat. On se bude spolupodílet na vytváření datového modelu,
který není předem známý.
Tento proces má konec. Po skončení prací můžeme Record obohatit o zjištěné
sloupce migrací.
Nice to have: Uvítáte možnost zabránit tomu, aby pracovník B nevratně
přepsal údaje uložené pracovníkem A.
Pozn.: Celkovým výsledkem má být tabulka obohacených záznamů a bude to v
djangovském projektu. Ale proces získávání dat ze světa nemusí probíhat v
Djangu. Jen mi přijde, že při tomto množství záznamů a možnostech Django
admina bude praktické v Djangu rovnou začít a mít rovnou použitelnou tabulku.
Nápad na řešení:
Model Key s charfieldem 'key'. Pracovník bude mít právo přidávat nové
objekty Key a mazat ty, na které nic neodkazuje. RecordAdmin bude mít oněch
původních 10 read-only fieldů, ale pod ním bude ActivityAdminInline s FK na
Key.
Pracovník zjistí nějaký údaj o Recordu. Tak vybere z roletky v inlinu klíč,
doplní textovou hodnotu a odešle. Případně přidá nový Key ("sloupec").
Jak byste řešili tu konkurenci? Mně napadlo znemožnit pracovníkovi editaci
už odeslaných aktivit a že se za platnou brala jen ta poslední.
Na takovéty dynamicky přidávané ChoicesFieldy si ale žádné řešení neuvedomuju.
Chtěl bych to samozřejmě nahozené rychle s minimem programování a hacků.
Nějaké tipy?
Díky!
V.
Jan Češpivo
Mar 20, 2016, 5:57:11 AM3/20/16
to djan...@googlegroups.com
Ahoj, nejdriv bych se zamyslel, zda ma vubec smysl pouzit relacni databazi a radeji pouzit nejakou nosql, kdyz tam nejsou zadne vztahy a struktura je navic predem neznama.
H.
--
--
E-mailová skupina djan...@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
---
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete e-mail na adresu django-cs+...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/django-cs/56EDBBF7.3080700%40sandbox.cz.
Další možnosti najdete na adrese https://groups.google.com/d/optout.
Jan Bednařík
Mar 20, 2016, 8:38:50 AM3/20/16
to djan...@googlegroups.com
Tohle vypadá na ideální projekt pro Google Docs Sheets. Máš tam historii změn, flexibilitu ve sloupcích a datových typech, user friendly pro neprogramátory, a ty ostatní featury co od toho chceš. Když ta data budeš chtít využít i jinde, půjdeš nato přes API.
A co je hlavní, už je to hotové, tak to nemusíš programovat :-)
Honza
Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAChT7t9bttNyx9WcnbQr1MYpQ6jnv3L-9cCake9kNtV2qum32w%40mail.gmail.com.
Další možnosti najdete na https://groups.google.com/d/optout.
Jan Češpivo
Mar 20, 2016, 9:37:43 AM3/20/16
to djan...@googlegroups.com
+1 :)
Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAMmgUkPobTsOEJ3QdNNPT5_xxkCxUFup_zrhd%3D_DoYVqezCPXw%40mail.gmail.com.
Honza Král
Mar 20, 2016, 9:38:37 AM3/20/16
to djan...@googlegroups.com
Tohle vypada, ze je tema pro Honzy, tak se take pridam.
Take bych to neresil pridavanim sloupcu a misto toho sahnul po necem
flexibilnejsim. Ne nutne cele NoSQL ktere by te asi pripravilo o dost
vyhod (viz ten admin), ale treba json field (prihreju si polivcicku s
https://pypi.python.org/pypi/django-appdata) ktere ma nekde ulozene
schema atp.
Honza
Honza Král
E-Mail: honza...@gmail.com
Phone: +420 606 678585
> https://groups.google.com/d/msgid/django-cs/CAMmgUkPobTsOEJ3QdNNPT5_xxkCxUFup_zrhd%3D_DoYVqezCPXw%40mail.gmail.com.
Take bych to neresil pridavanim sloupcu a misto toho sahnul po necem
flexibilnejsim. Ne nutne cele NoSQL ktere by te asi pripravilo o dost
vyhod (viz ten admin), ale treba json field (prihreju si polivcicku s
https://pypi.python.org/pypi/django-appdata) ktere ma nekde ulozene
schema atp.
Honza
Honza Král
E-Mail: honza...@gmail.com
Phone: +420 606 678585
Vladimir Macek
Mar 20, 2016, 10:09:28 AM3/20/16
to djan...@googlegroups.com
Děkuji všem Honzům i ostatním,
ano, došel jsem k tomu v noci také. Zůstaneme v Google Tabulkách. Djangem
by se to teď velmi zesložiťovalo.
Hlavní záznam bude v jedné tabulce, která se bude po buňkách doplňovat a
podzáznamy (kterých se navíc ukázalo může být k jednomu Record víc) se
budou přes identifikátor plnit Google Formulářem do další tabulky "odpovědí".
Google Formuláře spojené s Tabulkou jsou mimochodem chytře implementované.
Když potřebujete přidat v průběhu vyplňování do Formuláře nějaké pole, dodá
se nový sloupec na konec tabulky a klidně tam může být i vámi mezitím ručně
vytvořený sloupec atp.
Až pracovnice data dokončí, tak se to naleje do postgresu. Změn schématu
pak už bude minimálně, standardní migrace i datové.
Dík za tip na django-appdata, smysl je ze stránky bohužel ale špatně
pochopitelný a tak si to jen zasunu do hlavy.
V.
--
: Vladimir Macek : http://macek.sandbox.cz : +420 608 978 164
: UNIX && Dev || Training : Python, Django : PGP key 97330EBD
: I think my spaceship knows which way to go...
ano, došel jsem k tomu v noci také. Zůstaneme v Google Tabulkách. Djangem
by se to teď velmi zesložiťovalo.
Hlavní záznam bude v jedné tabulce, která se bude po buňkách doplňovat a
podzáznamy (kterých se navíc ukázalo může být k jednomu Record víc) se
budou přes identifikátor plnit Google Formulářem do další tabulky "odpovědí".
Google Formuláře spojené s Tabulkou jsou mimochodem chytře implementované.
Když potřebujete přidat v průběhu vyplňování do Formuláře nějaké pole, dodá
se nový sloupec na konec tabulky a klidně tam může být i vámi mezitím ručně
vytvořený sloupec atp.
Až pracovnice data dokončí, tak se to naleje do postgresu. Změn schématu
pak už bude minimálně, standardní migrace i datové.
Dík za tip na django-appdata, smysl je ze stránky bohužel ale špatně
pochopitelný a tak si to jen zasunu do hlavy.
V.
: Vladimir Macek : http://macek.sandbox.cz : +420 608 978 164
: UNIX && Dev || Training : Python, Django : PGP key 97330EBD
: I think my spaceship knows which way to go...
Reply all
Reply to author
Forward
0 new messages