| Autor | Zpráva | ||
|---|---|---|---|
| Andrej.B Profil |
#1 · Zasláno: 24. 10. 2018, 21:07:34
Zdravim,
pri navrhovani struktury DB pre prijem na sklad mam vytvorenu tabulku SKLAD_POLOZKA kde mam tieto stlpce: id_sklad_polozka id_material datum_sklad_polozka mnozstvo_polozka Prijmem si material /id_material = 1/, ktory ma 1000 metrov V dalsej tabulke mam BALIK kde mam tieto stlpce: id_balik id_material datum_balik mnozstvo_balik Odvediem balik, ktory ma id_material = 1, ktory ma 400 metrov... Konecny stav na sklade id_material 1 = 600 metrov ... klasika lahke. Ako to riesit neskor pri zmene roku. v datumoch pouzivam TIMESTAMP. Pride januar 2019, prijmem na sklad znova id_material 1 - 5000 metrov, odvediem 2 baliky kazdy po 400m. Zostatok na sklade: 1000(prijem2018)-400(balik2018)+5000(prijem2019)-400(balik 2019)-400(balik 2019) = 4800 metrov. Pri mnozstve balikov z vyroby cca 200k/ rok, by musel zostatky riesit spocitanim vsetkch odvedenych balikov za posledne roky. Nieje to zbytocne zatazenie na DB? Logika mi skor hovori aby som si na konci roka urobil inventuru a od januara zacinal od zaciatku s tym, ze by som si prijal znova na sklad zostatky z roku 2018. Ako sa to riesi vo vseobecnosti? Ako pisem aj v predchadzajucom dotaze Automaticke zistenie hodnot tabulky /bezpecnost/ bojim sa toho, ze niekde urobim nejaku logicku chybu pri navrhu a budem to musiet prerabat... v Selectoch pouzivam na odlisenie rokov takyto postup, kde premenna $rok = date('Y'); WHERE datum_sklad_polozka
BETWEEN
UNIX_TIMESTAMP('$rok/01/01')
AND
UNIX_TIMESTAMP('$rok/12/31 23:59:59')dik za pomoc |
||
| Keeehi Profil |
#2 · Zasláno: 24. 10. 2018, 21:27:19
Andrej.B:
Základ bych viděl v tom, že hodnotu v mnozstvo_polozka při vytvoření balíku upravíš. Tudíž tam nebudeš mít stále 1000 ale pak i 600. Kolik toho máš na skladu pak zjistíš jednoduše jako SELECT SUM(*) FROM SKLAD_POLOZKA WHERE id_material = 1; Odčítat od toho balíky už nebudeš muset protože to už jsi vlastně udělal když jsi updatoval hodnotu při vytvoření balíku.
|
||
| Andrej.B Profil |
#3 · Zasláno: 24. 10. 2018, 22:29:21
ale potom nezistim kolko som prijal v minulosti, kedze tam budem mat uz odcitane polozky z balikov.
|
||
| Keeehi Profil |
#4 · Zasláno: 25. 10. 2018, 00:38:37
Andrej.B:
Na to si udělej zvláštní tabulku. Tabulka sklad by měla sémanticky reflektovat aktuální stav skladu. Když chceš vědět historii příjmů, udělej si tabulku prijem. |
||
| Joker Profil |
#5 · Zasláno: 25. 10. 2018, 09:52:56
Zatížení databáze by nemuselo být takové drama, jsou to jen číselné operace.
Navíc omezené na rok, takže ani růst databáze by nemusel být takový problém. Ale kdyby to bylo pomalé, možná by stačilo přidat sloupec s významem „zbývající množství“. Zároveň by to přineslo i novou informaci: Z evidence podle [#1] nutně nevyplývá informace které balíky jsou už spotřebované. Například pokud bylo přijato 1000 a 5000 a vydáno 400, 400 a 400, může zbývat buď jeden balík a v něm 4800, nebo dva balíky, v jednom 1-1000 a ve druhém 4801-3800. |
||
| Andrej.B Profil |
#6 · Zasláno: 25. 10. 2018, 10:26:05
Keeehi [#4]:
to je presne to, co neviem, co je spravne... tabulka SKLAD_POLOZKA je vlastne prijem podla toho ako material chodi od dodavatela... a potom mam tabulkui BALIK kde su spotrebovane mnozstva... cize by som mal mat dalsiu tabulku SKLAD_ODPOCET, kde by som priratal vsetko co ide do SKLAD_POLOZKA a potom pri odvedeni vyroby by som len dal - metre co su v baliku? tak nejako? Joker [#5]: možná by stačilo přidat sloupec s významem „zbývající množství“. - to vypada super, mohol by som to vyuzit, v spatnej dohladatelnosti a lotiek by to zprehladnilo tok materialu vo vyrobe... Diky zatial |
||
| Keeehi Profil |
#7 · Zasláno: 25. 10. 2018, 11:44:41
Andrej.B:
„tabulka SKLAD_POLOZKA je vlastne prijem“ Pak by se měla jmenovat příjem a ne sklad. Správné pojmenování velmi pomáhá porozumění celého problému. Doporučil bych si sednout a veškeré entity které máji být v projektu si namodelovat na papír. Napsat si k nim vztahy, omezení atp. No a na závěr si projít veškeré scénáře které mohou nastat (hlavně ty neobvyklé, např. že se něco naskladní ale bude se to třeba muset vrátit dodavateli) a ověřit, že model je vše schopen vyjádřit. Určitě tam najdeš spoustu míst které budou špatně, protože tě to při prvotním návrhu nenapadlo. Tak to opravíš a zkusíš to znovu. Tím by jsi měl vygenerovat dostatečně dobré řešení. To se určitě v průběhu tvorby projektu bude měnit protože na papíře nikdy nepřijdeš na všechny nedostatky ale mít solidní základ rozhodně pomůže. A nakonec, o výkon databáze se neboj. Když ti z toho vxjde třeba sto tabulek, tak to pro ně vůbec nic neznamená. Jejich limity jsou řádově větší. |
||
| Andrej.B Profil |
#8 · Zasláno: 25. 10. 2018, 18:45:53
praveze som nad tym sedel dost dlho :) Vsetko co sa tyka skladu je sklad_ ... ale urcite mohlo byt lepsie, inak by som nepisal... A mat 100 tabuliek je moc, moj limit na rozdiel od databazy nieje radove vyssi ale nizsi :)
Diky, dam to asi odznova radsej... |
||
| Keeehi Profil |
#9 · Zasláno: 26. 10. 2018, 00:01:16
Andrej.B:
Tu stovku jsem naschvál lehce přestřelil, aby jsi se nebál. Je mi jasné že tvůj projekt se bude nejspíš pohybovat někde okolo deseti, dvaceti. Je totiž důležité aby jsi se nebál a nechtěl to všechno nějak mačkat do jedné či několika málo tabulek. Bývá to častá chyba začátečníků, že se bojí že to bude moc tabulek a nebo dat a tak vymýšlejí různé pseudooptimalizace aby vyřešili problém který vůbec neexistuje. Jinak obecně 100 tabulek není nic nereálného, pracoval jsem ve startupu který vytvářel eshopy a k těm 100 tabulkám jsme se pomalu blížili. Teď dělám v korporátu a těch tabulek jsou tisíce v různých databázích. Samozřejmě ta serverová farma na které to běží není žádné tintítko ale to není podstatné. Co jsem tím chtěl říci je to, že existují i mnohem rozsáhlejší projekty a případně i s těmi si databáze zvládnou poradit. |
||
| Andrej.B Profil |
#10 · Zasláno: 26. 10. 2018, 05:25:53
Mnozstvo tabuliek znamena aj mnozstvo roznych selectov, ktore az tak neovladam.... Vid par dni dozadu Join... Zacal som s tym prednedavnom len pre jednoduche odvadzanie vyroby, nakolko excel uz z roznych pricin nevyhovoval a zacalo sa na to nabalovat a nabalovat... Urcite som tu nie naposledy ... Diky
|
||
| Joker Profil |
#11 · Zasláno: 26. 10. 2018, 11:06:07
Keeehi:
„Tu stovku jsem naschvál lehce přestřelil, aby jsi se nebál.“ Dal jsem si vypsat všechny tabulky z databáze největšího projektu na kterém dělám a je jich asi 1500 (plus nějaké experimentální) :-) Ovšem nejde o to mít tabulek co nejvíc nebo co nejméně, ale „tak akorát“ vzhledem k jejich obsahu. (Přehnaný rozpad do mnoha tabulek vede ke složitým a potenciálně pomalým dotazům. Přehnané sdružování dat vede k tomu, že v databázi jsou uložené informace na které se prakticky nelze dotázat, nebo dokonce některé stavy systému databáze nedokáže vůbec reprezentovat. Z toho i vyplývá, že je o něco lepší přehnaný rozpad než přehnané sdružování, protože to, že dotaz je náročné sestavit a jeho provedení dlouho trvá, se pořád řeší lépe, než že dotaz sestavit vůbec nejde.) |
||
|
Časová prodleva: 5 let
|
|||
0