=?ISO-8859-2?Q?Aplikacja_BD_-_jak_to_zrobi=E6,_pyt._teoretyczne?=
=?ISO-8859-2?Q?Jacek_W=B1sowski?= - 24-01-2006 10:40
=?ISO-8859-2?Q?Aplikacja_BD_-_jak_to_zrobi=E6,_pyt._teoretyczne?=
Witam
Wiem, że problem jest do rozwiązania, bo w ten sposób działa większość
aplikacji bazodanowych....
Jest sobie magazyn poduktów i osoby które zarządzają tym magazynem.
Jedna osoba zmiania ceny towarów, druga ilości, trzecia i czwarta jeszcze
inne rzeczy. Wszystkie mogą tworzyć nowe pozycje w magazynie i w zasadzie
wszystko edytować.
Chciałem zapytać w jaki sposób rozwiązuje się w takich i podobnych
przypadkach problem nadpisywania tabel oraz pracy na "najświeższych"
wartościach w bazie.
Może być, że dodanie/edytowanie jednego towaru zajmie powiedzmy 5 minut - w
tym czasie 10 innych rekordów mogłobyć zmininych przez innych userów.
Jak programiści radzą sobie z tym zagadnieniem ?
Ze względu na częste sortowanie, wyszukiwanie i właśnie modyfikacje idealny
jest obiekt DataSet.
Mam kilka rozwiązań, ale żadne nie jest idealne....
Wszelkie podpowiedzi są dla mnie na wagę złota
pozdrawiam
Jacek
PS: Projekt w VS2005 + MSDE
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Artur Muszynski - 24-01-2006 10:40
"Jacek Wąsowski" <jacekwasowski@gazeta.SKASUJ-TO.pl> wrote in message
news:dr4j9i$86h$1@inews.gazeta.pl...
> Witam
> Wiem, że problem jest do rozwiązania, bo w ten sposób działa większość
> aplikacji bazodanowych....
>
> Jest sobie magazyn poduktów i osoby które zarządzają tym magazynem.
> Jedna osoba zmiania ceny towarów, druga ilości, trzecia i czwarta jeszcze
> inne rzeczy. Wszystkie mogą tworzyć nowe pozycje w magazynie i w zasadzie
> wszystko edytować.
>
> Chciałem zapytać w jaki sposób rozwiązuje się w takich i podobnych
> przypadkach problem nadpisywania tabel oraz pracy na "najświeższych"
> wartościach w bazie.
> Może być, że dodanie/edytowanie jednego towaru zajmie powiedzmy 5 minut -
> w
> tym czasie 10 innych rekordów mogłobyć zmininych przez innych userów.
> Jak programiści radzą sobie z tym zagadnieniem ?
>
> Ze względu na częste sortowanie, wyszukiwanie i właśnie modyfikacje
> idealny
> jest obiekt DataSet.
>
> Mam kilka rozwiązań, ale żadne nie jest idealne....
Bo nie ma idealnego rozwiązania.
Proste i skuteczne rozwiązanie, to blokowanie optymistyczne. Poberasz dane
(SELECT), edytujesz, a przy zapisie (UPDATE) sprawdzasz, czy dane nie
zostały w międzyczasie zmienione (WHERE kol1=stara_wartość1,kol2=....). W
przypadku błędu komunikat i powrót do edycji, żeby można było poprawić.
Drugie podejście, to blokowanie tabel na poziomie aplikacji (przed edycją
robisz wpis do specjalnej tabeli).
Trzecie podejście polega na zdanie się na mechanizmy bazy danych -
wymuszanie więzów integralności itd. Próby zapisania bzdur kończą się
błędem.
Rozwiązanie na pewno złe, to blokowanie rekordów do edycji za pomocą
transakcji.
artur
=?ISO-8859-2?Q?S=B3awomir_Szysz=B3o?= - 25-01-2006 13:33
=?ISO-8859-2?Q?Re:_Aplikacja_BD_-_jak_to_zrobi=E6,_pyt._teoretyczne?=
Dnia Tue, 24 Jan 2006 11:27:34 +0100, "Artur Muszynski"
<arturm@union.wytnijto.com.pl> wklepał(-a):
>Bo nie ma idealnego rozwiązania.
>Proste i skuteczne rozwiązanie, to blokowanie optymistyczne. Poberasz dane
>(SELECT), edytujesz, a przy zapisie (UPDATE) sprawdzasz, czy dane nie
>zostały w międzyczasie zmienione (WHERE kol1=stara_wartość1,kol2=....). W
>przypadku błędu komunikat i powrót do edycji, żeby można było poprawić.
Rozwiązanie mało wydajne - w najgorszym przypadku 3 selecty, żeby poprawić jeden
rekord (1 - pobranie danych, 2 - weryfikacja przed update, 3 - ponowne pobranie,
gdy błąd).
>Drugie podejście, to blokowanie tabel na poziomie aplikacji (przed edycją
>robisz wpis do specjalnej tabeli).
Aplikacja się wykłada, blokady zostają - w jednym programie zastałem takie
rozwiązanie, zaorałem to i zrobiłem normalny "select for update" blokujący
rekord. Jeśli aplikacja padnie, sesja znika i blokady też - problem rozwiązuje
się sam. O ile baza to wspiera. :)
>Trzecie podejście polega na zdanie się na mechanizmy bazy danych -
>wymuszanie więzów integralności itd. Próby zapisania bzdur kończą się
>błędem.
>Rozwiązanie na pewno złe, to blokowanie rekordów do edycji za pomocą
>transakcji.
A możesz uzasadnić to ostatnie?
--
Sławomir Szyszło mailto:slaszysz@poczta.onet.pl
Primus inter FAQires & Grand Inquisitor no.0 of pl.comp.bazy-danych
FAQ pl.comp.bazy-danych http://www.dbf.pl/faq/
Archiwum http://groups.google.com/groups?grou...mp.bazy-danych
Grzesiek G. - 25-01-2006 13:33
Sławomir Szyszło napisał(a):
> Dnia Tue, 24 Jan 2006 11:27:34 +0100, "Artur Muszynski"
> <arturm@union.wytnijto.com.pl> wklepał(-a):
>
>
>>Bo nie ma idealnego rozwiązania.
>>Proste i skuteczne rozwiązanie, to blokowanie optymistyczne. Poberasz dane
>>(SELECT), edytujesz, a przy zapisie (UPDATE) sprawdzasz, czy dane nie
>>zostały w międzyczasie zmienione (WHERE kol1=stara_wartość1,kol2=....). W
>>przypadku błędu komunikat i powrót do edycji, żeby można było poprawić.
>
>
> Rozwiązanie mało wydajne - w najgorszym przypadku 3 selecty, żeby poprawić jeden
> rekord (1 - pobranie danych, 2 - weryfikacja przed update, 3 - ponowne pobranie,
> gdy błąd).
>
SELECTa przed update nie trzeba robić - wystarczy odpowiedni WHERE w
UPDATE + sprawdzenie czy coś się zaktualizowało (sprawdzenie @@ROWCOUNT
w MSSQL). Ponieważ jest to podejście optymistyczne, to zakładająć iż
optymizm jest uzasadniony (najczęściej robi się jeden select + jeden
update), jest sens go stosować.
--
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!
Artur Muszynski - 25-01-2006 13:33
>>Proste i skuteczne rozwiązanie, to blokowanie optymistyczne.
> Rozwiązanie mało wydajne - w najgorszym przypadku 3 selecty, żeby poprawić
> jeden
> rekord (1 - pobranie danych, 2 - weryfikacja przed update, 3 - ponowne
> pobranie,
> gdy błąd).
To Grzegorz wyjaśnił.
>>Rozwiązanie na pewno złe, to blokowanie rekordów do edycji za pomocą
>>transakcji.
>
> A możesz uzasadnić to ostatnie?
Podobnie, jak przechwytywanie wyjątków nie zastępuje poprawnego kodu, tak
samo jest w przypadku transakcji. Przekroczenie czasu wykonywania transakcji
jest sytuacją wyjątkową, która nie powinna mieć miejsca. Przy operacjach
interaktywnych byłaby to sytuacja normalna. Jest też problem z ustaleniem
użytkownika, który zablokował rekord. Ponadto możesz być niemile zaskoczony,
bo żaden standard nie mówi, że blokada działa na poziomie pojedynczego
rekordu (w rzeczywistości zwykle tak nie jest).
Pozdrawiam
artur
=?ISO-8859-2?Q?Jacek_W=B1sowski?= - 25-01-2006 13:33
=?ISO-8859-2?Q?Re:_Aplikacja_BD_-_jak_to_zrobi=E6,_pyt._teoretyczne?=
Wymysliłem, że UPDATE tabeli wykonywany bdzie po modyfikacji każdego rekordu.
Mając blokowanie optymistyczne, gdy 2 osoby nie będą edytowac tego samego
wiersza - będzie OK. W przeciwnym wypadku będzie błąd (tu dam jakiś monit).
W chwili modyfikacji tabeli, w osobnej tabeli (tblFlagi) ustawiam sobie flagę
z 0 na 1 co ma być sygnałem dla innych userów, że dana tabela została
zmodyfikowana.
I teraz mam timer, który resetuje się (odlicza od nowa) w chwili ruchu myszy
lub wciśnięcie klawiszy. Gdy dojdzie do powiedzmy 5 sekund (czyli 5 sek
bezczynności) oczytuje dane z tabeli tblFlagi. Jeśli przy tblOsoby jest 1,
tzn że należy zrobić Fill. Jeśli ma 0 tzn, że tabela tblOsoby nie była
modyfkowana przez innych userów i wciąż pracujemy na najnowszej wersji.
Dobrze ??
co dopracować:
- 5 sekund.... Narazie testy. Chodzi o to, że jak osoba nie używa programu
przez 5 sekund prwdopodobnie nie będzie używała do przez następne trzy w
których wykonana zostanie metoda FILL (o ile będzie taka potrzeba). Metodę
FILL wrzucę do BackGrodungWorker lub osobnego wątku (rozważam to jeszcze).
Rozważam jeszcze to, żeby zrezygnować z czekania na bezczynność osoby
kozystającej z programu. Może olać to i ustawić timer na stałe ma 5 czy 10
sek. i robić sprawdzanie cyklicznie (i ew. fill tabeli)....
- nie wiem jak to będzie z szybkością działania programu.... Tabele nie są
duże, tylko jedna max kilkadziesiąt tysięcy rekordów. Ale prawie nigdy nie
będą całe wczytywane....
może być ??
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
=?ISO-8859-2?Q?S=B3awomir_Szysz=B3o?= - 26-01-2006 11:01
=?ISO-8859-2?Q?Re:_Aplikacja_BD_-_jak_to_zrobi=E6,_pyt._teoretyczne?=
Dnia Wed, 25 Jan 2006 09:48:34 +0100, "Grzesiek G."
<gruza@spamerom_nie.priv4.onet.pl> wklepał(-a):
>SELECTa przed update nie trzeba robić - wystarczy odpowiedni WHERE w
>UPDATE + sprawdzenie czy coś się zaktualizowało (sprawdzenie @@ROWCOUNT
>w MSSQL). Ponieważ jest to podejście optymistyczne, to zakładająć iż
>optymizm jest uzasadniony (najczęściej robi się jeden select + jeden
>update), jest sens go stosować.
Jak dla mnie to jest podejście pesymistyczne - optymistyczne nic by nie
sprawdzało. :) Poza tym sprawdzanie wartości każdej kolumny przed update zamiast
skorzystania z mechanizmów blokowania to dla mnie jakieś ciężkie
nieporozumienie. Bo i tak nie gwarantuje to spójności danych.
--
Sławomir Szyszło mailto:slaszysz@poczta.onet.pl
Primus inter FAQires & Grand Inquisitor no.0 of pl.comp.bazy-danych
FAQ pl.comp.bazy-danych http://www.dbf.pl/faq/
Archiwum http://groups.google.com/groups?grou...mp.bazy-danych
Artur Muszynski - 26-01-2006 11:01
"Sławomir Szyszło" <slaszysz@poczta.onet.pl> wrote in message
news:dr8l3h.qc.1@slaszysz.poczta.onet.pl...
> Dnia Wed, 25 Jan 2006 09:48:34 +0100, "Grzesiek G."
> <gruza@spamerom_nie.priv4.onet.pl> wklepał(-a):
>
>>SELECTa przed update nie trzeba robić - wystarczy odpowiedni WHERE w
>>UPDATE + sprawdzenie czy coś się zaktualizowało (sprawdzenie @@ROWCOUNT
>>w MSSQL). Ponieważ jest to podejście optymistyczne, to zakładająć iż
>>optymizm jest uzasadniony (najczęściej robi się jeden select + jeden
>>update), jest sens go stosować.
>
> Jak dla mnie to jest podejście pesymistyczne - optymistyczne nic by nie
> sprawdzało. :) Poza tym sprawdzanie wartości każdej kolumny przed update
> zamiast
> skorzystania z mechanizmów blokowania to dla mnie jakieś ciężkie
> nieporozumienie. Bo i tak nie gwarantuje to spójności danych.
Może, zamiast pleść banialuki, byś się tak trochę doszkolił? Hasło masz
podane. Wyszukiwarką, mam nadzieję, umiesz się posługiwać. Przy okazji
poczytaj też o blokowaniu pesymistycznym (przy odrobinie szczęścia
znajdziesz coś o deadlockach w tym kontekście).
artur
=?ISO-8859-2?Q?S=B3awomir_Szysz=B3o?= - 26-01-2006 11:01
=?ISO-8859-2?Q?Re:_Aplikacja_BD_-_jak_to_zrobi=E6,_pyt._teoretyczne?=
Dnia Wed, 25 Jan 2006 21:35:21 +0100, "Artur Muszynski"
<arturm@union.wytnijto.com.pl> wklepał(-a):
>Może, zamiast pleść banialuki, byś się tak trochę doszkolił? Hasło masz
>podane. Wyszukiwarką, mam nadzieję, umiesz się posługiwać. Przy okazji
>poczytaj też o blokowaniu pesymistycznym (przy odrobinie szczęścia
>znajdziesz coś o deadlockach w tym kontekście).
I co, popełniłem wykroczenie, bo nazwałem to po swojemu, o Wielki Znawco
Terminologii? Gdzie mam wnieść opłatę karną?
--
Sławomir Szyszło mailto:slaszysz@poczta.onet.pl
Primus inter FAQires & Grand Inquisitor no.0 of pl.comp.bazy-danych
FAQ pl.comp.bazy-danych http://www.dbf.pl/faq/
Archiwum http://groups.google.com/groups?grou...mp.bazy-danych
Grzesiek G. - 30-01-2006 10:32
Sławomir Szyszło napisał(a):
> Dnia Wed, 25 Jan 2006 09:48:34 +0100, "Grzesiek G."
> <gruza@spamerom_nie.priv4.onet.pl> wklepał(-a):
>
>
>>SELECTa przed update nie trzeba robić - wystarczy odpowiedni WHERE w
>>UPDATE + sprawdzenie czy coś się zaktualizowało (sprawdzenie @@ROWCOUNT
>>w MSSQL). Ponieważ jest to podejście optymistyczne, to zakładająć iż
>>optymizm jest uzasadniony (najczęściej robi się jeden select + jeden
>>update), jest sens go stosować.
>
>
> Jak dla mnie to jest podejście pesymistyczne - optymistyczne nic by nie
> sprawdzało. :) Poza tym sprawdzanie wartości każdej kolumny przed update zamiast
> skorzystania z mechanizmów blokowania to dla mnie jakieś ciężkie
> nieporozumienie. Bo i tak nie gwarantuje to spójności danych.
Jeżeli tabela ma pole typu timestamp, czy DatęOstatniejModyfikacji, to
wystarczy sprawdzać klucz+wymienione powyżej pole zamiast wszystkich.
Mechanizm blokowania niezbyt się chyba sprawdza w bazach, które nie mają
poziomu izolacji snapshot, czy read commited snapshot (używam
terminologii z MSSQL).
Na marginesie: podejście które nic nie sprawdza nazywane jest w
literaturze "last wins".
Pozdrawiam
--
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Wydajność baz danych w zależności od poziomu izolacji ANSI/ISO
Czy zna (obsługuje) ktoś program Iso Draw ?
MYSQL - kodowanie w ISO-PL
strona plus baza w iso do utf-8
Kodowanie: z iso na utf
Konwesja znaków w dump'ie bazy danych - ISO -> utf-8 -> ISO -> utf-8
=?iso-8859-2?q?Co_oznacza_b=B3=B1d_Warning:_mysql=5Fconnect() _[function.mysql-connect]:_Can't_connect_to_local_MySQL_server_through_sock et_'/var/run/mysqld/mysqld.sock'_(2)_in?=
=?iso-8859-2?q?Informatyka,_Java,_EJB,_Ajax,_Spring=2E_Czy=BF by_to_koniec_=B6wiata,_czy_te=BF_nasze_uczelnie_b= EAd=B1_uczy=B3y_w_ko=F1cu!_czego_praktycznego_=2E= 2E=2E=2E?=
[MS SQL 2005] =?windows-1250?Q?Ilo=9C=E6_wiersz=F3w_w_zbiorze_wynikowym?=
=?ISO-8859-2?Q?=AFegnam_si=EA=2E=2E=2E?=
zanotowane.pldoc.pisz.plpdf.pisz.pladwokat.keep.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
