Serwer Q-SEP

Zalety:

• Transakcyjność (z podtransakcjami)
• Uruchomienie na dowolnych "Windowsach"
• Duża szybkośc wykonywania operacji podstawowych ( w tym indeksowania)
• Duża stabilność i niezawodność
• Dostępne mechanizmy backup'owania danych w czasie pracy
• Możliwość dołączenia do programu jednostanowiskowego w postaci biblioteki DLL
• Niezwykła prostota instalacji
• W liście dostępnych operacji znajdują się również operacje blokowe (multiAdd, multiDel itp)

• Nie zapamiętuje indeksów przy wyłączeniu - po każdym uruchomieniu musi je na nowo stworzyć.
• Brak mechanizmu równoległego wykonywania zleceń - w czasie wykonywania zlecenia klienta pozostali czekają na zakończenie operacji, zatem istnieje niebezpieczeństwo zawłaszczenia serwera przez jednego z klientów.

• Programy jednostanowiskowe i dema.
• Małe i średnie sieci lokalne.
• Bazy danych o tabelach poniżej 500 000 rekordów
• Instalacje poniżej 100 klientów jednocześnie pracujacych na bazie danych.

Implementacja dla Q-SEP

Serwery SQL'owe

Zalety, wady i zakres zastosowań są ogólnie znane i uczą tego na wyższych uczelniach. A ponieważ serwery SQL'owe oprócz zalet mają i wady zatem nie zawsze opłaca się ich stosowanie w praktyce. Po krótce parę z nich:

• Nie wszystkie serwery mają podtransakcje - co czyni część aplikacji bardzo trudnych do napisania.
• Brak kontroli nad sposbem wykonania zapytania, czasami powoduje iż pewne operacje trwają dużo dużo dłużej niż powinny (i co gorsza nie ma jak napisać zapytania inaczej)
• Wiele serwerów ma nieokreślony stan po dojściu na pozycję EOF lub BOF - nie ma możliwości dalszej reakcji.
• W praktyce wiele procesów trzeba wykonywać i tak procesem klienta, gdyż pewne obliczenia serwer wykonuje ŹLE lub w ogóle nie da się ich wykonać na serwerze.
• Pisanie tzw. "stored procedures" - wiąże bezpowrotnie aplikację z konkretnym serwerem SQL.
• Serwery SQL są idealne do pracy wsadowej, ale bardzo ciężko na nich zaprojektować dobry interfejs dla normalnego użytkownika, który nie chce nic wiedzieć o informatyce, chce tylko wykonywać swoją pracę. Skrajnym przykładem tu mogą być formularze HTML, w których dopiero po wciśnięciu ok dowiemy się czy to co żeśmy wpisali jest poprawne, co gorsza często musimy wpisywać to od początku w razie popełnienia jakiegoś błędu. Podpowiedzi jeśli są to małe słowniczki (do tysiąca pozycji).
• Rozwijanie aplikacji może być bardzo bardzo trudne. Jeżeli aplikacja jest oparta o całą masę zapytań SQL (często jedno na pół strony) i mamy zapytania związane z jakimś modułem w 30 różnych miejscach to przy zmianie identyfikatora np. pola ...... (życzę szczęścia!). Stąd w Q-line-3000 powstały pliki QCON, które ten problem rozwiązują.
• Każdy serwer SQL tak na prawdę wykonuje inny język SQL (nie mówimy o samej składni ale i o znaczeniu zapytań).
• W razie błędów (np w tak podstawowej operacji jak sumowanie - a są i w serwerach "dużych firm") praktycznie programista jest bezradny.
• Struktury baz trzymane są jako dane, co zaprzecza podstawowej regule, iż aplikację zawsze powinno się szybko i łatwo móc opróżnić z danych!
• .... i dużo dużo więcej (przemyślcie to!)

Implementacja dla serwerów SQL