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

zasto?

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.

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.

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...

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.

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?

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 ?

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

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.

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?

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...

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. ...)

Sve ovo što sam napisao oko sadržaja kalkulacije je čisto da počneš "nešto"...
Što se tiče "problema" može ih biti mnogo od tehničke prirode pa sve do Fin. Policije.
Ukoliko stvarno nameravaš da u nekoj verziji nekom prodaš aplikaciju prethodno potraži pomoć sertifikovanog knjigovođe koji bi odobrio ispravnost rada tvoje aplikacije.

Za početak ti preporučujem Access bazu podataka, jer ima dosta primera na net-u, dosta knjiga na srpskom jeziku. Sa 100.000 slogova nema problema, ukoliko savladaš osnove izrade baza podataka. A ukoliko se dovoljno usavršiš, pa ti je potreban "Database Server", vrlo je lako izvršiti export Access baze u MS SQL Server ili MSDE2000(free).

e to se zove savet! :) hvala...

sto se tice sadrzaja aplikacije, tu sam jako dobro informisan jer poznajem dosta ljudi koji se bave tim poslom, a imao sam i prilike da radim sa slicnim aplikacijama tako da mi u toj sferi ne treba pomoc...
Problem mi je bio pri odabiru baze, ali sada sam i to resio...

Hvala svima na savetima...

Evo malo kontra argument od pljuvanja access-a

Acceess ce da prezvace 100 000 slogova dok si reko keks, to nije puno ja sam imao tabele sa 5 000 000 slogova pa i to radi dosta dobro :)
Ukoliko imas vise korisnika do 5-6 radice ti solidno u stvari sve zavisi do dizajna baze, kako je neko vec napisao, i aplikacije koja barata sa access-om ukoliko se odlucis da to ne bude access (prim VB, C#).

Problemi nastaju kad ti baza naraste preko nekih 200 MB dolazi do blagog usporenja. Za one koje nisu mnogo radili baze access je idealno (moje misljenje) resenje za win platforme. I jos jedno misljenje, ne mozes da naucis da trcis a da pre toga ne naucis da hodas :)