V předchozím díle našeho seriálu jsme nakousli téma vývoje rozsáhlejších projektů. Dnes budeme pokračovat; řekneme si něco o přípravě struktury databáze a o členění programu. Tyto věci je potřeba udělat již v poměrně rané fázi vývoje, abyste měli jasno, kam se bude Vaše aplikace ubírat.

Data a databáze

Pokud aplikace má (a ona má skoro vždycky) nějaký vztah k databázi, bývá dobrým zvykem navrhnout si, jak bude taková databáze vypadat. To je velmi důležitá část přípravy. Není nic horšího než dodělávání struktury databáze "za chodu", a to zejména mají-li se měnit relační vztahy mezi tabulkami. Obecné pravidlo, jak to udělat "napoprvé a dobře" pravděpodobně neexistuje. Ale jako příklad naznačíme, jak by se mohla ubírat naše představivost při sestavování (dejme tomu) protálu pro ON-LINE evidenci půjčování knížek z knihovny.

Pozn.: Musíte uznat, že to je daleko méně otřepaný příklad než ON-LINE obchod.

Důležité je si uvědomit, že každá tabulka by měla shromažďovat data o jedné "entitě". Tento hrozný výraz zkrátka znamená, že budeme mít tabulku "knih", tabulku "čtenářů" a tabulku "výpůjček". V MySQL by návrh mohl vypadat nějak takto:

Bude to stačit? V případě, že budeme půjčovat jen jednu knihu, zcela určitě to jako kostra stačit bude; pokud bychom najednou půjčovali více knih, stojí za zvážení zřízení další tabulky, aby se nám udaj "půjčeno od" neopakoval zbytečně v mnoha řádcích. Níže uveďme některé technické zásady, které byste měli mít při tvorbě tabulek k dispozici:

• Ujasněte si, zda budete používat v názvech databázových objektů malá, velká písmena nebo jejich kombinace. V MySqL to totiž není jedno.
• Zaveďte si nějakou metodiku pojmenování polí. Například já jsem použil "id" jako název klíče v každé tabulce. To Vám může a nemusí vyhovovat (někdo třeba používá "ctenari_id", "knihy_id" a podobně).
• Je-li to jen trochu možné, používejte nějaké vizuální pomůcky pro návrh databáze
• Navrhněte nejprve pole, sloužící jako primární a cizí klíče. Například, tabulka výpůjček bude jistě mít i pole datum_do, knihy mohou mít čárový kód a podobně. Nicméně, pro představu o vztazích mezi tabulkami stačí výše uvedená sktruktura.

Členění programu

Dobře napsanou funkci můžete použít vícekrát. A to i v mnoha projektech a v tom je kouzlo opakovaného používání kódu. Zvažme, například, následující kód pro ověření hesla, který bychom chěli využít v několika projektech:

Poctivě řečeno, tato funkce moc dobře napsána není. V reálné aplikaci by pravděpodobně stačilo použít existující připojení k databázi, spíše než uvnitř těla funkce vytvářet nové (důvodem je to, že pravděpodobně už nějaké to připojení k databázi bude existovat, nebo by zanedlouho stejně vzniklo). Další problém je logický - nejprve zjišťujeme zda existuje uživatel a potom, zda má správně heslo. To by se dalo spojit do jednoho kroku. Třetí důvod proč to nepůjde použít je ten, že k funkci není žádná dokumentace. Po úpravě by to mohlo vypadat mnohem nadějněji (třeba takto):

Všimněte si (vím, že se opakuji), že kvalitní kód obsahuje komentáře. To proto, abyste se v něm vyznali, když jej budete za nějakou dobu chtít opravit - nebo znovupoužít. Toto téma je tak důležité, že mu věnujeme i část následujícího dílu.