par pitanja oko baze...

Pravim neku aplikaciju za vodjenje preduzeca pa me zanima:

1) Da li je lose raditi sa Access bazom? Da radim sa SQLom?
vec sam poceo da radim sa Accessom posto sa njim imam najvise iskustva i radi bez servera... (napominjem da baza treba da ima oko 100 000 komada robe... stotine kalkulacija koje se pamte + svasta.. :)

2) Koliko ce trajati filtriranje access baze od 100 000 unosa SQL upitom?

3) Kad pravim kalkulaciju (unosi se koja je sve roba kupjena i po kojim cenama) kako ovo najbolje snimiti? Kako dizajnirati tabelu za ovako nesto?

Unapred veoma zahvalan....

Potpis

And don't be mad at me for crying for humanity,
call it pretensions but I got good intentions,
to keep my sanity, I'm hoping, fuck, there's gotta be
an answer to their strategies and their evil inventions... ~Looptroop

1. Ja bih ti u svakom slučaju predložio neku drugu bazu podataka (MSSQL ili MySQL).

Potpis

"I'd take the awe of understanding over the awe of ignorance any day."
- Douglas Adams

zasto?

Potpis

And don't be mad at me for crying for humanity,
call it pretensions but I got good intentions,
to keep my sanity, I'm hoping, fuck, there's gotta be
an answer to their strategies and their evil inventions... ~Looptroop

Zato što je ACCESS krš od baze podataka, pogotovo kad se radi o ozbiljnoj primjeni sa mnogo zapisa, raznim proračunima nad kolonama i sl. Ja sam npr. radio program koji je nad nekoliko polja računao ROUND(kolona, 2). U Access 2000 na Win98/ME program radi, a na novijem Access-u, na WinXP funkcija ROUND je nepoznata(!). SQL sintaksa ACCESS-a je daleko od svakog standarda. Ko zna na kakve poteškoće možeš naići. A kada već uradiš pola programa, kasno je vraćati se na početak.

Potpis

"I'd take the awe of understanding over the awe of ignorance any day."
- Douglas Adams

Ne koristim access ali slusam komentare.

Uglavnom su da je neozbiljno, a sada se recimo pojavio MSDE, free varijanta MSSQL baze, s nekim ogranicenjima, ali za manji broj korisnika dovoljno.

Neki se zale na racunicu, recimo u aplikaciji za menjacnice.

Neefikasno cuvanje podataka, uvuces jednu recimo DBF tabelu od 100 K (klasican primer neracionalnog koriscenja prostora) i ocekujes da ce se access baza prosiriti manje od toga, pa se iznenedis koliko se prosiri.

Potpis

Pomozite Micro$oftu u borbi protiv piraterije, poklonite prijatelju Linux

OK, odlucio sam se za MySQL...
10ak sati rada i prebacicu se na SQL :) nadam se da nece biti problema...
Jel OK da baze radim u MySQL Administratoru i MySQL query Browseru? Ako ne preporucite neki editor...

Hvala...

Potpis

And don't be mad at me for crying for humanity,
call it pretensions but I got good intentions,
to keep my sanity, I'm hoping, fuck, there's gotta be
an answer to their strategies and their evil inventions... ~Looptroop

Ja koristim phpMyAdmin za administraciju baza podataka. Za to ti treba Web Server sa podrškom za PHP. Ima sve što je potrebno. Davno sam koristio MySQL Administrator (ili tako nešto) pa nisam bio zadovoljan Unicode podrškom.

Potpis

"I'd take the awe of understanding over the awe of ignorance any day."
- Douglas Adams

Ja nisam uspeo da napravim naša slova u vezi Access <-> MySql

Funkcija ROUND postoji i meni radi savršeno tačno

Pitao jednog dana neko nesto ovako:
'Hocu da se po Nemackoj i Italiji vozim drumovima. sta da kupim, Mercedes ili Toyotu?'

A onda mu odgovorili: 'Kupi Mercedes, Toyota je krs od kola i nije dobra za preko 2,000,000 km godisnje. A modeli od pre 2003 su imali dugme za duga svetla, a vidis 2003 model nema dugme za duga svetla' A onda neko kaze 'kako nema, ima duga svetla, evo ja sam uspeo..' i tako dalje.

Da li ce ti biti dobar Access ili MS SQL ili MySQL zavisi od mnogo stvari. Koliko ces korisnika da imas, koliko ce njih da radi u istom trenutku, sta ce to oni da rade, koliko su blizu ili daleko jedni od drugih, kakve ce to kalkulacije da rade (i da li su te kalkulacije uopste potrebne, mozda ima neki bolji nacin). Najmanje je vazno to sto ces imati 100,000 vrsta robe. (Kalkulacije koje se pamte, srecno ti bilo s tim :-)

Sve to mi iz covekovog pitanja ne mozemo da zakljucimo. Nema veze, zato znamo sta je djubre a sta ne, je li tako?

ok, update pitanja:

1) 100 000 artikala
2) 5-6 korisnika stalno konektovano i rade standardne operacije inserta, deleta i update-a unosa...
eto... :)

niko mi nije odgovorio kako da dizajniram bazu? Mislio sam da to mozda izgleda ovako

BR DOKUMENTA: ARTIKAL: CENA: ...
1 ARTIKAL1 300
1 ARTIKAL2 500
1 ARTIKAL3 600
2 ARTIKAL1 300
2 ARTIKAL2 100

i tako dalje i onda kad zelim da prikazem dokument 1 isfiltriram...
e sad ne znam da li ce biti problem da imam niz od 1000-2000 dokumenata sa po 100 artikala?

Potpis

And don't be mad at me for crying for humanity,
call it pretensions but I got good intentions,
to keep my sanity, I'm hoping, fuck, there's gotta be
an answer to their strategies and their evil inventions... ~Looptroop

Za MS SQL (MSDN) i Access 100,000 redova u jednoj tabeli nije problem. Ni 5-6 korisnuka koji jednovremeno "rade standardne operacije inserta, deleta i update-a unosa" nije problem. Naravno ako su tabele koliko toliko normalizovane i cela aplikacije je uradjena koliko toliko pristojno. Verovatno nije problem ni za MySQL niti bilo sta drugo. Naravno da sveka varijanta moze da se uradi tako da jedva radi ili ne radi nikako. Ali to ne znaci da je bilo koji od ovih sistema 'krs koji ne radi'. samo znaci da u nekom od njih rumemo da adimo bolje nego u nekom drugom.

Tri kolone koje si nam prikazao od tabele deluju OK. Samo, ne verujem da ce ti baza ostati na jednoj tabeli sa tri kolone .. :-)

A kako ces da dizajniras bazu - to zavis od toga sta ces da radis. Malo si nam rekao da bi iko imao ideju. I da znas, meni je supermoderator brisao teme kad bi mu se ucinilo da trazim da mi neko uradi domaci zadatak ili da uradi posao za mene.
;-)

naravno bice mnogo vise od 3 kolone (30ak)...
Ne vidim zasto bi ovo svrstao u kategoriju pitanja 'domaci zadatak' pitam za savet jer aplikacija treba da radi perfektno, a ja nemam iskustva :)

inace jos par informacija o aplikaciji:

Pored evidencije o poslovnim partnerima i sifarnika robe aplikacija treba da pamti sve dokumente unosa robe u magacine i iznosa iz istih (kalkulacije, fakture,...) e tu tabelu ne znam kako da dizajniram. Da li moze neko da predlozi neku alternativu mom predlogu ?

Potpis

And don't be mad at me for crying for humanity,
call it pretensions but I got good intentions,
to keep my sanity, I'm hoping, fuck, there's gotta be
an answer to their strategies and their evil inventions... ~Looptroop

Ako tabela ima 30ak kolona onda je kandidat za normalizaciju.

Potpis

All beer is good. Some beer is better.

Koliko vidim treba da re radi robno knjigovodstvo. Bez obzira sta mislimo o accessu mnogi su to uradili pa ces i ti. Pogledaj deo gde se objasnjava master/detail relacija (ili kako se vec u access terminologiji zove). Prvo napravis sifarnike, maticne podatke. Onda tabele gde ces da cuvas promene. Mada bi moglo da se napravi sa dve tabele gde postoji i sifra promene (ulaz, kalkulacija, faktura, nivelacija), ali ako pocinjes sa ovim onda kreni jedno po jedno jer sada ne vidis celinu svega toga. A i lakse je dodavati kad se pojavi nesto novo.

Potpis

Pomozite Micro$oftu u borbi protiv piraterije, poklonite prijatelju Linux

Presao sam na MySQL...
koliko je lose resenje da za svaku fakturu/kalkulaciju pravim novi table u bazi?
zar ne moze nekako da se napravi table of tables kao 3d baza podataka?

Potpis

And don't be mad at me for crying for humanity,
call it pretensions but I got good intentions,
to keep my sanity, I'm hoping, fuck, there's gotta be
an answer to their strategies and their evil inventions... ~Looptroop

Mnogo je loše. To se ne radi tako. Pogledaj Northwind ili bilo koji primer baze pre nego što počneš svoju da praviš.

Ja glasam za Firebird. Ima stvari koje MySql nema, a radi odlično.
Želio sam u stvari dodati komentar o Access-u. Nas koji smo malo stariji, iz doba Dbase III, Access me najviše podsječa na to. Možeš u njemu napraviti sve, ali ipak za ozbiljniji posao koristiš nešto drugo.

Ovo je jos gore od domaceg zadatka :-) Radis profesionalni posao, a ne umes da ga uradis, pa hoces da ti mi uradimo. Tu nema nista lose, samo sto niko nema vremena za to, pogotovo besplatno. Bolje je da nadjes nekoga da poradi ozbilnjije na tome, inace ces se uvaliti u veelike probleme. Tvoja ideja da kreiras novu tabelu u bazi za svaki novi racun govori da ne znas i ne razumes mnogo vise od toga koju bazu da izaberes. To sto ne znas ne moze da se nauci za neko kratko vreme (analiza sistema, dizajn baze, programiranje aplikacije, testiranje, plan implementacije, odrzavanje, dokumentovanje).

Mani se corava posla, ili kupite gotov sistem, lepo neko rece toga ima koliko hoces, ili platite posteno nekoga ko zna da vam to uradi. Zreanjanin nije malo mesto i siguran sam da cete nekoga naci.

Pozdrav i srecno,

:-)

Ja nisam trazio da mi neko uradi posao, pitao sam za savet, koji sam dobio...
Ne razumem zasto se ljudi kao ti uopste javljaju na forumu... Forum i sluzi za to da se nesto pita / potrazi savet / sazna / nadje resenje /...
Pljuvanje i omalovazavanje necijeg rada ili ruganje manjku necijeg iskustva ni cemu ne vodi...
Ne znam kako bih mogao da imam puno vise iskustva sa 18 godina, niti vidim kako si ti tvoje iskustvo (predpostavljajuci da ga imas) stekao ako nikog nikad nisi nista pitao...

Takodje ne znam o kakvim velikim problemima pricas... Ja ovu aplikaciju razvijam samoinicijativno, ako je odradim dobro (ne ocekujem da to bude slucaj u prvoj verziji), mozda cu je nekom i prodati... Ne vidim gde tu moze da nastane problem...

P.S. Zrenjanin je manji nego sto mislis...

Potpis

And don't be mad at me for crying for humanity,
call it pretensions but I got good intentions,
to keep my sanity, I'm hoping, fuck, there's gotta be
an answer to their strategies and their evil inventions... ~Looptroop

Ako stvarno mislis da napraviš komercijalnu aplikaciju predlažem da prvo pročitaš "malo" više literature o robno-materijalnom knjigovodstvu, pa onda bi znao "malo" više o 3-30 kolona...

Svaka kalkulacija (externi ulaz) treba da sadrži u zaglavlju:
- broj dokumenta po kojem je primljena roba (prijemnica - faktura/račun/otpremnica dobavljača...)
- datum prijema robe
- broj dokumenta - kalkulacije
- datum kalkulisanja
- komitenta (dobavljač robe - iz šifarnika komitenata)
- zavisne troškove (transport...)
- ukupan nabavni iznos
- ukupan iznos input PDV-a
- ukupna input PDV osnovica
- ukupan iznos output PDV-a
- ukupna output PDV osnovica
- Ukupna marža
- ukupan prodajni iznos
u detaljima kalkulacije (preporučujem čitanje knjige sa master/details odnosom tabela):
- redni broj unešene stavke
- grupu artikla (iz šifarnika grupa - odeljenje/magacin/tip/proizvođač...)
- šifru artikla (iz šifarnika artikla - kako bi posle povezao Lager listu/karticu robe...)
- naziv artikla
- količinu artikla
- jedinicu mere artikla
- fakturnu Cenu
- rabat (odobreni popust pri nabavci robe)
- nabavnu Cenu (F.Cena - Rabat%)
- input PDV stopa (%)
- input poreska osnovica (Fakturna cena + Input PDV stopa * Kolicina)
- marža (razlika u ceni)
- output PDV stopa (%)
- prodajna cena
- SUMe: fakturna vrednost / nabavna vrednost / I/O PDV / marža / prodajna vrednost

Ukratko to bi bile "kolone" :) možeš i nešto od ovoga da optimizuješ, a naravno i da proširiš, sve je pitanje krajnjih ciljeva-zahteva poslodavca.

Naravno posle ti treba još raznih rekalkulisanja (specifikacija poreza, lager stanje, kartica robe...) na osnovu ostalih dokumenata za robno (računi-otpremnice, interni povraćaji, externi povraćaji, prenos V.P./M.P. ...)

Potpis

hacker