Tisk a evidence faktur, díl 1½ – ještě k databázi
Věcné připomínky Jirky Pecha, Jakuba Vrány a fousa mě donutily původní návrh databáze hodně upravit. Mám tu pro vás finální verzi a pár poznámek.
Hledáte něco na faktury?
Fakturoid – tisk a správa faktur pro živnostníky a malé firmy. Konečně jednoduše.
Mimochodem, dopadlo to nakonec úplně jinak, než v této sérii článků ;)
Ostatní díly:
Naši databázi vidíte na obrázku č. 1, zde je soubor s SQL create příkazy a výsledný soubor DBDesigneru.
Obrázek č. 1 – Nová databáze pro jednoduchou aplikaci na tisk a evidenci faktur
Stručně o tom, co se měnilo:
- V původním návrhu by se nedala vůbec vystavit faktura, protože tam nebyl prostor pro částky a DPH, jak mě vtipně upozornil Jirka Pech. Ehm, inu tak. Tady si můžete přečíst mou chabou obhajobu.
- Byl jsem nucen uznat, že Jakub Vrána má pravdu, když říká, že zvláštní tabulka
invoice_has_subjectsje zbytečná asupplier_idicustomer_idse nám přesunuli přímo do tabulkyinvoice. - fous přispěl poznámkou o potřebě různých adres pro subjekty (sídlo, fakturace apod.)
- Sám jsem pak ještě vyhodil z tabulky subject pole pro kontaktní osobu a dal jsem je do tabulky
person.
Taky vás tak fascinuje, když se začnete zabývat naprosto jednoduchým problémem a postupně zjišťujete, že v sobě skrývá složitosti, které se před vámi rozkrývají a každá cesta nabízí mnoho odboček a ty zase další a další?
Proto je důležité stanovit si nějaký základní cíl, což v našem případě je tisk a jednoduchá evidence faktur, toho se držet a zaměřit se pouze na to, co je naprosto nezbytné pro jeho dosažení a rychle se snažit dostat k uživatelskému rozhraní, k něčemu, co bude reálné. Mnohem lépe popsané to najdete v Getting Real.
Trik je v tom, kde udělat tu dělící čáru, co je naprosto nutné a co už je bonus.
Zároveň musíme myslet na možnosti budoucího rozšíření. V naší databázi je to třeba tabulka person nebo možné navázání dalších tabulek na task pro podrobnou evidenci času.
Trik je v tom, kde udělat tu dělící čáru, co je naprosto nutné a co už je bonus. Tady to bylo ještě celkem jednoduché, protože nutné je to, co se musí vytisknout na fakturu, u jiných aplikací je řez mnohem složitější.
Ještě jednou díky všem za připomínky. Budu snažit rychle napsat další díl. Reálně to vidím tak na 14 dní, protože v práci máme rozjeté projekty, které si v následujících dnech vyžádají většinu mého času. V hlavě mám ale pár menších článků, které snad stihnu publikovat dřív.
Zatím se mějte.
V tomto návrhu nebude fungovat (v jednom z komentářů k předchozímu článku) zmíněné propojení více adres na subject (tabulky SUBJECT a ADDRESS). Zde by měla být ještě nějaká spojovací tabulka, která by dokázala na subject navázat více adres – id(INT), subject_id (SMALLINT), address_id(SMALLINT). Pak bude mít smysl i tabulka ADDRESS_KIND, teď je tam celkem k ničemu…
Marek Vidtman: Jasně, dyť jsem blb… jdu to hned opravit.
Tak ještě podobně je na tom tabulka PERSON a PERSON_CONTACT. Předpokládam tedy, že každá osoba může mít více typů kontaktu (tel., mobil, ICQ, mail atd…)
Beru zpět… nevšiml jsem si person_id v tabulce PERSON_CONTACT… to vlastne dava prostor k zamysleni, zda muj prvni komentar taky neni spatny a nestacilo by misto spojovaci tabulky SUBJECT_HAS_CONTACT pridat subject_id do tabulky CONTACT…
Analyza je dulezita ;)
a dulezite je precist si po sobe, co clovek napise a pak to teprve poslat… samozrejme, ze jsem myslel tabulku ADDRESS…
opravena veta tedy zni:
>>>nestacilo by misto spojovaci tabulky SUBJECT_HAS_ADDRESS pridat subject_id do tabulky ADDRESS…
Nejsi blb … jen jsi to prehlidnul … to je proste TVORBA :o)
Marek Vidtman: Však mi to tam na konec dokopeme :D S tou adresou jsem to upravil a už mi došlo, kde jsem předtím udělal chybu: já jsem natáhnul ten vztah od tabulky
addressksubject, mělo to být opačně. A pak jsem se nechal únést a tu vztahovou tabulku jsem tam zbytečně hodil.Mirek: Díky za podporu ;)
Uf, to je chyb… nemám zrovna šťastnou sérii, ale věřím, že to nějak překousnete.
chybama se člověk učí…. jen kdo nic nedělánic nepokazí….
Nahodou chyby, nebo spis slepy ulicky maji jednu vynikajici funkci: umozni dokonale zmapovat hranice pole pripustnych reseni.
Nevim, jestli jsem to nepřehlíd, nebo jestli je to tam někde skryto, ale je také myšleno na to, že si zákazník časem změní adresu, ale na původní (už vydané) faktuře musí adresa zůstat stále stejná?
Honza: Ha, dobrý postřeh! Po pravdě mě v tomhle jednoduchém příkladu nenapadlo promýšlet to do takových podrobností. Pokud bychom se nesmířili s tím, že v případě potřeby vytisknout nějakou starou fakturu, kde by měla být jiná adresa, budeme odkázáni na ruční úpravu kódu (protože faktura bude HTML stránka), museli bychom vytvořit zvláštní tabulku, která by obsahovala „konfiguraci“ každé faktury.
To mi ale přijde hodně nad rámec tohoto příkladu. Nicméně, díky za připomínku, je rozhodně na místě.
Co se adres tyce, mozna by pomohl priznak je-li adresa aktivni ci nikoliv. Editaci adresy bych zakazal, pouze jeji zneplatneni – prave pro potreby starych faktur. Co se mi ale nepozdava je fakt, ze jedna adresa muze byt fakturacni, dodaci apod. Jelikoz mate v tabulce adres cizi klic na subject, muzete v tabulce adres zkusit definovat slozeny primarni klic z id a subject_id. Cizi klic subject_id tak bude zaroven soucasti primarniho klice.
V tabulce invoice Vam podle meho nazoru chybi dodaci a fakturacni adresy, coz si predstavuju jako slozene cizi klice do tabulky address, takze kombinace (customer_id, invoice_address), (customer_id, delivery_address) a (supplier_id, invoice_address) by Vam ukazovaly na primarni klic tabulky address, tedy na (subject_id, id). Tim byste mohl mit zajisteno, ze nemuzete ve fakture priradit spatnou adresu.
Predpokladm ze toto schema navrhujete pro MySQL. Pokud je to novejsi verze nez-li je 4.1.X, pak byt Vami, rozhodne pouziju pohledy.
Jo, asi jo. Určitě je tu víc nedomyšlených věcí. Jak píšu v článku, nikdy nedomyslíme všechno, takže je důležité se rychle dostat k uživatelskému rozhraní a tam na chyby přijít.