Synchronizacyjna schizofrenia

Smutna prawda jest taka, że żaden producent nie spełnia oczekiwań użytkowników, jeśli chodzi o synchronizowanie baz danych.

Smutna prawda jest taka, że żaden producent nie spełnia oczekiwań użytkowników, jeśli chodzi o synchronizowanie baz danych.

Na pierwszy rzut oka nie ma nic szczególnie interesującego w zaprezentowanych powyżej danych. Mamy tu adres, nazwę firmy i nazwisko jednego z jej pracowników. Wydaje się więc, że nie ma żadnych przeszkód, aby etykiety z tym adresem naklejać na broszury rozsyłane do klientów w ramach bezpośredniej kampanii marketingowej prowadzonej dla firmy AirFloat Manufacturing Co.

Co się jednak stanie, jeśli broszurze takiej będzie towarzyszyć osobisty list? Pan Charles Tipton jest znany np. jednemu ze sprzedawców w terenie jako "Red"; z kolei dla pracownika serwisu Charles Tipton to "Charlie". Natomiast dyrektor regionalnego biura sprzedaży zna go pod pseudonimem "Chuck". To jaki pseudonim pojawi się na nalepce adresowej zależy w tym momencie od tego, jakiej bazy danych użyto do wygenerowania adresu. A ponieważ użytkownicy wymieniają często między sobą różne prospekty i towarzyszące im informacje o klientach, to użycie akurat tego, a nie innego pseudonimu zależy po prostu od momentu, w którym dochodzi do zaadresowania listu.

Załóżmy zatem, że pracownik serwisu zmienił pseudonim rezydujący w pamięci centralnego komputera na "Charlie". Kiedy odlegli użytkownicy łączą się z bazą danych tego komputera, słowo "Charlie" zastępuje poprzednią informację, jakakolwiek by ona nie była, rezydującą w ich komputerach.

Dyrektor regionalnego biura sprzedaży zauważy tę zmianę i wprowadzi w to miejsze z powrotem słowo "Chuck". Nie muszę powtarzać, że cała ta zabawa w wymianę pseudonimów trwać może długo. Jedno jest pewne: Charles J. Tipton, który odbiera mnóstwo poczty z firmy AifFloat, nieźle się ubawi czytając korespondencję.

Nie ulega wątpliwości, że użytkownicy zmieniający czy dodający nowe dane do plików zawierających informacje o klientach powinni dysponować narzędziami, które umożliwiałyby replikowanie poszczególnych baz danych (czyli powiadamianie o tych zmianach każdego użytkownika). I to jest właśnie zadanie dla systemów sychronizujących bazy danych.

Produkowane obecnie systemy automatyzowania procesów obsługi klientów bazują na standardowych motorach baz danych, które nie oferują opcji synchronizowania baz danych. Wyjątkiem jest tu Lotus Corp. Produkowany przez tę firmę system Notes zawiera moduł replikowania danych. Szkopuł w tym, że Notes nie spełnia oczekiwań użytkowników. Powód - Notes nie dysponuje pracującą solidnie, relacyjną bazą danych.

Wielu producentów wyposaża już swoje produkty w pewne mechamizmy sychronizowania baz danych, zachwalając ich zalety. Kiedy jednak poprosimy taką firmę o zademonstrowanie nam możliwości takiej bazy danych, zaczynają się schody. Prawda jest bowiem smutna i brzmi tak: żadna z tych firm nie oferuje obecnie pracującego solidnie i co ważne niezawodnie, systemu replikowania danych. Trzeba przy tym przyznać, że niektóre produkty sprawują się już całkiem poprawnie.

A oto kilka pytań dotyczących mechanizmów synchronizowania, które należałoby zadać każdemu producentowi baz danych oferującemu tę opcję:

1. Czy system replikuje tylko te pola, których zawartość uległa zmianie podczas odczytywania ich i zapisywania przez użytkowników (pozostałe części rekordu nie powinny być w tym momencie replikowane)?

2. Czy użytkownicy wysyłają za pośrednictwem linii telefonicznej plik zawierający zmienione w rekordzie pola w określonym czasie i czy wymienione przez wszystkich użytkowników pliki są następnie synchronizowane w trybie przetwarzania wsadowego? Czy użytkownik musi się łączyć z odległym komputerem dwa razy: raz aby zapisać dane i drugi raz, aby je odczytać? Czy system dodaje do poddawanego właśnie edycji pola znacznik, która informuje pozostałych użytkowników o tym, że pole to jest właśnie zmieniane?

Co się dzieje, jeśli użytkownik połączył się z komputerem, który wykonuje akurat operację synchronizowania bazy danych? Czy zawartość oznakowanych pól jest przesyłana do odpowiednich pól centralnej bazy danych i czy użytkownicy mogą jednocześnie odczytywać zmiany wprowadzane do bazy danych przez innych użytkowników.

3. Czy użytkownicy mogą się komunikować z centralną bazą danych (w celu wprowadzenie zmian lub odczytania aktualnych danych) w sposób automatyczny, np. przez samo włączenie modemu do sieci.

4. Czy oprogramowanie radzi sobie z ewentualnymi zakłóceniami w łączności. Chodzi o to, aby w przypadku uszkodzenia łącza poddawane replikowaniu dane nie ulegały przekłamaniu, co mogłoby skończyć się tym, że zamiast słowa "Charlie" do bazy danych zapisano by słowo "Farlie".

5. Czy oprogramowanie oferuje mechanizmy śledzenia i ewidencjonowania zmian dokonywanych w bazie danych? Użytkownicy mogą wtedy sprawdzać: kto, kiedy i co zmienił w bazie danych.

6. Jak oprogramowanie radzi sobie z ewentualnymi kolizjami, które mogą powstawać w przypadku zgłaszania się do pracy z bazą danych kilku użytkowników jednocześnie? Każdy z nich może przecież próbować wstawiać do tego samego pola absolutnie różnej wartości.

Peter A. Perera jest prezydentem firmy konsultingowej The Perrera Group (Andover, Mass.).

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200