Na rynku funkcjonuje dziesiątki
systemów rejestracji czasu pracy pracowników, opartych na autorskich programach.
Wiele z nich napisanych zostało wczoraj, inne powstawały latami na bazie doświadczeń
i współpracy z klientami. Te napisane „wczoraj” charakteryzują się chorobami wieku
dziecięcego. Błędy, błędy, błędy, … Klient pracując z programem jednocześnie go
testuje. Wykonując kawał dobrej, ale darmowej roboty, pomagając programiście usunąć
objawiające się komunikaty o błędach. Pal licho, jeśli to tylko błędy systemowe
związane z działaniem programu. Jeśli jednak są to pomyłki podczas wyliczeń skutki
takich sytuacji mogą być opłakane. Dodatkowa praca przy wykrywaniu i wyszukiwaniu
pomyłek, brak zaufania do systemu, konflikty z pracownikami, a w końcu spotkania
w sądach.
Poszukując optymalnego rozwiązania należy wziąć pod uwagę nie tylko ładny wygląd
interfejsu, ale też wiek aplikacji oraz też rodzaj silnika bazy danych.
Problem ten jest często pomijany, potencjalni użytkownicy nie wgłębiają się w techniczne
aspekty budowy aplikacji, a to jest ważny aspekt podczas eksploatacji systemu.
Najpopularniejsze silniki i systemy bazodanowe na których oparto programy do ewidencji
czasu pracy to Firebird, Microsoft SQL Serwer, Oracle, Paradox, MySQL,… Wybór jednej
z nich powoduje, że aplikacja na zawsze związuje się z określonym silnikiem i w
związku z tym nabiera cech, które będzie trudno zmienić programiście. Nabiera cech
pozytywnych, ale i negatywnych. Zyskuje pewne funkcjonalności, ale również traci.
Co zatem może być ważne z punktu widzenia zwykłego użytkownika? Jaką informacje
niesie za sobą wiedza o silniku bazy danych, na którym opiera się aplikacja?
Rozważania należy rozpocząć od scharakteryzowania typowego użytkownika systemu.
Osoba ta zajmuje się rozliczaniem czasu pracy pracowników, jest pracownikiem kadr,
zajmuje się wypłatami, obsługą związaną ze sprawami pracowniczymi. Nigdy nie jest
informatykiem, nigdy nie chce zajmować się zarządzaniem aplikacjami, chce, aby wszystko
działało i każdego ranka programu uruchamiały się bez problemów. Odstępstwa od tej
reguły zaburzają spokój i wprowadzają nerwową atmosferę. Doskonale, jeśli jest do
dyspozycji „firmowy” informatyk, który ogarnia wszystkie problemy. Jeśli jest, ale
dochodzący, na telefon, sprawy się komplikują. Użytkownik oczekuje systemu bezobsługowego,
w razie konieczności, wykona proste czynności samodzielnie lub według wskazówek
telefonicznych. Instalacja i pierwsze uruchomienie również nie powinno nastręczać
kłopotów. Podesłanie demo programu i samodzielna instalacja to ważny warunek udanego
początku współpracy.
Powyższe aspekty nie są brane jednak pod uwagę przez twórców programów
do ewidencji czasu pracy. W celu instalacji programu wymagany jest przyjazd
serwisanta. W razie awarii dysku, awarii połączenia sieciowego, problemu z wirusem,
przeniesieniem bazy lub serwera do innej lokalizacji wizyta płatnego serwisu jest
nieunikniona. A można tego uniknąć. Informatycy, zafascynowani technologią Microsft’a
powiedzą, że SQL Serwer jest najlepszy, a bo ma to i tamto i tu pojawia się cała
lista funkcji, o których można poczytać w Internecie. Zgoda, to narzędzie jest potężne,
nie zaprzeczę. Ale czy z punktu widzenia wygody działania pracownika działu HR ma
to znaczenie? Oto jakie pytania postawiłby, gdyby wiedział o co pytać, zwykle zna
odpowiedzi, ale dopiero gdy sam zderzy się z problemami:
- Czy można aplikację opartą na SQL Serwerze szybko przenieść na inny komputer?
- Czy można bazę danych w sposób pewny i bezpieczny zarchiwizować bez znajomości specjalistycznych
technik informatycznych i dodatkowych narzędzi?
- Czy można zaktualizować system bez konieczności stosowania dodatkowych narzędzi
informatycznych?
- Czy można samemu doinstalować kolejne końcówki klienckie, bez zbędnych działań w
konfiguracji systemu operacyjnego?
- Czy można w sposób łatwy udostępnić dane rcp bez wglądu w dane całego komputera?
- Czy czynności serwisowe związane z eksploatacją bazy są wymagane i w jakim stopniu
determinują poprawną pracę systemu?
- Czy wyżej wymienione czynności musi robić zawodowy informatyk, czy zrobi to każdy
kadrowiec?
- Czy zmiana wersji serwera wpłynie na działanie aplikacji?
- Czy sama baza danych nie ogranicza ilości przechowywanych danych?
- Czy sam silnik bazy danych jest bezpłatny, czy należy za niego dodatkowo zapłacić?
- Czy zwiększanie objętości bazy wiąże się z koniecznością zakupu płatnych wersji
bazy danych lub innych dopłat?
- Czy baza danych ogranicza liczbę końcówek klienckich i czy wymagane są dopłaty za
kolejne?
- Czy baza ogranicza nas do pracy na jednym systemie operacyjnym, czy może mamy możliwość
wyboru działania na Windows, Linux,…?
- Czy będąc wielką i znaną firmą jesteśmy pewni, że dane nie wyciekają nam furtkami
stworzonymi przez samego producenta?
Pytań jest dużo, ale warto je zadać. Trudno jest odnieść się do wszystkich znanych
baz, dlatego proponuje znaleźć plusy i minusy silnika Firebird.
Firebird to silnik baz danych na licencji open source, który został zbudowany w
oparciu o komercyjną bazę danych Interbase, i jest rozwijany już niespełna dwie
dekady. Jako projekt typu open source jest środowiskiem darmowym, użytkownicy nie
muszą za niego płacić, płaci się tylko za aplikację. Nie występuje w jednej skompilowanej
postaci, każdy na własny użytek może skompilować własną wersję wzbogaconą o dodatkowe
funkcjonalności i zabezpieczenia, tworząc własną niepowtarzalny silnik baz danych.
Bazują na tym wszystkie wielkie agencje bezpieczeństwa USA, uniwersytety, instytucje
państwowe, armia odcinając się od niepewnego w tym względzie SQL Serwera f-y Microsoft.
Unikalność instancji zwiększa bezpieczeństwo danych, gwarantuje wyłączenie wszelkich
bocznych furtek, którymi wyciekają dane. Rozwiązania komercyjne znanych producentów
takich gwarancji bezpieczeństwa nie zapewnią. Świadomi zagrożeń administratorzy
poszukują rozwiązań dających możliwość instalacji wrażliwej części systemu na doskonale
chronionym systemie, np. Linux. Solidne środowisko bazodanowe powinno oferować możliwość
wyboru instalacji części serwera na hoście z systemem Linux (Fedora, OpenSuse, CentOS,
Mandriva, Ubuntu), Windows x86/Win64, MAC OS X, Solaris, HP-UX. Jedynym znanym rozwiązaniem
oferującym tak szerokie możliwości jest… Firebird.
Czy zatem Firebird ma jakieś wady? Moim zdaniem nie. Jest świetnym narzędziem z
powodzeniem mogącym napędzić ogromne banki danych, wcale nie gorzej, niż inne, płatne
i renomowane systemy DB. Jest prosty w eksploatacji. Backup bazy można wykonać „w
locie” zwyczajnie kompresując plik bazy dostępnymi programami Zip, Rar, WinZip.
Wszystkie czynności związane z instalacją, kopiowaniem bazy, przenoszeniem programu
nie wymagają skomplikowanych, czasochłonnych, nieodpornych na błędy, uzależnionych
od istniejących sadników systemu operacyjnego czynności. Z punktu widzenia programisty
Firebird jest też bazą ze świetnie zaimplementowanym językiem SQL, płatnymi i bezpłatnymi
narzędziami IDE, wielką siecią community, doskonale przygotowaną dokumentacją. Firebird
oferuje ADO.NET, umożliwiając integrację np. z IIS Microsoft, oferując możliwość
tworzenia systemów
rejestracji czasu pracy online.
Z punktu widzenia technicznego w porównaniu z innymi darmowymi wersjami płatnych
rozwiązań jak MS SQL Express, Oracle Express, Firebird nie ogranicza wielkości bazy
danych, nie ogranicza wbudowanych funkcjonalości. Firebird umożliwia zarządzanie
bazami o wielkości 1TB!
Reasumując. Najważniejszą cechą jaka powoduje, że Firebird jest najlepszym rozwiązaniem
to brak konieczności administrowania. Administracja systemem sprowadza się do zainstalowania
silnika bazy i okresowych backupów, których wykonanie jest łatwe jak zipowanie :)),
zaoszczędzony czas proponuję spędzić na kawce...