Forum » Programiranje » Struktura podatkovne baze
Struktura podatkovne baze
mobisux9 ::
Zdravo,
rad bi si olajšal vsakodnevno delo s podatki
V podjetju vsak mesec (lahko pa tudi večkrat na mesec) dobimo od dobaviteljev različne podatke o izdelkih (cenike, specifikacije).
Posamezni izdelek lahko dobavljamo od več dobaviteljev. Kljub temu, da vsak dobavitelj pošilja podatke v drugačnem formatu, imajo vsi izdelki nekaj skupnih atributov (recimo ean koda, cena). Sedaj bi želel te podatke spraviti v podatkovno bazo (mysql,postgresql?) in ker gre za različne izdelke bi imel dve tabeli: izdelki (id, naziv, cena, ean koda) in podrobnosti (povezava z izdelki, ključ in vrednost, dobavitelj). Pod ključ in vrednost bi shranjeval npr. teža, št. dni dobave, itd. pač različno, kar od različnih dobaviteljev dobim za različne izdelke.
Zanima me, kako se sicer rešuje take stvari (pod kaj naj sploh googlam?) in kako potem hitro iskati po taki bazi?
rad bi si olajšal vsakodnevno delo s podatki
V podjetju vsak mesec (lahko pa tudi večkrat na mesec) dobimo od dobaviteljev različne podatke o izdelkih (cenike, specifikacije).
Posamezni izdelek lahko dobavljamo od več dobaviteljev. Kljub temu, da vsak dobavitelj pošilja podatke v drugačnem formatu, imajo vsi izdelki nekaj skupnih atributov (recimo ean koda, cena). Sedaj bi želel te podatke spraviti v podatkovno bazo (mysql,postgresql?) in ker gre za različne izdelke bi imel dve tabeli: izdelki (id, naziv, cena, ean koda) in podrobnosti (povezava z izdelki, ključ in vrednost, dobavitelj). Pod ključ in vrednost bi shranjeval npr. teža, št. dni dobave, itd. pač različno, kar od različnih dobaviteljev dobim za različne izdelke.
Zanima me, kako se sicer rešuje take stvari (pod kaj naj sploh googlam?) in kako potem hitro iskati po taki bazi?
prtenjam ::
Pozdravljeni,
Glede na vprašanje sklepam, da niste razvijalec programske opreme (aka programer). Če moja predpostavka drži, potem vam svetujem, da - vsaj na začetku - vodite stvari v Excelu. Tudi Excel lahko smatrate kot neke vrste podatkovno bazo. In ko boste stvari imeli urejene tam potem pa preidite na "podatkovno bazo", s tem da vam vseeno svetujem da pri tem razmislite o kakšnem že narejenem orodju in tega ne razvijate sami... Vse to seveda pod predpostavko, da niste razvijalec.
V kolikor pa ste razvijalec potem pa.... hm ... boste morali prehoditi še dolgo pot ;)
Glede na vprašanje sklepam, da niste razvijalec programske opreme (aka programer). Če moja predpostavka drži, potem vam svetujem, da - vsaj na začetku - vodite stvari v Excelu. Tudi Excel lahko smatrate kot neke vrste podatkovno bazo. In ko boste stvari imeli urejene tam potem pa preidite na "podatkovno bazo", s tem da vam vseeno svetujem da pri tem razmislite o kakšnem že narejenem orodju in tega ne razvijate sami... Vse to seveda pod predpostavko, da niste razvijalec.
V kolikor pa ste razvijalec potem pa.... hm ... boste morali prehoditi še dolgo pot ;)
Matjaž Prtenjak
https://mnet.si
https://mnet.si
Fuks ::
Rabiš 2 tabeli, kot si jih opisal.
Ena možnost, najbolj preprosta:
- v prvi tabeli [Product] nastaviš EAN za primarni ključ
2. V drugi tabeli npr. [SupplierProduct] narediš nek auto increment celoštevilski ključ in postaviš referenco (foreign key) na prvo tabelo.
Potem lahko izvajaš poizvedbe, npr izpis detajlov o izdelku z vsemi možnimi variantami nekako takole:
SELECT * FROM Product p JOIN SupplierProduct sp USING (EAN) WHERE p.EAN = "vpiši_ean"
Dobil boš stik tabel pri tej vrednosti EAN-a. Npr da imaš izdelek pri treh dobaviteljih, boš dobil vse stolpce tabele Product v vsaki vrstici (enake) ter v vsaki vrstici različne podatke glede na dobavitelja.
Seveda lahko izvajaš tudi druge poizvedbe... to je samo primer. Nadalje bi potem še dobavitelja dal v svojo tabela, da nebi njegovo ime vseskozi podvajal itd.
Sedaj boš mogoče lahko bolj konkretno zastavil vprašanje ;)
Ena možnost, najbolj preprosta:
- v prvi tabeli [Product] nastaviš EAN za primarni ključ
2. V drugi tabeli npr. [SupplierProduct] narediš nek auto increment celoštevilski ključ in postaviš referenco (foreign key) na prvo tabelo.
Potem lahko izvajaš poizvedbe, npr izpis detajlov o izdelku z vsemi možnimi variantami nekako takole:
SELECT * FROM Product p JOIN SupplierProduct sp USING (EAN) WHERE p.EAN = "vpiši_ean"
Dobil boš stik tabel pri tej vrednosti EAN-a. Npr da imaš izdelek pri treh dobaviteljih, boš dobil vse stolpce tabele Product v vsaki vrstici (enake) ter v vsaki vrstici različne podatke glede na dobavitelja.
Seveda lahko izvajaš tudi druge poizvedbe... to je samo primer. Nadalje bi potem še dobavitelja dal v svojo tabela, da nebi njegovo ime vseskozi podvajal itd.
Sedaj boš mogoče lahko bolj konkretno zastavil vprašanje ;)
sebastjan28 ::
Mislim, da bo za začetek najboljše opravil svoje MS access. Seveda to ni rešitev za večjo količino podatko, ki bi jih bo urejalo večje število ljudi, vendar za osebno uporabo in učenje je to najlažji začetek.
Osebno bi si tudi prebral kaj na temo osnov SQL in normalizacije podatkov,...
Osebno bi si tudi prebral kaj na temo osnov SQL in normalizacije podatkov,...
videc ::
Ms Access ali kakšna podobna alternativa bi bila najboljše za to.
Seveda pod pogojem, da imate licenco za Access. :)
Če bo ostala zadeva majhna, se pa da lepo rešiti tudi z Excelom.
Seveda pod pogojem, da imate licenco za Access. :)
Če bo ostala zadeva majhna, se pa da lepo rešiti tudi z Excelom.
DaMachk ::
Na voljo je še vedno tudi Base iz OpenOffice.org ali pa LibreOffice družine, ki je brezplačen.
No signiature, as you see..
videc ::
Ales ::
In zakaj te moti, če nekdo poimensko navede alternativo? Saj točno po tem sprašuje OP.
Sicer pa takole - za informacijski sistem podjetja je najbolje zadevo od začetka zastaviti tako, da bo ustrezala vsem potrebam in da bo v prihodnosti omogočala nadgradnje, vzdrževanje, itd.. Menjati npr. bazo podatkov oz. njen vmesnik v utečenem podjetju ni mačji kašelj, običajno ni poceni in je kar udarec na delovne procese.
Sam osebno bi najprej razmislil o vseh zahtevah, ki naj bi jih vmesnik za dostop do podatkov v bazi izpolnjeval, z ozirom na delovne procese v podjetju. Potem bi najbrž izbral kak python framework in naredil interno spletno aplikacijo, ki bi tem zahtevam ustrezala. Sam tip baze za tako relativno majhno (sklepam?) količino podatkov niti ni poglaviten, za začetek je lahko kar SQLite, sicer pa postgreSQL.
Sicer pa takole - za informacijski sistem podjetja je najbolje zadevo od začetka zastaviti tako, da bo ustrezala vsem potrebam in da bo v prihodnosti omogočala nadgradnje, vzdrževanje, itd.. Menjati npr. bazo podatkov oz. njen vmesnik v utečenem podjetju ni mačji kašelj, običajno ni poceni in je kar udarec na delovne procese.
Sam osebno bi najprej razmislil o vseh zahtevah, ki naj bi jih vmesnik za dostop do podatkov v bazi izpolnjeval, z ozirom na delovne procese v podjetju. Potem bi najbrž izbral kak python framework in naredil interno spletno aplikacijo, ki bi tem zahtevam ustrezala. Sam tip baze za tako relativno majhno (sklepam?) količino podatkov niti ni poglaviten, za začetek je lahko kar SQLite, sicer pa postgreSQL.
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Barcode scannerOddelek: Elektrotehnika in elektronika | 1463 (1179) | Vanquish |
| » | MS Access (strani: 1 2 )Oddelek: Programiranje | 7410 (5468) | travica |
| » | Iskalnik za cene živil?Oddelek: Izdelava spletišč | 3994 (3535) | Saladin |
| » | Kaj je to UPC/EAN CodeOddelek: Pomoč in nasveti | 3386 (3039) | No Can Do |
| » | Cene trgovcev v realnem času (strani: 1 2 )Oddelek: Loža | 31823 (29213) | fosil |