Komentáře k příspěvku: Tisk a evidence faktur, díl 1½ – ještě k databázi

Od: jan

jan — Sat, 02 Jun 2007 15:32:29 +0000

"Co se adres tyce, mozna by pomohl priznak je-li adresa aktivni ci nikoliv."

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.

Od: Karel Benák

Karel Benák — Fri, 18 May 2007 10:51:08 +0000

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.

Od: jan

jan — Tue, 01 May 2007 13:53:49 +0000

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ě.

Od: Honza

Honza — Tue, 01 May 2007 13:45:34 +0000

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á?

Od: Mirek

Mirek — Sun, 29 Apr 2007 20:00:13 +0000

Nahodou chyby, nebo spis slepy ulicky maji jednu vynikajici funkci: umozni dokonale zmapovat hranice pole pripustnych reseni.

Od: Pavel

Pavel — Sun, 29 Apr 2007 19:40:40 +0000

chybama se člověk učí…. jen kdo nic nedělánic nepokazí….

Od: jan

jan — Sun, 29 Apr 2007 17:33:18 +0000

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 address k subject, 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.

Od: Mirek

Mirek — Sun, 29 Apr 2007 16:28:11 +0000

Nejsi blb … jen jsi to prehlidnul … to je proste TVORBA :o)

Od: Marek Vidtman

Marek Vidtman — Sun, 29 Apr 2007 16:23:41 +0000

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…

Od: Marek Vidtman

Marek Vidtman — Sun, 29 Apr 2007 16:21:28 +0000

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 ;)

Od: Marek Vidtman

Marek Vidtman — Sun, 29 Apr 2007 16:15:17 +0000

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…)

Od: jan

jan — Sun, 29 Apr 2007 14:18:25 +0000

Marek Vidtman: Jasně, dyť jsem blb… jdu to hned opravit.

Od: Marek Vidtman

Marek Vidtman — Sun, 29 Apr 2007 14:11:03 +0000

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…