Dotaz: Tvorba databáze pro jednoduchý skladový program

[Marty_Burns]

Dobrý den, potřeboval bych si s pomocí PHP a MySQL napsat jednoduchý program pro skladovou evidenci a chtěl bych poprosit zkušené programátory o radu jak tu tvorbu pojmout. Pro každou položku ve skladech potřebuju mít tabulku, která bude zaznamenávat pohyby té konkrétní položky. Dále potřebuji zaznamenávat příjemky a výdejky, tak aby byly propojeny s jednotlivými tabulkami zboží.

Jen stále nevím jak to pojmout jestli opravdu vytvořit pro každé zboží samostatnou tabulku v databázi nebo číslo toho zboží jen zachytávat v tabulce příjemek a výdejek a příslušnou tabulku pak sestavit PHP skriptem na požádání.

Docela si říkám, že v momentě kdy tam budu mít 50 000 pohybů by mohlo trvat než od sebe všechny ty příjemky a výdejky odečte a sestaví kartu(tabulku) zboží.

Proto bych se chtěl zeptat co je pro MySQL a PHP horší varianta mít v tabulce 50 000 pohybů, které bude skript neustále procházet a odečítat nebo mít 1000 tabulek v databázi a na každé jen několik řádků? Na jaké problémy bych mohl při jednotlivých řešeních narazit?

Budu velmi rád a vděčný za jakoukoliv připomínku k tématu.

---

---

Odpovědi

[Tarmaq]

Moc nechapu proc by mela kazda polozka mit svoji vlastni tabulku. Nechces spis mit Tabulku obsahujici polozky a ke kazde z tech polozek pridavat do nejake jine tabulky jeji atributy? Myslim, ze pokud to spravne navrhnes, mel bys mit ohdadem tak 10-20 tabulek (nevim co vsechno je treba evidovat). Btw nebylo by lepsi pro dane ucely sahnout uz po nejakem hotovem reseni? Urcite uz nejaky takovy system existuje..

[Marty_Burns]

Děkuji za reakci, možná přemýšlím úplně špatně. Jde o to abych byl na požadavek schopný ke každé položce na skladu sestavit nějakou podobnou tabulku: | Množství | Kč | Datum|Doklad|Obsah|Příjem|Výdej|Zásoba|Příjem|Výdej|Zásoba| 18.9. P001 nákup 5 5 50 50 19.9. V002 prodej 3 2 30 20

Dále tabulka příjemky a výdejky: ID | Typ | Datum | Doklad | Číslo zboží | Množství | Cena | 001 P 18.9. Dodák01 Zboží1 5 50 002 V 19.9. ......

Kdybych teda měl všechno zboží v jedné tabulce a k tomu jen množství a průměrnou cenu tak na požadavek sestavení tabulky zboží, že by pročesal ty příjemky a výdejky a zobrazil to jako ta horní tabulka....Myslíš že je to teda lepší řešení, než pro každé zboží sestavit tabulku zvlášť?

Hotových řešení je samozřejmě mraky, ale chtěl bych to zkusit.

[Marty_Burns]

Úplně se mi ty náčrty tabulek rozesraly, ale další uživatelé mě již dole navádějí, že mnoho tabulek je úplný nesmysl.... Děkuju

[Marty_Burns]

Rozhodně méně tabulek. Zakládat tabulky dynamicky pro každé zboží nedává moc smysl. Prostě uděláš tabulku pohybů a jeden sloupec bude odkaz na tu danou položku. Až budeš chtít z toho dostat věci jako počet pohybů za časové období, atd. tak to máš hezky v jedné tabulce a jednoduše to z ní dostaneš. 50000 záznamů na jednu tabulku je pořád docela sranda. Navíc ty těch 50k položek nebudeš procházet scriptem, ale napíšeš SQL dotaz tak, aby ti vrátil jen to co chceš.

[Marty_Burns]

Moc děkuju, pomohl si mi.

[j]

Mezi nama ... ty chces psat sklad a nemas paru o tom, jak funguje SQL?

select sum(pocet) from pohyby where zbozi = XYZ ... 10M zaznamu, cas trvani 0,3s ...

[Marty_Burns]

Tak základní dotazy umím, ale jak přesně funguje SQL a jak moc náročné pro server je podle parametru WHERE vyhledávat ve velkém množství položek jsem neměl páru. Je to pro mě spíš cvičení, ale kdyby to fungovalo určitě bych to testoval pro svou potřebu. Díky

[j]

=> o SQL defakto nic nevis.

Podivej, vyber zaznamu z linearni tabulky je pro SQL zcela trivialni uloha - specielne, pokud jsou na spravnych polich indexy. Skoro stejne trivialni je vyber z vice jednoznacne provazanych tabulek (nikoli pres textovy pole samo ...).

Samo v okamziku, kdy zacnes resit vsemozne podminky vazeb, budes prohledavat textovy pole ... tak casova narocnost dotazu roste. Ale i u milionu zaznamu se bavime maximalne o desitkach vterin (nemyslim si, ze bys dokazal napsat tak slozity query, aby trvalo dyl).

=> pro tvy ucely

1) tabulka hlavicek ... 
id_pohybu, cislo_dokladu, ... typ (vydejka/prijemka)
2) tabulka radku
id_pohybu, id_radku, id_zbozi, pocet (idealne pro prijemky trebas kladnej, pro vydejky zapornej nebo opacne)...
3) tabulka zbozi
id_zbozi, ...

Samo, nevim kam az chces zajit, dal muzes mit tabulku dodavatelu/odberatelu, kterou privazes na hlavicku ...

Priklad:

Vyber vsech dokladu s nejakym zbozim zacinajicim na ...

select distinct cislo_dokladu from hlavicky
left join radky on radky.id_pohybu = hlavicky.id_pohybu
left join zbozi on zbozi.id_zbozi = radky.id_zbozi
where zbozi.nazev like "Prkno%" 

[Marty_Burns]

V principu stačí dvě tabulky. Tabulka pohybů (příjemek a výdejek) a tabulka stavů položek. Z PHP přidávat záznamy do tabulky pohybů a pomocí triggerů aktualizovat tabulku stavů.

[Marty_Burns]

Děkuju, s triggery jsem se při mém amater programingu ještě nesetkal, ale snad se s tím popasuju.

[j]

Trigger je to nejhorsi, co muzes databazi udelat ... ;D, neni lepsi zpusob, jak dokonale zabit vykon.

=> ano, je logicky si drzet stav nekde u zbozi, a neselectovat ho ze vsech pohybu (coz by slo taky), ale dela se to tak, ze v ramci jedny transakce vlozis (insert) zaznam do pohybu + aktualizujes(beznej update) pole stav. Kdyz se neco podela, nebude ani jedno ani druhy.

[Kit]

Trigger vlastně není nic jiného, než transakce, do které insertem vložíš záznam o pohybu a aktualizuješ pole stav. Když se něco podělá, nebude ani jedno ani druhý.

Rozdíl je akorát v tom, že transakce je v aplikaci a trigger v databázi. Trigger je výkonnější a šetrnější k prostředkům databáze i aplikace.

[axel]

Trigger neni obecne vykonnejsi ani setrnejsi, zalezi na konkretnim scenari. Typicky pro velke objemy dat byvaji triggery problem, protoze neumoznuji rozumnou optimalizaci. Co mi na triggerech ale vadi vice je odtrzeni logiky od aplikace. To ze je kus "v aplikaci" a kus v databazi mimo jine znamena, ze se neda rozumne logovat, trasovat, jednotne testovat... Z programatorskeho hlediska je to klasicky side effect se vsemi nevyhodami (a samozrejme i vyhodami, pokud nekdo nejake vidi). Osobne nenavrhuju logiku do triggeru vubec. Nerikam, ze to nema sem tam smysluplna vyuziti, ale napr. ve vicevrstve architekture to podle mne nema co delat.

[Tarmaq]

ja to vidim uplne naopak. Trigger mi umoznuje zaridit, aby se pohled choval jako relace, tj. abych do nej mohl vkladat, upravovat ho a triggery zaridi, aby se data rozsoupala do prislusnych tabulek z kterych se pohled sklada.. Nevim proc bych toto mel zarizovat na strane napr. PHP

[Kit]

Jeden důvod znám: Dotyčný umí PHP lépe než SQL a počítá s tím, že s těmi daty bude pracovat pouze jeho PHP aplikace

[axel]

PHP neumim vubec a SQL umim sice dobre, to ovsem pro psani triggeru moc potreba neni Modifikovat (coz neni totez co "pracovat") data opravdu typicky muze pouze "moje aplikace", respektive jeji k tomu urcena vrstva, respektive specificka vrstva tvorici rozhrani vuci ostatnim systemum. Jinak by se na enterprise urovni nedalo efektivne zamykat, cachovat, nahravat velke objemy dat, detailne ridit opravneni atd. Predstava jakesi chytre databaze, ve ktere se vrta spousta aplikaci, ktere o sobe nevedi, a ona vsechno udrzi konzistenti (ne jen technicky, ale i "byznysove") je trochu sci-fi. Umisteni logiky do databaze prestane cloveka bavit nejpozdeji ve chvili, kdy ma do ni pribyt pouziti messagingu, overeni opravneni ve vzdalenem systemu, volani webservices atd. Pro nektere systemy toto hrozi, pro jine treba nehrozi. Co tvrdim je, ze pokud potrebuju vicevrstvou architekturu (opravdu potrebuju, ne jen ze ji mama rad a pouzivam ji vsude i na miniprojekty), tak tam mam vrstvu aplikacni logiky a ta by se mi nemela prolinat s datovou ve forme triggeru.

[axel]

Triggery nad pohledy jsou specificka zalezitost. Zasadni prinos je urcite pro technologie poskytujici abstrakci nad tabulkami (formular si mysli, ze je nad tabulkou, generuje do ni inserty/updaty a je odstinen od datoveho modelu). Jinak mohu analogicky pouzit napr. stored proceduru nebo proceduru v aplikaci, naprogramovat to musim tak jako tak a v triggeru jsem nejvice omezen co do moznosti. Napriklad nainsertovat pres trigger nad pohledem vetsi objem dat je obvykle velky prusvih.

[Kit]

Obvykle je velký průšvih, pokud se to někdo snaží šmudlit v PHP, některá z operací se nezdaří a my netušíme, která data tam už jsou a která ne.

[axel]

To je nejaka posedlost tim PHP? Ja mam o nem pouze zakladni predstavu a mozna nespravedlive ho nepovazuju za vhodne pro veleke projekty, ale programovat dobre nebo spatne se da snad v zasade ve vsem

[Kit]

PHP v tom může být nevinně. Stačí nějaká chyba ve vstupních datech, které DB odmítne.

[Tomáš]

Mám tu jednu takovou aplikaci. Je v ní přes 2200 triggerů. Každý druhý zapisuje pokoutně do nějaké tabulky a jejich spouštění je jako neřiditelná lavina. Trasování je peklo. Dopadová analýza je inferno na druhou. Nějaké moduly a jasně definovaná rozhraní mezi nimi? Na takový luxus zapomeňte.

Trigger je dobrá věc, ale jen ve specifických případech. Pokud máte aplikaci v rukou ( máte zdrojový kód, který můžete libovolně upravovat ), tak lepší se triggeru vyhnout. Ideálně je pokud se vám podaří udržet data a logiku separátně. S logikou pak můžete v rámci nasazení aplikace výrazně lépe manipulovat než s daty.

[axel]

Presne tak, takovou aplikaci bohuzel take mame. Diky version managementu lze pekne sledovat, jak tyto veci vznikaji nejprve jako nenapadna "rozumna" vypadajici zkratka (zavolam jen insert a ono se mi to spravne doplni do dalsich tabulek) a konci jako bazina plna v zasade globalnich promennych, ktere ridi chovani jednotlivych triggeru podle toho, v jake situaci se zrovna volaji - pri davkove aktualizaci ne, pri aktualizaci z formulare ano, ale jen pokud se nejedna o zmenu rodneho cisla a neni to z pobocky, protoze tam to je cele slozitejsi atd. Nikdo nema jistotu, kdy se mu co zavola, takze do toho radeji nikdo nesaha (testovatelnost je blizka nule) a pro novou funkcionalitu casto vznika nejaka postranni cesticka, ktera to cele obchazi...

[Tarmaq]

Ja jsem ale nerekl, ze taham business logiku do triggeru. Samozrejme tyto popisovane vyhybky tam nepatri. V triggeru pouze zarizuju, aby se data propagovala tam kam maji, protoze to zadny SQL server neumi sam o sobe, z jednoducheho pohledu obsahujiciho par joinu, rozpoznat zaridit. Take netvrdim ze je vhodne, aby ten trigger soupal data nekam uplne jinam. Jen do tabulek, z kterych se sklada view nad kterym je (samozrejme zapis do nejake logovaci tabulky atp. tam byt muze)

Pokud je databaze vhodne navrhnuta, nestava se ze by se clovek podivoval pri chybe co se to deje a musel to nejak slozite analyzovat, pokud je v DB poradek.

Predpokladam ze tabulky v tve databazi obsahuji semtam nejaky nullovatelny sloupec, je to tak?

[axel]

Uvadis pouze triggery nad pohledy, coz je mensinova zalezitost. Nad tabulkami by se to pak tedy analogicky omezilo na jednu tabulku? Pak by tam opravdu prilis slozita logika byt nemohla, nejspis nejaka validace, a nemam s tim vubec problem (ovsem nedelame to tak, predevsim kvuli spatne vykonnosti pri zpracovani vetsiho mnozstvi dat). Jak je databaze navrzena nema vliv na to, zda se pri chybe nekdo "podivuje" a uz vubec na to, zda je chybu treba slozite analyzovat. Ano tabulky v me databazi obsahuji nullovatelne sloupce, souvisi to nejak s triggery?

[Tomáš]

Trigger rozhodně není transakce. Trigger se základním ACID transakčních DB nemá trigger vůbec nic společného. ( Na rozdíl od transakcí, které základem jsou. )

Výkonnost kódu (pro DB orientované aplikace) převážně závisí na tom kolik musí transakce udělat I/O operací s diskem. Rozdíl, zda kód běží v triggeru nebo PL/SQL nebo PHP, je zanedbatelný. Pro představu přístupová doba k datové větě (s lidským měřítkem × 1e9):

1. vylovení věty z cache na CPU = 1 ns ~ v lidském měřítku 1s
2. vylovení věty z paměti DRAM = 65 ns ~ v lidském měřítku 65s ~ 1 min.
3. vylovení věty z pevného disku = 2ms (seek time špičkového disku) ~ v lidském měřítku 23 dní, tady musíme trošku přidat protože disk pracuje blokově a průměr bude výrazně lepší. Takže řekněme 10x lepší číslo. Tedy cca 2 dny.
4. vylovení řádku přes sít z paměti vzdáleného stroje = 0.1 ms ~ lidském měřítku cca 1 den. Tady bychom taky mohli ubrat. Do síťového paketu se vejde taky více jak jeden řádek.

Ale nic si z toho nedělejte, názory jako Váš slyším i od seniorních vývojářů a IT architektů. Prý rozdíl mezi během triggeru a PL/SQL procedury i reálně změřili. A když se zeptám jak eliminovali diskovou cache, tak tou se nikdo nezabýval. Je to občas dost síla.

[j]

Jak tu nekdo zminil, trigger nema s transakci nic spolecnyho, a muze se podelat zcela nezavisle. A co se vykonu tyce, zasadni problem je predevsim v tom, ze trigger se musi vyhodnocovat VZDY pri LIBOVOLNE akci s tabulkou. I kdyz trebas nakonec nic neudela.

Minimalne se databaze musi podivat na typ akce (insert/update) a porovnat, zda na tu akci je trigger povesen. Pokud takovych akci probihaji tisice ... a z toho trebas jen 1% vyzaduje akci triggeru ...