Możliwość podpięcia zewnętrznej bazy danych

[Xariyx]

Czy kiedykolwiek w programie pojawi się możliwość podpięcia zewnętrznej bazy danych innej niż sqlite? Chodzi o bazy danych z opcją wielowątkowego read/write, które umożliwiłyby pracę w tym samym momencie kilku osobom. Program przeznaczony jest niby do mikroprzedsiębiorców, ale myślę, że taka zmiana pozwoliłaby też działać takim programem w odrobinkę większych firmach.

[lkosson]

Od strony technicznej program był pisany przy założeniu, że dostęp do bazy danych jest natychmiastowy lub prawie natychmiastowy. Przepięcie na serwerową bazę wymagałoby przejrzenia i optymalizacji wszystkich wykonywanych zapytań pod kątem tolerancji opóźnień sieciowych.

Użyty w projekcie Entity Framework Core ma kiepskie wsparcie dla równoległej obsługi kilku silników baz danych (konieczność użycia osobnych kontekstów i osobnych zestawów migracji), a nie chcę zastępować SQLite'a jako podstawowej bazy.

Procesy w programie są napisane z myślą o izolacji transakcji na poziomie serializable, domyślnie gwarantowanym przez SQLite. Użycie go przy pracy wielostanowiskowej byłoby dużym ograniczeniem, a zmiana na read committed wymagałaby dokładnej analizy wzajemnych zależności między procesami i dodanie mechanizmów blokowania.

Mam też wątpliwości, czy program od strony funkcjonalnej będzie wystarczający dla firm większych niż JDG. Fajnie byłoby zrobić z niego system sprzedażowy z prawdziwego zdarzenia, ale finalnie jest to program rozwijany w wolnych chwilach przez jedną osobę, co mocno ogranicza możliwości wsparcia zwykle oczekiwane przez większe organizacje.

Odpowiadając wprost na postawione pytanie - istnieje mała, ale niezerowa szansa, że obok dotychczasowej wersji będę udostępniał też eksperymentalną wersję przeznaczoną dla Microsoft SQL Servera i/lub Postgresa, a na podstawie tego jak się sprawdzi w praktyce i ile osób będzie z niej korzystać będę podejmował dalsze decyzje.

[niutech]

SQLite można dostosować do współbieżności, bazę można umieścić w folderze współdzielonym przez SMB, nie trzeba od razu MS SQL Server.

[lkosson]

W wydaniu 1.16.0 udostępniłem oddzielną paczkę ProFak-1.16.0-mssql.zip z wersją aplikacji z wkompilowaną obsługą bazy Microsoft SQL Server (dowolna wersja, dowolne wydanie). Przed pierwszym uruchomieniem należy utworzyć w katalogu z programem plik baza.txt, a w nim umieścić parametry połączenia z bazą, np.

server=sql-server.intra;database=profak;integrated security=true;TrustServerCertificate=True

Osobiście nie jestem zadowolony z tego jak program działa w takiej konfiguracji, głównie ze względu na opóźnienia blokujące UI na czas wykonywania większości poleceń i zapytań bazodanowych. Dodatkowo aplikacja nie obsługuje profili użytkowników, więc wszyscy korzystający pracują na tych samych ustawieniach spisów i menu głównego.

Praca z bazą SQLite z udziału sieciowego jest przewidziana raczej dla trybu jednoosobowego. Baza danych pracuje w trybie WAL, więc jest możliwy swobodny odczyt podczas wprowadzania zmian w innej sesji. Nie jest natomiast możliwe wprowadzanie zmian w dwóch niezależnych sesjach, nawet jeśli te zmiany dotyczą różnych obszarów. Ze względów technicznych rozpoczęcie edycji jakiegokolwiek rekordu otwiera transakcję bazodanową, więc w praktyce blokuje zapis dla wszystkich innych użytkowników.

W wersji 1.16.0 nieco poprawiłem działanie programu z udziału. Timeouty przy próbie równoległego zapisu są dużo mniejsze, a komunikat bardziej przyjazny. Dodatkowo program nie próbuje zapisywać ustawień menu i spisów w momencie gdy jest aktywna inna transakcja (uniemożliwiało to jakiekolwiek działanie w programie gdy ktoś inny miał otwarte okno edycji).

W zależności od tego jaki będzie odzew na temat wersji MSSQL (i czy w ogóle będzie), podejmę decyzję co dalej robić z tym tematem.

Póki co zostawiam to zgłoszenie otwarte.

[niutech]

Ze względów technicznych rozpoczęcie edycji jakiegokolwiek rekordu otwiera transakcję bazodanową, więc w praktyce blokuje zapis dla wszystkich innych użytkowników.

Czy transakcja nie może być rozpoczynana w momencie zapisu edytowanego rekordu, a nie rozpoczęcia edycji rekordu? Wtedy inni użytkownicy mogliby odczytywać tę samą bazę SQLite.

[lkosson]

Odczyt nie jest problemem, bo w trybie WAL baza jest dostępna do odczytu nawet podczas trwającej transakcji z zapisem.

Rozpoczynanie transakcji i zablokowanie (lub utworzenie - w przypadku dodawania) rekordu w momencie rozpoczynania edycji mocno upraszcza ogólną logikę związaną z transakcyjnością, szczególnie dla formularzy, które zawierają zagnieżdżone spisy - nawet podczas pracy jednostanowiskowej.

[mnowak2026]

A co myślisz o dodanie bazy online np. PostgreSQL? Daje to większe bezpieczeństwo w razie utraty/uszkodzenia komputera :)

[niutech]

@mnowak2026 Moim zdaniem domyślną bazą danych powinna pozostać SQLite z racji tego, że w założeniu ProFak to prosty, darmowy program do fakturowania; skierowany przede wszystkim do mikroprzedsiębiorstw i osób prowadzących JDG, a do tego przenośny (można go trzymać np. na pendrive USB). Instalowanie najpierw bazy MS SQL/PostgreSQL niepotrzebnie skomplikowałoby procedurę instalacji i wymagałoby uruchamiania dodatkowo serwera bazy danych przed uruchomieniem programu. Natomiast nie mam nic przeciwko, jeśli to byłaby opcjonalna funkcjonalność.

[lkosson]

@mnowak2026 Po przetarciu ścieżki przy podpinaniu SQL Servera, dodanie obsługi kolejnego silnika baz danych nie będzie problemem, ale na ten moment nie planuję tego robić.

ProFak nie będzie działał dobrze z bazą online/chmurową ze względu na opóźnienia sieciowe. Przy komunikacji po sieci lokalnej nie są one większe niż 0.5 sekundy, ale przez Internet otwieranie okna edycji faktury potrafi trwać 2-3 sekundy.

Najprostszym sposobem na zabezpieczenie się przed utratą lub awarią komputera, na którym masz bazę, jest jej synchronizacja za pomocą usługi typu Syncthing, DropBox lub OneDrive. Nie zastąpi to kopii zapasowej z prawdziwego zdarzenia, ale uchroni przynajmniej przed częścią wypadków losowych.

@niutech Podstawowym silnikiem jest i pozostanie SQLite. Jeszcze czekam na opinie i uwagi, ale póki co eksperyment z SQL Serverem uważam za nieudany.