Dziekuję Robercie za odpowiedź, mam jednak kilka "ale":
wrob pisze: "zdrowy chlopski rozum" - nie zawsze dziala - pervasive nie musi widziec struktury danych (ddf) aby moc na nich pracowac - wystarczy ze ma pliki dat - oraz aplikacja wywolujaca pervasive - w naszym wypadku symfonia - wysle do pervasive informacje z ktorej struktury (i jak ta struktura jest ulozona) i co chce uzyskac a pervasive juz sie zajmuje tylko blokowaniem pliki i rozbiciem bdrzew i indeksow w celu napelnienia pliku dat
hmm, to co opisałeś powyżej to klasyczna cecha ODBC a nie serwera. Skoro serwer nie musi znać struktury danych, żeby na nich działać a informację 'skąd' pobierać dane dostaje od klienta (w tym wypadku Symfonii) to czy chcesz powiedzieć, że pervasive oprócz "klasycznej" cechy serwera SQLowego, którą z całą pewnością posiada oferuje również mechanizm dostępu do danych zdalnym klientom w sposób identyczny jak poprzez ODBC ? Dobrze rozumiem ? tzn. "udaje" w jakis sposób zasób ?
wrob pisze: Generalnie w calym swoim poście popelniles blad w początkowym założeniu - uznałeś ze to typowy klient serwer - o to juz pociagnelo za soba lawine pytan - otoz nie jest to klient serwer w klasycznym tego slowa znaczeniu dokladniej to pervasive ma relational i transactional engine - i symfonia korzysta tylko z jednego.
Ok, posiada relational i transactional engine. A więc posiada te same mechanizmy, które mają wszystkie popularne systemy bazodanowe. Na czym więc polega wyjątkowość tych mechanizmów, że czynią pervasive "nie klasycznym" serwerem ?
Dla mnie to zabrzmiało troche tak:
"Windows nie jest klasycznym systemem operacyjnym, bo posiada również możliwość kopiowania plików".
Dodam, że cechy klasyczne jak najbardziej posiada - bez problemu łączę się z pervasivem ze zdalnych maszyn, wykonuję na nim polecenia SQLowe itd., chyba, że oprócz tego posiada jeszcze jakieś cechy o których nie wiem (?)
wrob pisze: A i nie jest to wcale zdechla technologia - w systemach czasu rzeczywistego, oraz w systemach wysokiej wydajnosci - stosuje sie głownie tego typu technologie oparte na bdrzewach i innych strukturach o liniowej złożoności gdyż sa one znacznie szybsze i maja deterministyczny czas odpowiedzi - (w porownaniu do wasko rozumianego klient serwer->SQL)
W porządku, ale nie mówimy o "tego typu" technologii w ogólnym uzyciu lecz konkretnie o pervasive i zastosowaniach biznesowych, które systemami czasu rzeczywistego nie są. Mówiąc o "zdechłości" pervasive'a miałem raczej na myśli jego rynkową agonię - poza Polską prawie nigdzie się go nie stosuje: ponoć 50% wszystkich serverów pervasive stoi właśnie w PL, kolejne 25% 2 Rosji, reszta w kilku krajach europy środkowej. Śmiem przypuszczać, że Pervasive Software "żyje" głównie dzięki sage a i tak - jak pisze kolega Rafał - sage poszło wreszcie po rozum do głowy i zastąpi go MySQLem. Szkoda, że tak późno.
OK, tak teoretyzować można by bez końca, zatem skrócę swoje pytania do jednego, ściśle symfonicznego:
Z Pervasive w jego "klasycznym" pojęciu wszystko gra: Działa, łączę sie z nim zewnetrznymi narzędziami, tworze/modyfikuję bazy - słowem ok. Natomiast wciąż nie łapię sposobu komunikacji Symfonii z Pervasive, tzn. zakładam, że sama Symfonia nie stosuje SQLa do komunikacji z bazą (stąd brak aktywnych połączeń TCP z serwerem) a ten z kolei oprócz "klasycznego" sposobu komunikacji jakim jest SQL oferuje jeszcze jakiś inny - własny mechanizm, z którym Symfonia "rozmawia". I to jest moje pierwsze pytanie - sposób komunikacji. Jeśli tak jest, to czy normą jest podczas wdrażania Symfonii w firmach, że trzeba stacjom roboczym udostepnić zasób sieciowy zawierający SH ? Pytam, ponieważ instalator stacji roboczej w żadnym momencie nie pyta o parametry połączenia z pervasivem, wymusza za to podanie lokalizacji instalacji SH.
Dziekuję za odpowedzi
Pozdr.
|