Navrh databazy
Ahoj,
potreboval by som poradit ohladom navrhu sql databazy.
Ide o obchod, doteraz sa tam pouziva suborova databaza. V principe je terajsia struktura rozdelena na hlavicky a obsah. Kazdy subor s hlavickami ma nadvazujuci subor s obsahom. Napr. Hlavicky_prijmov - obsah(polozky) prijmu, Hlavicky_vydajov_na_odberny_list - polozky atd. Takychto dvojic je asi 5. Subory z obsahmi pre vydaj maju takmer rovnaku strukturu. Dalej je tam subor so skladom a dalsie subory s ciselnikmi. Kedysi som zacinal s DBF, takze podobne rozlozenie mi pride take celkom logicke.
Toto by som potreboval preklopit do SQL. Nemusim dodrzat povodnu strukturu, do noveho systemu pojdu len ciselniky. Poziadavky na tej prevadzke su velmi specificke, tovar sa musi sledovat od prijmu az po vydaj, obrazne jogurt ABC s nejakym datumom vyroby moze mat inu predajnu cenu ako rovnaky jogurt ABC s inym datumom vyroby. Tovar sa tiez pouziva na vyrobu ineho tovaru (zo salamy a majonezy spravia salat). Tovar sa vydava na poukazky, kde zakaznik hradi len urcitu cast z ceny (zvysok hradi sponzor) a zaroven si moze zakaznik kupit ten isty tovar na rovnaky pokladnicny blok aj za plnu cenu. Poukazky aj s presnym rozpisom sa fakturuju sponzorovi (rozdiel co zakaznik nezaplatil). Nieco sa vydava na odberne listy a tie sa tiez potom hromadne fakturuju. Niektori zakaznici maju bonusove karty na ktore si zbieraju body a potom dostanu zlavu z ceny atd., atd.
Precital som si nieco o normalizacii databaz. Vychadza mi to ale, ze keby sa to malo vsetko navrhnut podla noriem, bolo by to neskutocne zlozite, neprehladne a rozbite na desiatky tabuliek. Preferujem jednoduchost a prehladnost aj za cenu nedodrzania noriem.
Moje prve uvahy smeruju k tomu, ze by sa vytvorili len dve tabulky pre obsah. Jedna pre prijem, ktora by obsahovala aj zostavajuci pocet kusov a aktualnu predajnu cenu, druha pre vydaj. Z tabulky pre vydaj by odkazovali cudzie kluce do hlaviciek vsetkych druhov vydajov (samostatne tabulky).
Takze prvy nastrel si predstavujem nejako takto:
Tabulka OBSAH_PRIJEM (obsahprijem_id, tovar_id, datum_vyroby, nakupna_cena, mnozstvo, aktualna_predajna_cena, zostatok_na_sklade, prijem_id)
Tabulka PRIJEM (prijem_id, dodavatel_id a dalsie specificke veci pre hlavicku prijmu...)
Tabulka OBSAH_VYDAJ (obsahvydaj_id, typ_vydaja, mnozstvo, cena_predajna, cena_sponzor, cena_zakaznik, obsahprijem_id, poukazka_id, odberny_list_id, spotrebaNaVyrobu_id, pokladn_doklad_id)
typ_vydaja potom moze nadobudat hodnoty [poukazka,odbernyList,beznyPredaj,spotrebaNaVyrobu ,....]
Tabulka POUKAZKA (poukazka_id, ...dalsie specificke veci pre poukazku...)
Tabulka ODBERNY_LIST(odberny_list_id, ...dalsie specificke veci pre odberny list...)
Tabulka SPOTREBA_NA_VYROBU(spotrebaNaVyrobu_id, ...dalsie specificke veci pre spotrebu na vyrobu...)
Tabulka POKLADN_DOKLAD(pokladn_doklad_id, ...dalsie specificke veci pre pokladnicny doklad...)
Napr.ak by riadok v OBSAH_VYDAJ mal typ vydaja hodnotu povedzme 'odberny list', tak by odberny_list_id odkazoval na prislusnu hlavicku a dalsie cudzie kluce by boli null. Ak by v OBSAH_VYDAJ mal typ vydaja hodnotu 'poukazka', tak by poukazka_id a pokladn_doklad_id odkazovali na prislusne hlavicky a zvysne cudzie kluce by opat boli null.
Hned ma ale napada prvy problem. Stava sa, ze sa pri prijme pomylia, dojde nespravny tovar atd. a chcu ho nasledne vymazat. Ak by som do OBSAH_VYDAJ pridal riadok s predajom tovaru a nasledne dalsi riadok ako storno, aj tak by nebolo mozne vymazat polozku z OBSAH_PRIJEM, kedze uz by na nu dva krat odkazoval cudzi kluc z OBSAH_VYDAJ.
Diky ak ste to docitali az sem, napisete na co si dat pozor, co urobit radsej inak a tiez ako...
pokud sis četl o normalizaci, tak jsi jistě narazil na její tři stupně. A taky na to, že normalizace není dogma, ale doporučení.
Z mého pohledu bych se např. zamyslel, zda je nutné mít tabulky řádků na každou operaci (příjem/výdej/prodej/atd.), když to je přece vlastnost tabulky hlavičky - ergo jsi neprovedl správně normalizaci. Z toho ti pak vypadne, že hlavičková tabulka bude mít pole "operace" a na řádcích spojených s určitým záznamem z hlavičkové tabulky už nic takového nepotřebuješ.
Dále, pokud aspiruješ na nějaký systém "skladů", tak bys podle toho měl ty sklady i vytvořit, tj. mít další datové struktury popisující sklad a náležitě každou operaci se skladem zpracovat, kontrolovat (např. kladné množství) a i dokladovat (archiv stavu skladů k určitému datu). Obecně sklad se musí pojmout stylem: "operace počáteční stav" - "operace příjem" (+ sklad) - "operace výdej" (- sklad)
edit: a ještě vidím cenové operace (tj. cenotvorba) - tam opět musíš uvážit, jak postavit data tak, abys byl schopen kdykoli rekonstruovat ceny v dané době. Já bych to třeba řešil časově platnými ceníky pro různé cenové úrovně. Struktura dat je ale závoslá na tom, zda se přeceňují položky v čase postupně, nebo celý sortiment najednou.
edit2: pokladní doklady jsou další "okruh", který bys měl řešit separátně, a to jako "pokladnu".. no z toho mi vychází už malé ERP, ještě přidat CRM modul
...vypadne, že hlavičková tabulka bude mít pole "operace" a na řádcích spojených s určitým záznamem z hlavičkové tabulky už nic takového nepotřebuješ....
To je pravda ak sa spravne rozumieme. Ale potom by som potreboval aj tak dalsie samostatne tabulky v ktorych by boli len specificke veci. Pretoze ak si kupis jogurt na poukazku tak sa tam este do tej poukazky zadava kolko hradi sponzor a kolko plati zakaznik, plus dalsich 5-6 veci, ktore sa vyskytuju len na poukazke a nikde inde. Jedna poukazka moze byt na viac kusov rozneho tovaru. Teda som tym chcel povedat, ze tie specificke veci by boli v hlavickach.
Mozes hodit nejaky priklad ako by si to rozdelil ty?
...a ještě vidím cenové operace (tj. cenotvorba) - tam opět musíš uvážit, jak postavit data tak, abys byl schopen kdykoli rekonstruovat ceny v dané době...
To je problem, ceny asi budem zapisovat priamo. Teoreticky kazdy jeden fyzicky kus moze mat roznu cenu, v praxi ale ma kazda polozka prijmu svoju vlastnu cenu (napr. Jogurt ABC s vyrobnym datumom vcera ma inu cenu ako ten isty jogurt vyrobeny dnes, eviduje sa vyrobna sarza co je zjednodusene datum vyroby). A tiez je mozne kupit ten isty jogurt od roznych dodavatelov za rozne ceny. A ja potrebujem mat evidenciu az po ten datum vyroby (vyrobnu sarzu)+dodavatela. V praxi na regali sa to miesa, ale s tym ja uz nic nespravim, aspon teoreticky to musi v PC sediet.
...no z toho mi vychází už malé ERP, ještě přidat CRM modul
...
Toho sa prave bojim. Nechcel by som z toho vyrobit nejaku obrovsku vec.
Inak diky za nazor a rady!
ad problém tabulek - nepotřebuješ. Můžeš přece všechna potřebná pole nadefinovat "napříč" jednou tabulkou, pro operace, kde nebudou potřeba, jednoduše nebudou vyplněna.
ad ceny - právě proto bys měl zavést sklady s nějakou "frontou" přijatých výrobků a cen, plus nějaký systém zpracování fronty, buď LIFO (zásobník) nebo spíše FIFO (fronta). Pak budeš moci ceny řešit algoritmicky, na základě nákupní ceny.
buď tvoříš funkční (a efektivní) systém, který reflektuje nějaký proces, nebo stvoříš polofunkční bastl, jehož přínos bude skoro čistá nula...
...Můžeš přece všechna potřebná pole nadefinovat "napříč" jednou tabulkou...
Uff, vela veci by sa skutocne takymto navrhom zjednodusilo. Ale ked to tak od oka odhadnem, bolo by to nejakych 30-40 stlpcov. Myslis, ze to nebude vadit pri vykone a tiez pri objeme dat (fyzicky velkost db)? Neviem ci null zabera menej miesta ako zadana hodnota.
ad sklady - vedel by si ma nakopnut ako si to predstavujes vo vazbe na prijem a vydaj? Nejaky mini vzor.
Lebo ja zatial uvazujem o tom ako som pisal na zaciatku, vyuzit obsah prijmu zaroven na sklad.
OBSAH_PRIJEM (obsahprijem_id, tovar_id, datum_vyroby, nakupna_cena, prijate_mnozstvo, aktualna_predajna_cena, zostatok_na_sklade,...). Doteraz sa nejaka extra evidencia cien nerobila, ked sa nieco precenilo nebol o tom ziadny zaznam (teda bol vo vydajoch, ak sa to medzi jednotlivymi preceneniami aj predalo).
Ale rad sa necham poucit ako to spravit lepsie.
Diky!
Podle toho kde a v jaké databázi. Základní pravidlo zní, že sloupce, kde je velká pravděpodobnost mají být na konci. Navím jakou uvažuješ databázi, ale třebas NULL v posledních sloupcích tabulky na Oracle nezabírá nic. Uprostřed to zabírá overhead na separaci sloupcu + znak null.
Bude to pre MS SQL. Trochu som googlil a udajne null nezabera skoro nic pre varchar, avsak vraj zabera plnu dlzku pre datove typy pevnej dlzky ako string[10] alebo int.
Dakujem vsetkym za reakcie a rady.
P.S. neviete co sa stalo s diskusiou databazy na builder.cz? Uz dlhsie som tam nebol a nejako to tam uz nezije...