On Wed, Jul 29 2020, Jaroslav Klapalek wrote:
--- 1/2 Úprava databáze coffee_db.sql | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+)
diff --git a/coffee_db.sql b/coffee_db.sql index 51f83aa..5248d4c 100644 --- a/coffee_db.sql +++ b/coffee_db.sql @@ -38,6 +38,32 @@ insert or ignore into days values (0),(1),(2),(3),(4),(5),(6) ;
+create table if not exists event_types ( + id integer primary key, + name varchar(255) not null, -- name of the event
Podle mě to není jméno události, ale objekt, se kterým se pracovalo. Nebyl by "object" lepší název?
+ status varchar(32) not null, -- `status` x days ago (required when `display`=1)
Status se mi taky nelíbí. Co třeba verb_past? Do komentáře bych napsal: Used when display=1 in sentence "`verb_pase` X days ago".
+ action varchar(32) not null, -- label of button to register event
Proč to nenazvat rovnou button_label?
+ display integer default 1, -- 1 for showing the latest occurence on the main page + trigger integer references event_types(id) default NULL + -- When set, registering this event will also count for `trigger` event +);
Když tak o tom přemýšlím, tak tabulka event_types z velké části slouží k tomu, aby definovala user interface. A pokud vím, tak většinou se lidi snaží "user interface" a "business logiku :-)" od sebe co nevíc oddělit. Nevyšel by pak ten kód jednodušší? Místo netriviálních SQL dotazů by tam byl jednodušeji pochopitelný kód v pythonu? Tabulka event_types by obsahovala jen id a name a s databázi bys interagoval jen pomocí event_add(name) a event_list_last() a překlad do lidského jazyka bys dělal buď pythonem nebo v html templatu. Co o tom soudíš? Na zbytek se případně podívám zítra. -M.