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