W dniu 16.12.2011 21:46, identifikator: 20110701 pisze:
>> dbają o to, aby blokować odpowiednie wiersze/strony/tabele. Chodzi Ci o
>> mechanizmy implementacje we własnej bazie danych?
>
> przepraszam, ale jaśniej już napisać się nie da...
> najlepiej na moim przykładzie...
Jaśniej odpowiedzieć się nie da:
- transakcja
- poziom izolacji
Już Ci o tym pisałem w poprzedni wątku. Jak nie doczytasz o tych
pojęciach to dalsza dyskusja nie ma sensu. Jak doczytasz to też nie
będzie miała bo sam sobie odpowiesz na pytanie.

--
Pozdrawiam
Michoo

do góry

On 2011-12-16 13:46, Stachu 'Dozzie' K. wrote:

> Ach, to ty pytałeś dziekanatu! Trzeba było spytać prowadzącego, bo to
> jemu potencjalnie będziesz przeszkadzać. Wzrost zużycia środków trwałych
> i innych materiałów z faktu twojej obecności jest pomijalny, uczelni
> jako instytucji naprawdę nie zrobi to żadnej różnicy.

Ba IMO jako instytucja utrzymywana z podatków ma psi obowiązek pozwolić
na coś takiego przy powyższym założeniu.

--
Tomek

do góry

W dniu 2011-12-16 12:48, Stachu 'Dozzie' K. pisze:
> On 2011-12-16, wloochacz<w...@n...gmail.spameromnie.com> wrote:
>> W dniu 2011-12-15 12:47, Stachu 'Dozzie' K. pisze:
>>> On 2011-12-15, wloochacz<w...@n...gmail.spameromnie.com> wrote:
>>>> W dniu 2011-12-15 11:50, voy pisze:
>>>>> W dniu 2011-12-15 10:06, identifikator: 20110701 pisze:
>>>>>>> A potem kup sobie jakis podrecznik i poczytaj
>>>>>>
>>>>>> na studia się nie wybieram, jaki podręcznik zakupić?
>>>>>
>>>>> Source Code
>>>>>
>>>>> http://www.sqlite.org/download.html
>>>>>
>>>>> Pozdr :)
>>>> Nie wiedziałem, że SQLite zapewnia wielodostęp - od kiedy?
>>>
>>> Od dość dawna. Na pewno od wersji 2.x.
>>> http://sqlite.org/faq.html#q5
>>> Wprawdzie można by chcieć nieco więcej od pełnoprawnej bazy danych, ale
>> Nie ma żadnego "ale" no chyba, że sobie żartujesz ...
>> Zapewnienie możliwości pobierania danych przez wiele app w tym samym
>> czasie (tylko i wyłącznie, bo modyfikować już się nie da), to *nie jest*
>> wielodostęp.
>
> W takim razie proszę o twoją definicję, bo ma spore szanse być niezgodna
> z pozostałą częścią świata.
ORLY?

> Ja twój termin "wielodostęp" zrozumiałem jako możliwość używania tego
> samego pliku bazy danych przez wiele procesów. To, że niektóre operacje
> muszą być synchronizowane, nijak na to nie wpływa.
Acha.
Czyli to, że możliwość zapisu danych w bazie danych, a nie w tabeli czy
wierszu tabeli, tylko w całej bazie danych (sic!) jest ograniczona tylko
do jednego procesu w tym samym czasie, to Ci nie przeszkadza w
twierdzeniu iż SQLite jest systemem wielodostępnym?
Można i tak, ale w takim przypadku fakt - różnimy się w pojmowaniu
definicji wielodostępności i jest spora szansa na to, że Twoja jest
niezgodna z pozostałą częścią świata.

> Analogicznie system z jednym procesorem nie może być wielozadaniowy, bo
> w tym samym czasie tylko jedno zadanie naraz może się wykonywać.
Good point.
Tyle, że w *wielodostępnych* RDBMS sam silnik o to dba, a w przypadku
SQLLite muszę o to zadbać ja.
W przypadku kiedy klienci bazy danych pochodzą od różnych dostawców
ciężko mi sobie wyobrazić ową "synchronizację niektórych operacji"...
Chyba, że zwyczajnie SQLLite opluje mnie błędem, że teraz nie wolno - to
jakoś to kulawo może działać.
Jakoś...

>>> to co jest i tak jest niezłe jak na malutki, osadzalny silnik.
>> Co do tego, to zgoda.
No offence, Kolego!
Mam zerowe doświadczenie z SQLite i po prostu pewnych rzeczy na temat
tego silnika nie wiem, a zawsze się czegoś nowego dowiem - przy okazji ;-)

--
wloochacz

do góry

Tomek Banach <b...@b...org> napisał(a):

> On 2011-12-16 13:46, Stachu 'Dozzie' K. wrote:
>
> > Ach, to ty pytałeś dziekanatu! Trzeba było spytać prowadzącego, bo to
> > jemu potencjalnie będziesz przeszkadzać. Wzrost zużycia środków trwałyc
> h
> > i innych materiałów z faktu twojej obecności jest pomijalny, uczelni
> > jako instytucji naprawdę nie zrobi to żadnej różnicy.
>
> Ba IMO jako instytucja utrzymywana z podatków ma psi obowiązek pozwolić
> na coś takiego przy powyższym założeniu.
Czegos sie bali... nie wiem... moze ze bede piwo pil na wykladzie...
Pozdrawiam








--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 2011-12-17, wloochacz <w...@n...gmail.spameromnie.com> wrote:
[...]
>>> Nie ma żadnego "ale" no chyba, że sobie żartujesz ...
>>> Zapewnienie możliwości pobierania danych przez wiele app w tym samym
>>> czasie (tylko i wyłącznie, bo modyfikować już się nie da), to *nie jest*
>>> wielodostęp.
>>
>> W takim razie proszę o twoją definicję, bo ma spore szanse być niezgodna
>> z pozostałą częścią świata.
> ORLY?
>
>> Ja twój termin "wielodostęp" zrozumiałem jako możliwość używania tego
>> samego pliku bazy danych przez wiele procesów. To, że niektóre operacje
>> muszą być synchronizowane, nijak na to nie wpływa.
> Acha.
> Czyli to, że możliwość zapisu danych w bazie danych, a nie w tabeli czy
> wierszu tabeli, tylko w całej bazie danych (sic!) jest ograniczona tylko
> do jednego procesu w tym samym czasie, to Ci nie przeszkadza w
> twierdzeniu iż SQLite jest systemem wielodostępnym?

Nie przeszkadza. Wystarczy, że ta blokada będzie krótka. Chyba jakoś
niespecjalnie przeszkadza ci mówić o wielodostępie do takiego PostgreSQL
pracującego na jednoprocesorowej maszynie? Bo to mniej więcej to samo:
tylko jeden proces może w danym momencie zapisywać dane.

> Można i tak, ale w takim przypadku fakt - różnimy się w pojmowaniu
> definicji wielodostępności i jest spora szansa na to, że Twoja jest
> niezgodna z pozostałą częścią świata.

Nadal nie podałeś co rozumiesz pod pojęciem "wielodostęp" i dlaczego
jest zachowany na serwerze jednoprocesorowym, a przy synchronizacji na
pliku już nie jest. No chyba że na serwerze jednoprocesorowym baza traci
twoim zdaniem własność "wielodostępu" (założyłem że twierdzisz, że nie
traci).

>> Analogicznie system z jednym procesorem nie może być wielozadaniowy, bo
>> w tym samym czasie tylko jedno zadanie naraz może się wykonywać.
> Good point.
> Tyle, że w *wielodostępnych* RDBMS sam silnik o to dba, a w przypadku
> SQLLite muszę o to zadbać ja.

W Postgresie (pozwól, że przyssam się do tej bazy z pełnowymiarowych
RDBMS-ów) o synchronizację dostępu dba silnik. W przeciwieństwie do
SQLite, gdzie o synchronizację dostępu dba... silnik.

W pierwszym przypadku z silnikiem się łączysz, w drugim silnik osadzasz
w aplikacji, (czyli aplikację linkujesz z biblioteką). Nie widzę
specjalnej różnicy.

> W przypadku kiedy klienci bazy danych pochodzą od różnych dostawców
> ciężko mi sobie wyobrazić ową "synchronizację niektórych operacji"...

Oczywiście że ciężko. Ale wtedy najprawdopodobniej nie używasz SQLite,
tylko pełnowymiarowej bazy relacyjnej.

Poza tym nie słyszałem o konkurencyjnej do SQLite implementacji silnika
SQLite. Ale to taka drobna sygnalizacja, że te obawy dotyczą dość
mglistej (i moim zdaniem mało prawdopodobnej) przyszłości.

--
Secunia non olet.
Stanislaw Klekot

do góry