Dokumenti, tj. fakture ti je možda bolje držati u odvojenim dokumentima (subjektivno), a organizaciju uvjek možeš raditi po folderima itd... dok se baza uvijek radi što je moguće otpornija na velik broj zahtjeva, sinhronizaciju itd... i da bude što lakše baratati sa njom po pitanju izmjena. Tu XML i nije baš najbolje rješenje. Možda, ako ti baza nema puno artikala, možeš ju učitati u program, a samo na kraju spasiti ili napraviti autosave ili whatever. Npr. za to ti može poslužiti Hashtabela...

Hvala mnogo na brzom odgovoru i savetu...
Sto se tice faktura, nije problem drzati u odvojenim dokumentima i folderima, nego razimsljam u kom formatu da ih cuvam... znaci u smislu da mogu uvek da se otvore u tabeli(datagrid) i da se izmene ili tako nesto, i da mogu da se stampaju... zato sam mislio da ih cuvam u xml fajlovima(posebnim)... A sto se tice magacina si u pravu, xml i nije najbolje resenje ali ne znam koje drugo da uzmem? problem je sto artikala ima mnogo, kad bih stavljao sve u bazu, onda bih imao po jednu posebnu tabelu za svaki magacin, ne znam da li je to mnogo, imati tipa 50tak tabela? Nadam se jos nekim idejama i savetima ...
Hvala mnogo na pomoci !!!

A da sve to tržite u jednoj bazi odvojenim tableama pa da se svaki od putnika kači aktivno na bazu,
Danas su cijene ADSL-a priločno smiješne, a dobro osmišnjena SQL aplikacija uopšte ne zahtjeva veliki banwith
Ukoliko se rdai o prijensnim uređajima pa ni taj GPRS (ili EDGE) nije toliko preskup, a laptopi su za mene najbolja varijana
kada se opreme USB MODEMIMA.
Prednosti ove metode su neopisive
a ako se odlučite držati sve u bazi poslati ću vam par dijagrama baza podataka da videite kako smo mi to uradili


Edit:
Pardon sada sam pročitao vaš drugi post.
Moj savjet je da sve podatke čuvate u tabelama i to da ne radite više tablea za više skladišta, Izvještavanje se u velikoj mjeri komplkuje kada imate zasebne table, Ovako fino napravite tabelu dokumenta koja je referntna na tableu skladišta i tabelu vrste dokumentat i sve čuvate u jernom nizu isto tabela lagera ima primarni ključ oznaka skladišta + oznaka artikla. A na aplikativnom nivu riješavate probleme izmjene podataka.
Za prikaz koristite neki od report alata kao što su Cristal Reports i moj favorit SQL Report Server jer je bezplatan (uz SQL server).



_{[Ovu poruku je menjao adopilot dana 19.08.2009. u 00:18 GMT+1]}

Nema razloga ne držati sve u jednoj bazi.

Hvala svima mnogo, pomogli ste mi dosta!
Samo jos jedno pitanje, koliko sam video na onom dijagramu dole, znaci ja bih tako pamtio u onoj tabeli sa kljucevima id artikla i id fakture, sve fakture koje su prosle kroz firmu. Bojim se samo da li ce onda posle nekog vremena baza postati prevelika i prespora? Jer bih onda imao po 30tak redova u proseku po fakturi(ako ima 30 artikala npr) i ko zna koliko faktura za na primer godinu dana... znaci broj faktura puta broj redova po fakturi, to je mnogo redova u tabeli... Da li je to previse?

Ma 10ak hiljada redova je smešno.
Samo cepaj i ne plaši se za preformanse.

Uf, ne znam zasto sam napisao 30, nesto sam se zbunio... Pre ce biti da ima oko 1000 artikala, ali dobro ako je 10 000 smesno, onda je valjda i 100 000 prihvatljivo? :)))
Hvala na pomoci !

Zavisi naravno od hardvera na kome tjeraš bazu, ali 100k je mali broj ... Par miliona je srednji... 30mil+ postaje ozbiljno...

Kad sam spomenuo hardver, samo sam mislio da nije neka ultra-kanta, sve ostalo je OK; a ako firma bude imala preko 100k faktura, mislim da im nije problem izdvojiti malo novca za pristojan server :)