Jak vybudovat malou softwarovou firmu

Návrh datového modelu

Úspěšná softwarová firma musí dodávat úspěšné projekty. Takový software musí být stabilní, dostatečně rychlý a umožňovat další rozvoj. Tím pádem potřebuje kvalitní datový model. Pokud se databáze začne zadrhávat při větším množství dat nebo nejde jednoduše přidat další zákazníkův požadavek, či data neumožňují získal potřebnou informaci je to problém a firma ztrácí důvěru zákazníka. Já se řídí při návrhu nemnoha pravidly která mě provedla všemi těmito zmíněnými úskalími. Pojďme si je probrat.

Barevné odlišení druhů dat a vazeb

Na následujícím obrázku můžeme na první pohled odhadnout jaké tabulky jsou hlavní, které jsou podpůrné nebo že některé jsou něčím specifické. Je dobré umístit třeba vlevo nahoru i nějaké vysvětlivky co které barva znamená.

Tak například na tomto datovém modelu jsou hlavní tabulky oranžové, méně důležité tabulky světle oranžové, podpůrné tabulky zelené, polymorfní tabulky jsou magicky fialové. Spojovací tabulky jsou modré a typové tabulky žluté.  

Důvodem je zjednodušit orientaci v tom jak data putují.

Například žluté tabulky pro sledování datového toku můžeme ignorovat. Na druhou stranu až programátoři začnou pracovat na interpretaci dat pomocí  nějakého ORM budou vědět že žluté tabulky bude potřeba vytvořit jako první.

U fialových tabulek nebudeme hledat napojení přes primární klíč, protože jsou odkazovány polymorfní vazbou. 

Šedivé jsou komentáře které vysvětlují smysl tabulky nebo i obsah u typových tabulek.

Unikátnost dat

Při návrhu bychom měli využít nadhledu který máme. Na rozdíl od vývojáře, který implementuje konkrétní funkcionalitu vidíme data v širším měřítku. Vývojář se soustředí jen na danou věc a snadno mu unikne, že kolega podobná data využívá jinde. A tak vytvoří duplicitu. Později dojde k situaci kdy bude potřeba data propojit třeba kvůli nějakým hodnocením a v tu ránu budete propojovat tabulky pomocí vazby přes texty a mořit procesor zbytečnými operacemi a ztrácet kredit u zákazníka až se bude divit proč u konkurence trvá akce milisekundy a u vás minuty …

Proto při návrhu DM dbejte unifikovat podobná data do jedné tabulky. Na tabulku pak vytvářet vazby z ostatních tabulek jak bude potřeba. 

Mnohdy lze podobnou věc řešit pouze polymorfně. Tím se vyhneme tomu aby v nějaké takovéto tabulce bylo třeba deset sekundárních klíčů. Kdy vždy je jeden naplněný a ostatní prázdné.

Příkladem může být tabulka “poznámky”, kdy chcete v aplikaci mít možnost umístit jednu nebo několik poznámek ke kterémukoliv záznamu. Řekněme k firmě, uživateli, objednávce, faktuře, adrese, prostě čemukoliv si zákazník řekne. Pak použijeme polymorfní řešení, viz obrázek.

Jindy tuto situaci vyřeší typová tabulka. Příkladem může být druh/role uživatele. Nebudeme vytvářet tabulku zákazníci a tabulku administrátoři. Vytvoříme tabulku uživatel a k němu typovou tabulku role …

Typové tabulky rulezz

Obecně je antipatern mít v kódu cokoliv “zadrátováno”. To platí i o výčtových typech. Každý slušný programátor ví, že mít v kódu například čísla je škodlivé, protože nikdo za týden nebude vědět proč je někde číslo 7 a jinde 16. To samé platí ale opačně pro databázi, kde se v záznamu objeví text “inprogress”. Ale co tam má byt v jiných případech? 

Jak víte že zrovna “new, inprogress, completed, blocked, approved” jsou ty správné hodnoty, když nejsou nikde k mání? 

Budete prolézat celou aplikaci a hledat kde se co vyskytuje za varianty? Výčtové typy patří do typové tabulky.

Další důvod je rychlost… vždy bude pro procesor jednodušší indexovat čísla, než různě dlouhé texty. Rovněž můžete vazbu na stejnou typovou tabulku použít vícekrát a ušetříte úložiště.

Přemýšlet dopředu

Možná je to schopnost, možná je to zvyk ale rozhodně je to dobré. Někteří tvůrci datového modelu se zaměří pouze na přání klienta v danou chvíli a vytvoří DM podle toho. To by možná fungovalo pro projekty které ustrnou ve vývoji. Jenže pokud se projekt osvědčí tak klient bude chtít do projektu přidávat nové funkce, vlastnosti, modifikace a tak dále. 

Proto je při návrhu potřeba přemýšlet i tímto směrem. Zbytečně si nezasekávat cestu. Například již zmiňovaná poznámka, kterou aktuálně chce klient jen k objednávce. Mysleme na budoucnost a udělejme je tak, aby se dala dát ke všemu na co si klient v budoucnu vzpomene. 

Nebo i zmiňovaná role uživatele. Raději ji rovnou udělejme M:N a nikoliv jen N:1. Jednou klient třeba zjistí, že potřebuje mít zákazníka s rolí administrátor a pro vás to nebude žádný problém.

Poznámky k tabulkám 

Mnohdy mám v DM víc poznámek než tabulek. Důvodem je zachování myšlenky. Když DM vytvářím, je mi vše jasné. Ale jednou budu potřebovat vysvětlit DM kolegům, nebo po třeba po půlroce udělat nějakou zásadnější změnu.

V tu chvíli jsou poznámky k nezaplacení, protože mi pomohou se rozpomenout jak jsem co myslel v době tvorby. 

Realizace projektu 

Když jsme v minulých článcích prošli založením firmy, přijímáním zaměstnanců, plánováním projektu a teď tvorbou základů software, je čas se věnovat  praktickému řízení chodu firmy (Firemní management) za účelem realizace projektu. 

Dozvíte se jak v hybridním prostředí, které se dnes prosazuje kvůli všelijakým epidemiím a nutnosti pracovat nějakou dobu z karantény řídit firmu bez ztráty přehledu a jistoty, že práce bude odevzdána včas a v požadované kvalitě.

Tak zase příště

Josef Chmel 

Jednatel v WorkVector. s.r.o. 

https://workvector.com