Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Azurnost podataka

[es] :: Baze podataka :: Azurnost podataka

[ Pregleda: 3639 | Odgovora: 10 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

db2005

Član broj: 72506
Poruke: 5
*.ptt.yu.



Profil

icon Azurnost podataka28.10.2005. u 12:58 - pre 224 meseci
Neznam da li cu uspeti da dobro formulisem pitanje
da bih dobio pravilan odgovor. Da pokusam.

MDB na serveru (nazovimo tako izdvojen racunar)
Sa klijenta pristupam podacima (tabelama) preko
ODBC-a ili ADO-a svejedno. Mislim da klijent nije
bitan (VB, VF, ... ili nesto drugo)

Kako ce se razlikovati jednokorisnicka od visekorisnicke
aplikacije kod naredbi tipa UPDATE, INSERT ili bilo koje
druge koja azurira tabelu odnosno bazu.

Ranije (dbf) sam to radio sa USE <...> EXCLUSIVE
ili sa RLOCK tabele, ili sloga, itd ...

Da li i sada treba prilikom pisanja koda voditi racuna
o istoj stvari ili baze imaju ugradjene mehanizme
i same vode racuna o nemogucnosti konflikata.

Ko vodi racuna o tome da li dva korisnika istovremeno
azuriraju isti slog, odnosno da li access ima komande
za zakljucavanje podataka i kada i kako ih koristiti?
Isto pitanje me zanima i za MSSQL?
Da li je problematika slicna ili ista za svaku bazu?

Zamolio bih za jedan kratak primer (nekoliko SQL naredbi)


Nadam se da je razumljivo sta me zanima.

Hvala unapred.



 
Odgovor na temu

db2005

Član broj: 72506
Poruke: 5
*.vdial.verat.net.



Profil

icon Re: Azurnost podataka28.10.2005. u 17:42 - pre 224 meseci
Negde sam procitao da se to postize transakcijama

BEGIN TRANSACTION
...
...
COMMIT TRANSACTION

medjutim, na drugim mestima

' ... Postgres je jako fin sistem, i podrzava transakcije, dok MySQL ne podrzava transakcije ...'

Pa zar NET nije pun MySQL baza kojima pristupa mnogo korisnika?

Pomagajte ljudi !!!
 
Odgovor na temu

k0nj!na
Dzowadin Konjosav
Novi Sad

Član broj: 2137
Poruke: 39
*.com
Via: [es] mailing liste



Profil

icon Re: Azurnost podataka29.10.2005. u 02:42 - pre 224 meseci
MySQL podržava transakcije od verzije 3.23.49, ali samo ako je tabela tipa
InnoDB ili BerkeleyDB.
MyISAM koji je default tip tabele ne podržava tansakcije.

[Ovu poruku je menjao k0nj!na dana 29.10.2005. u 03:45 GMT+1]
~ k0nj!na ~
 
Odgovor na temu

db2005

Član broj: 72506
Poruke: 5
*.ptt.yu.



Profil

icon Re: Azurnost podataka29.10.2005. u 11:19 - pre 224 meseci
Citat:
MySQL podržava transakcije od verzije 3.23.49 ...


Ma to nema veze sa temom, dajte da ne razvlacimo temu.

Zeljno ocekujem pomoc a dobijam replike na nesto sto je
drugi napisao (vidi citat) . :(

 
Odgovor na temu

Riste Pejov
Team Leader/Senior Software Developer @
Ein-Sof ltd Skopje
Skopje, Macedonia

Član broj: 128
Poruke: 571
217.16.84.*

Jabber: richie@bagra.net.mk
ICQ: 154236769
Sajt: riste.softver.org.mk


Profil

icon Re: Azurnost podataka29.10.2005. u 20:32 - pre 224 meseci
Access, dbf ... i ostale desktop baze cij cilj nije multi user okolina, i koji nemaju transakcije se nemogu uopste uporegjivati sa RDBMS-a koji imaju transakcije cime se moze postici atomicnost operacijama i izolacija korisnika. Desktop baze su proslost! Ako zelis multi user ... zaboravi access.

evo nesto za izolaciji kod SQL servera: http://msdn.microsoft.com/libr...us/tsqlref/ts_set-set_74bw.asp

evo o izolaciji kod Firebird servera:
http://www.ibphoenix.com/main....338:20227&page=ibp_expert5

firebird koristi record versioning concurrency a SQL server koriosti transaction log file, zato firebird nudi vecu konkurentnost i manipulaciju podataka. SQL server 2005 bi trebao imati record versioning.


[Ovu poruku je menjao Riste Pejov dana 29.10.2005. u 21:35 GMT+1]
People who think they know everything tend to irritate those of us who do.
 
Odgovor na temu

db2005

Član broj: 72506
Poruke: 5
*.ptt.yu.



Profil

icon Re: Azurnost podataka29.10.2005. u 23:54 - pre 224 meseci
Citat:
Riste Pejov: Access, dbf ... i ostale desktop baze cij cilj nije multi user okolina, i koji nemaju transakcije se nemogu uopste uporegjivati sa RDBMS-a koji imaju transakcije cime se moze postici atomicnost operacijama i izolacija korisnika. Desktop baze su proslost! Ako zelis multi user ... zaboravi access.


Ups, pa ti me covece prestravi ...

Nemoj se ljutiti, ali bih ja za pocetak nesto
'manje profesionalno'.

Pazi ...
U mom preduzecu (30-ak zaposlenih) instaliran je softver za
knjigovodstvo na kome trenutno ima 30-ak hiljada stavki u tabeli
stavke a bude ih oko 50 godisnje samo u ovoj tabeli.
Taj mdb ima preko 400 tabela. Pojma nemam sta su sve izprojektovali
ali su u istom fajlu su i osnovna sredstva i plate i ko zna sta jos sto
nije instalirano nama. Kad zaviris u Relationships padnes u nesvest.

E sad sve to radi (vec tri godine) bez ikakvih problema na 10 racunara
od kojih su 6 stalno zakaceni na bazu.

Aplikacija je pisana u VB6.

U drugom preduzecu sam video aplikaciju gde se u mdb fajlu obradjuje
preko pola miliona slogova. Imamo sam probleme (ja im odrzavam)
iskljucivo zbog nestanka struje ili drugih neregularnih zavrsetaka program
ali je gotovo uvek repair sredjivao stvar. Za 4 godine samo smo jednom
izgubili 100 slogova i to mojom greskom (slucajno obrisano) koji su mogli
biti spaseni ali sam zbog nedostatka vremena (moga) insistirao da ih
otkucaju.

Pazi Riste, procitao sam neke tvoje postove i video da su uglavnom pisani
za visi nivo korisnika, ali (bez ljutnje) moras ponekad da bi pomogao manje
iskusnim korisnicima da se spustis na njihov nivo :).

Ejj pa necu sigurno raditi projekat za Ministarstvo finansija ili mozda EPS :)

Mozes li molim te da mi samo u par recenica pojasnis sledece:

1.
SELECT * FROM FinansijksaStavka WHERE BrojDokumenta=1000
Shvatam da ovo mogu raditi 10 korisnika bez da imaju probleme
oko narusavanja integriteta baze.

2.
Korisnik I
UPDATE Komitenti SET NazivKomitenta='TELEKOM' WHERE IDKomitenta='001'
Istovremeno korisnik II
UPDATE Komitenti SET SedisteKomitenta='BEOGRAD' WHERE IDKomitenta='001'

Ovo je ono sto me zanima.
Dakle postoji konekcija na bazu (ODBC, ADODB, .... sta ja znam)

Da li je dovoljno (dozvoljeno) napisati samo UPDATE, INSERT naredbe bez
da se nekako zastiti slog od istovremenog azuriranja nekog drugog korisnika.

Ako samo uradim niz takvih azuriranja na jednoj masini ce to sve
funkcionisati dobro ali sta ce se desiti ako MDB postavim na server
a recimo bazi preko iste aplikacije pristupam na primer preko terminal servera.
Ko tu brine o ovlascenjima i prioritetima ko moze azurirati tabelu?
Da li ja kao autor iz svog koda nekim naredbama.
Znaci nemam pojma sta je u VB kodu aplikacije koja mi je u preduzecu.
Kako su autori vodili racuna da onih 6 klijenata ne naprave konflikt
prilikom azuriranja podataka.
Trazio sam po raznim SQL helpovima ali nisam mogao da nadjem razumljivi
objasnjenje za sada.
Zato sam u prvom postu postavio paralelu sa DBF.
Imam (clipper) paket koji godina bez problema radi na 5 racunara a
tabelama se intezivno pristupa. Naravno u kodu sam vodio racuna
o dozvolama za pristup podacima (najcesce zakljucavanjem slogova RLOCK).

Svestan sam da nije lako pojednostavljivati ali se nadam da me razumes.
MDB uglavnom nece iziskivati moje ceste intervencije kao recimo MSSQL ili
Firebird a mislim da je bolji izbor nego recimo SQLite.

Imam nekoliko uradjenih jednokorisnickih aplikacija sa win bazama ali se
dosada nisam upustao u projektovanje visekorisnickih.

Nadam se da sam sad bio jasniji. I nemoj se molim te ljutiti sto pokusavam
da izvucem nesto sto je verovatno
Ne zelim da temu prosirujemo na to sta je bolji izbor i koja recimo
odnos cena/kvalitet :)

 
Odgovor na temu

ismilovic
Ivan Smilović
Istra

Član broj: 63197
Poruke: 89
*.hr
Via: [es] mailing liste



Profil

icon Re: Azurnost podataka30.10.2005. u 09:51 - pre 224 meseci
> Ko tu brine o ovlascenjima i prioritetima ko moze azurirati tabelu?
Imam slične probleme a upravo sam pročitao....... (.NET Framework
Developer's Guide)
In a multiuser environment, there are two models for updating data in a
database: optimistic concurrency, and pessimistic concurrency. The DataSet
object is designed to encourage the use of optimistic concurrency for
long-running activities such as when you are remoting data and when users
are interacting with data.

Pessimistic concurrency involves locking rows at the data source to prevent
users from modifying data in a way that affects other users. In a
pessimistic model, when a user performs an action that causes a lock to be
applied, other users cannot perform actions that would conflict with the
lock until the lock owner releases it. This model is primarily used in
environments where there is heavy contention for data, where the cost of
protecting data with locks is less than the cost of rolling back
transactions if concurrency conflicts occur.

.... Možda ti pomogne
 
Odgovor na temu

Riste Pejov
Team Leader/Senior Software Developer @
Ein-Sof ltd Skopje
Skopje, Macedonia

Član broj: 128
Poruke: 571
80.77.145.*

Jabber: richie@bagra.net.mk
ICQ: 154236769
Sajt: riste.softver.org.mk


Profil

icon Re: Azurnost podataka31.10.2005. u 09:25 - pre 224 meseci
Citat:
db2005: Ups, pa ti me covece prestravi ...
Pazi ...
U mom preduzecu (30-ak zaposlenih) instaliran je softver za
knjigovodstvo na kome trenutno ima 30-ak hiljada stavki u tabeli
stavke a bude ih oko 50 godisnje samo u ovoj tabeli.
Taj mdb ima preko 400 tabela. Pojma nemam sta su sve izprojektovali
ali su u istom fajlu su i osnovna sredstva i plate i ko zna sta jos sto
nije instalirano nama. Kad zaviris u Relationships padnes u nesvest.

E sad sve to radi (vec tri godine) bez ikakvih problema na 10 racunara
od kojih su 6 stalno zakaceni na bazu.


Sve je to super, cuo sam da je u odredjenim situacijama moguce da mdb drzi sve to, ali kao sto bi rekli englezi: don't push your luck.
Nadam da ti se nece desiti nesto kao power ili disk failure i i zavrsis sa korumpiranim mdb fajlom.

Citat:

1.
SELECT * FROM FinansijksaStavka WHERE BrojDokumenta=1000
Shvatam da ovo mogu raditi 10 korisnika bez da imaju probleme
oko narusavanja integriteta baze.

Ako su to samo read-only transakcije onda nemas nikakvog problema. Problemi se pojave kada na istoj bazi moras u isto vreme da imas OLTP (unos novih faktura recimo) i da menadzer trazi izvestaj ili neki long running query koji pokrije 30 000 recorda.

Citat:

2.
Korisnik I
UPDATE Komitenti SET NazivKomitenta='TELEKOM' WHERE IDKomitenta='001'
Istovremeno korisnik II
UPDATE Komitenti SET SedisteKomitenta='BEOGRAD' WHERE IDKomitenta='001'

Ovo je ono sto me zanima.
Dakle postoji konekcija na bazu (ODBC, ADODB, .... sta ja znam)

Sam ADO podrzava transakcije ali neam pojma kako to radi kad je u pitanju access baza. U principu tvoji korisnici rade na razlicitim slogovima tako da nemas nikakvog problema

[greska] nisam video da je ID isti ... tako da ova u zavisnosti ko je prvi, vtori moze da dobije gresku kad pokusa da smeni record, ili se moze desiti da ga DB engine ostavi da saceka da prvi zavrsi pa da onda uradi update. Sve zavisi o nivou izolacije i tipu transakcije koje dva clienta koriste[/greska]


Ja nemam nikakvog iskustva u access-u ili clipper-u. Jedino sam jednom radio sa Paradox ali je aplikacija radila na PC-u koji je problema sa jacinom struje i imao sam milion i jednog problema sa tom bazom. Tada sam se zakleo da necu vise nikad u zivotu raditi na bazu kao paradox, clipper, access ...

Citat:

Svestan sam da nije lako pojednostavljivati ali se nadam da me razumes.
MDB uglavnom nece iziskivati moje ceste intervencije kao recimo MSSQL ili
Firebird a mislim da je bolji izbor nego recimo SQLite.

Nadam se da sam sad bio jasniji. I nemoj se molim te ljutiti sto pokusavam
da izvucem nesto sto je verovatno
Ne zelim da temu prosirujemo na to sta je bolji izbor i koja recimo
odnos cena/kvalitet


U principu MDB i nije nesto drasticno laksi za odrzavanje nego FB ili SQL Server sve je stvar navike. Ja isto imam nekoliko FB baze koje imaju puno recorda i koje rade prakticno sa zero-maintenance. Ali zato, kada nestane struja i momentalno je bilo 30 povezanih korisnika, 99% je verovatnost da ce sve raditi fino kad se struja vrati. A da ne pricam od tome da kada neko pokrene analizu koja involvira 100K recorda ne ometa uopste ostale kliente koje rade OLTP. Kada jednom probas FB i se navuces ... onda jedino ti ostaje da postanes FB evangelista

Access valjda ima neke varijante record locking-a koje stvarno ne znam kako i zasto rade.

I na kraju mogu samo reci da ocigledno govorimo o razlicitim stvarima, posto je zaklucavanje slogova sasvim razlicno MDB(o cime pojma nemam) i SQL Server/FB.

Znam da sam veliki evangelista Firebird-a, i baza je prema mojim iskustvima one-stop resenje za sve moje DB potrebe od embedded single user, koja ide kao samo jedan dll i nema potebe instalacija servera, pa do multi-user server koji podrzava 100nak korisnika i terabajte podataka.

I ne brini, ne ljutim se zatoa sto neko zeli saznati nesto vise sa cime nema iskustva, sto vise i ja bi zeleo da saznam nesto vise o locking mehanizmima kod access, paradox ili clipper. A za ono gore MDB sa 400 tabela, 100K recorda i 30tak usera ... svaka cast momak, mislio sam da je to nemoguce



[Ovu poruku je menjao Riste Pejov dana 31.10.2005. u 11:53 GMT+1]
People who think they know everything tend to irritate those of us who do.
 
Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.eqao.com.



+79 Profil

icon Re: Azurnost podataka31.10.2005. u 14:41 - pre 224 meseci
db2005, imas na ovom sajtu formu posvecen Accessu, pa probaj tamo.

 
Odgovor na temu

db2005

Član broj: 72506
Poruke: 5
*.244.197.0



Profil

icon Re: Azurnost podataka31.10.2005. u 22:45 - pre 224 meseci
>I ne brini, ne ljutim se zatoa sto neko zeli saznati nesto vise sa cime nema >iskustva, sto vise i ja bi zeleo da saznam nesto vise o locking mehanizmima kod >access, paradox ili clipper. A za ono gore MDB sa 400 tabela, 100K recorda i >30tak usera ... svaka cast momak, mislio sam da je to nemoguce

Riste PC nam higijenicarka ne koristi ( Mozda kad uDZemo u EU ;) ).
30ak zaposlenih, 10 PC-a a obicno do 6 user-a. To je kudikamo manje
od 30, zar ne? :)
A sve to u uslovima koje ne mozes ni da sanjas.
AC 120-150V -> korektori -> Agregati +svakodnevni ispadi struje.
i tako sve godine koje nabrojah. (Kosovo i Metohija)

Za disk failure se ne treba brinuti ako se redovno radi backup.

Clipper mi radi sa 5 usera od '96 kod nekoliko klijenata takoDZe bez
problema. Ko ne veruje moze da proveri.

Na kraju nije mi uopste bila namera da bilo sta favorizujem.

Mene je zanimalo kako se zakljucavaju podaci za nesmetano azuriranje.
Nacin sa Transact-SQL-om.
Mislio sam da mi se to moze objasniti u par recenica i da je isto ili
slicno za sve baze koje podrzavaju Transact-SQL.

Pominjao sam aplikaciju samo da kazem da se za obim poslova koji ce
meni najverovatnije trebati nesmetano moze uraditi i sa MDB-om obzirom
da sam prakticno video da je moguce, a ne da favorizujem access.

Nista mi ne smeta da to bude i FireBird koji sam ozbiljno uzeo u
razmatranje citajuci mnoge postove o istom.

Neka bude i Firebird ali mi ako ti nije tesko napisi par redova
kako se zakljucava slog za upis da bih imao samo neku predstavu ili
bar postiraj nekoliko linkova za neki help i samples.

Puno pozdrava :)


Citat:
Zidar: db2005, imas na ovom sajtu formu posvecen Accessu, pa probaj tamo.


Hvala, pokusavao sam ali nisam nasao pa sam zato i otvorio novi topik
smatrajuci da ce biti od koristi i drugima.

Dajte bre ljudi neki link na temu, samo ne tipa guglaj malo SQL :)

Pozdrav i hvala svima.





[Ovu poruku je menjao db2005 dana 31.10.2005. u 23:46 GMT+1]
 
Odgovor na temu

Riste Pejov
Team Leader/Senior Software Developer @
Ein-Sof ltd Skopje
Skopje, Macedonia

Član broj: 128
Poruke: 571
80.77.145.*

Jabber: richie@bagra.net.mk
ICQ: 154236769
Sajt: riste.softver.org.mk


Profil

icon Re: Azurnost podataka01.11.2005. u 07:49 - pre 224 meseci
Evo par linkova:

Understanding InterBase transactions
http://bdn.borland.com/borcon2...cle/paper/0,1963,32280,00.html

InterBase server transactions and their support in FIBPlus
http://www.interbase-world.com/en/articles/532.php

Imas znaci objasnenja kako se koriste transakcije sa FIB i IBX komponentama koje koriste nativni API za interbase. Isto tako tako vredi pogledati

Firebird ODBC driver
http://www.ibphoenix.com/main....ibphoenix&page=ibp_60_odbc

jer ces valjda preko VB pristupati Firebird-u i tako trebas implementirati izolaciju preko ODBC drajvera.


People who think they know everything tend to irritate those of us who do.
 
Odgovor na temu

[es] :: Baze podataka :: Azurnost podataka

[ Pregleda: 3639 | Odgovora: 10 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.