Přidat otázku mezi oblíbenéZasílat nové odpovědi e-mailem 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...

Odpověď na otázku

1 Zadajte svou přezdívku:
2 Napište svou odpověď:
3 Pokud chcete dostat ban, zadejte libovolný text:

Zpět do poradny