🚀 go-pugleaf

W dniu 2015-03-29 o 23:10, Pancio pisze:
> Witam,
> Jestem na początku pisania nowej aplikacji i zastanawiam sie ktory silnik bazy danych wybrac - czy MS SQL Server Express 2008 R2 czy moze Firebird.
> Chcialem na poczatku zrobic aplikacje w miare "uniwersalna" w ktorej uzytkownik na poczatku wybieralby sobie wariant bazy danych. Jednak przez ostatni tydzien troche sobie poczytalem i roznice w budowie obu baz sa dla mnie na tyle duze, ze jednak to sobie odpuszcze. To nie to co, np. Access i MS SQL.
> Docelowo w bazie ma byc okolo 30-40 tabel (glownie slowniki) oraz powiedzmy 5 glownych tabel z liczba rekordow na poziomie 15-20 tysiecy rocznie w kazdej. Do bazy jednoczenie podpietych bedzie okolo 10 uzytkownikow. Calosc pisana jest w Delphi XE3 a do laczenia z baza uzywam AnyDACa 5.
To się da zrobić i na plikach tekstowych ;-)

> Poprzedni calkiem spory projekt mialem oparty na MS SQL i poki co klienci nie skarza sie na szeroko pojetosc "awaryjnosc".
Nie wiem jak inni, ale ja nie mam żadnych problemów pod tym kątem z MSSQL.

> Jednak gdy zobaczylem rozmiar instalki MS SQL i Firebirda 2.5 to no.... sa spore roznice.
Są, ale co z tego?
Są też i w innych miejscach, bo jednak MSSQL to nie FB. Ma znacznie 
większe możliwości (tylko czy one Ci są potrzebne?) i parę rzeczy robi 
się zupełnie inaczej.

> I teraz do Was pytanie, bo jestem w momencie pisania w ktorym jeszcze moge cos pozmieniac w kodzie programu - ktory silnik baz danych czesciej wybieracie do aplikacji komercyjnych - MS SQL (Express) czy Firebird?
> Sorry za tak banalne pytanie, ale nie chce "przedobrzyc" i waham sie troche. Zaznacze moze, ze w gre wchodza jedynie te dwie bazy, nic poza tym.
> Dzieki za podpowiedzi,
MSSQL.
Bo jest rozpoznawalny i jak klient Cię zapyta "na jakiej bazie to 
chodzi" odpowiadasz "Microsoft SQL Server" i nie ma więcej pytań.

A zdecydowanie MSSQL, kiedy Twoją grupą docelową są średnie i duże 
firmy, które pewnie już mają jakiś serwer bazy danych i jeśli to PL, to
w 80% będzie to MSSQL. A przynajmniej ja tak mam...

Jeżeli jest inaczej - zostań przy FB.

-- 
wloochacz

W dniu 2015-03-29 o 23:10, Pancio pisze:
> Witam, Jestem na początku pisania nowej aplikacji i zastanawiam sie
> ktory silnik bazy danych wybrac - czy MS SQL Server Express 2008 R2
> czy moze Firebird. Chcialem na poczatku zrobic aplikacje w miare
> "uniwersalna" w ktorej uzytkownik na poczatku wybieralby sobie
> wariant bazy danych. Jednak przez ostatni tydzien troche sobie
> poczytalem i roznice w budowie obu baz sa dla mnie na tyle duze, ze
> jednak to sobie odpuszcze. To nie to co, np. Access i MS SQL.
> Docelowo w bazie ma byc okolo 30-40 tabel (glownie slowniki) oraz
> powiedzmy 5 glownych tabel z liczba rekordow na poziomie 15-20
> tysiecy rocznie w kazdej. Do bazy jednoczenie podpietych bedzie okolo
> 10 uzytkownikow. Calosc pisana jest w Delphi XE3 a do laczenia z baza
> uzywam AnyDACa 5. Poprzedni calkiem spory projekt mialem oparty na MS
> SQL i poki co klienci nie skarza sie na szeroko pojetosc
> "awaryjnosc". Jednak gdy zobaczylem rozmiar instalki MS SQL i
> Firebirda 2.5 to no.... sa spore roznice. I teraz do Was pytanie, bo
> jestem w momencie pisania w ktorym jeszcze moge cos pozmieniac w
> kodzie programu - ktory silnik baz danych czesciej wybieracie do
> aplikacji komercyjnych - MS SQL (Express) czy Firebird? Sorry za tak
> banalne pytanie, ale nie chce "przedobrzyc" i waham sie troche.
> Zaznacze moze, ze w gre wchodza jedynie te dwie bazy, nic poza tym.
> Dzieki za podpowiedzi, -- Pancio
>

W mojej opinii główną zaletą Firebirda jest jego rozmiar i łatwość 
dystrybucji aplikacji jednostanowiskowych z Firebird w wersji embeded.
Za to brakuje mu innych rzeczy typu full-text.
No i jeszcze IBExpert, ale tylko dlatego, że mam licencje ;)

Tomek D.

No wlasnie, bo nie zaznaczylem, ze 90% klientow dla ktorych kierowana jest aplikacja korzysta już z oprogramowania opartego na MS SQL.
Powiem tak, nie norzystalem do tej pory z Firebirda, ale za to nie mam najmniejszych problemow z MS SQL majac nawet swiadomosc tego, ze nie wykorzystuje wszystkich jego mozliwosci.
Jedyne co mnie odstrasza (moze to za szumnie powiedziane) to rozmiar samej instalki. W tym przypadku Firebird bije oprogramowanie Microsoftu na glowe. Natomiast mi osobiscie bardziej przypada do gustu MS SQL szczegolnie poprzez typy danych, ktorych w Firebirdzie jest troche malo.
Ale dzieki wielkie za odpowiedz i nakierunkowanie.
--
Pancio

W dniu poniedziałek, 30 marca 2015 11:10:58 UTC+2 użytkownik Pancio napisał:

> Jedyne co mnie odstrasza (moze to za szumnie powiedziane) to rozmiar samej instalki. W tym przypadku Firebird bije oprogramowanie Microsoftu na glowe. 
Tak z naprawdę czystej ciekawości zapytam - a dlaczego rozmiar instalki ma znaczenie? 

W dniu poniedziałek, 30 marca 2015 11:31:30 UTC+2 użytkownik goo-...@ciach.net napisał:
> W dniu poniedziałek, 30 marca 2015 11:10:58 UTC+2 użytkownik Pancio napisał:
> 
> > Jedyne co mnie odstrasza (moze to za szumnie powiedziane) to rozmiar samej instalki. W tym przypadku Firebird bije oprogramowanie Microsoftu na glowe. 
> Tak z naprawdę czystej ciekawości zapytam - a dlaczego rozmiar instalki ma znaczenie?


A juz dopowiadam.
Stawiam sie w roli uzytkownika koncowego. I tak sobie patrze, ze mam dwa programy robiace IDENTYCZNIE to samo. Jedno instaluje sie (silnik + aplikacja) w minute i zajmuje 30 MB, a inne z kolei instaluje sie 20 minut i zajmuje 300 MB.
Nie raz instalowalem MS SQL i nie mialem z tym akurat problemow, natomiast sam proces instalacji Firebirda mile mnie zaskoczyl.
Jednak o wiele bardziej cenie sobie bezawaryjnosc i samo programowanie takiej bazy niz proces jej instalacji. Wszak uzytkowac to bedzie latami, a o instalce user zapomni juz na drugi tydzien.

--
Pancio

W dniu 2015-03-30 o 09:15, wloochacz pisze:
> W dniu 2015-03-29 o 23:10, Pancio pisze:

> Bo jest rozpoznawalny i jak klient Cię zapyta "na jakiej bazie to
> chodzi" odpowiadasz "Microsoft SQL Server" i nie ma więcej pytań.

Preważnie klienci maja "eskuelserwer".

> A zdecydowanie MSSQL, kiedy Twoją grupą docelową są średnie i duże
> firmy, które pewnie już mają jakiś serwer bazy danych i jeśli to PL, to
> w 80% będzie to MSSQL. A przynajmniej ja tak mam...

Rozumiem ze dorzucasz i uruchamiasz kolejna własną wersje MSSQL Server-a 
bo nie wyobrażam sobie łączenia się na sępa do nie wiadomo jakich, nie 
wiadomo jak licencjonowanych, nie wiadomo jak i do czego  używanych i 
nie wiadomo jak aktualizowanych i administrowanych już aktywnych MSSQL 
Server-ów w firmie?

miab

W dniu 2015-03-30 o 11:53, Pancio pisze:
> W dniu poniedziałek, 30 marca 2015 11:31:30 UTC+2 użytkownik goo-...@ciach.net napisał:
>> W dniu poniedziałek, 30 marca 2015 11:10:58 UTC+2 użytkownik Pancio napisał:
>>
>>> Jedyne co mnie odstrasza (moze to za szumnie powiedziane) to rozmiar samej instalki. W tym przypadku Firebird bije oprogramowanie Microsoftu na glowe.
>> Tak z naprawdę czystej ciekawości zapytam - a dlaczego rozmiar instalki ma znaczenie?
>
>
> A juz dopowiadam.
> Stawiam sie w roli uzytkownika koncowego. I tak sobie patrze, ze mam dwa programy robiace IDENTYCZNIE to samo. Jedno instaluje sie (silnik + aplikacja) w minute i zajmuje 30 MB, a inne z kolei instaluje sie 20 minut i zajmuje 300 MB.
149.9/36,6 MB wersja 32 bit Express/LocalDB
196.7/43,1 MB wersja 64 bit Express/LocalDB

Ja tu widzę od 36,6 do 196,7, no to skąd te 300 ;-)

Robia to samo, ale nie tak samo :)
Tak czy siak - MSSQL swoje waży, coś za coś.

> Nie raz instalowalem MS SQL i nie mialem z tym akurat problemow, natomiast sam proces instalacji Firebirda mile mnie zaskoczyl.
> Jednak o wiele bardziej cenie sobie bezawaryjnosc i samo programowanie takiej bazy niz proces jej instalacji. Wszak uzytkowac to bedzie latami, a o instalce user zapomni juz na drugi tydzien.

-- 
wloochacz

W dniu 2015-03-30 o 12:34, miab pisze:
> W dniu 2015-03-30 o 09:15, wloochacz pisze:
>> W dniu 2015-03-29 o 23:10, Pancio pisze:
>
>> Bo jest rozpoznawalny i jak klient Cię zapyta "na jakiej bazie to
>> chodzi" odpowiadasz "Microsoft SQL Server" i nie ma więcej pytań.
>
> Preważnie klienci maja "eskuelserwer".
>
>> A zdecydowanie MSSQL, kiedy Twoją grupą docelową są średnie i duże
>> firmy, które pewnie już mają jakiś serwer bazy danych i jeśli to PL, to
>> w 80% będzie to MSSQL. A przynajmniej ja tak mam...
>
> Rozumiem ze dorzucasz i uruchamiasz kolejna własną wersje MSSQL Server-a
> bo nie wyobrażam sobie łączenia się na sępa do nie wiadomo jakich, nie
> wiadomo jak licencjonowanych, nie wiadomo jak i do czego  używanych i
> nie wiadomo jak aktualizowanych i administrowanych już aktywnych MSSQL
> Server-ów w firmie?
A różnie to bywa; jak wiedzą co i jak, to stawiam bazę na ich instancji. 
Ale to wyjątek od reguły... zazwyczaj stawiam Expressa i po sprawie.

-- 
wloochacz

W dniu poniedziałek, 30 marca 2015 13:34:31 UTC+2 użytkownik wloochacz napisał:
> W dniu 2015-03-30 o 12:34, miab pisze:
> > W dniu 2015-03-30 o 09:15, wloochacz pisze:
> >> W dniu 2015-03-29 o 23:10, Pancio pisze:
> >
> >> Bo jest rozpoznawalny i jak klient Cię zapyta "na jakiej bazie to
> >> chodzi" odpowiadasz "Microsoft SQL Server" i nie ma więcej pytań.
> >
> > Preważnie klienci maja "eskuelserwer".
> >
> >> A zdecydowanie MSSQL, kiedy Twoją grupą docelową są średnie i duże
> >> firmy, które pewnie już mają jakiś serwer bazy danych i jeśli to PL, to
> >> w 80% będzie to MSSQL. A przynajmniej ja tak mam...
> >
> > Rozumiem ze dorzucasz i uruchamiasz kolejna własną wersje MSSQL Server-a
> > bo nie wyobrażam sobie łączenia się na sępa do nie wiadomo jakich, nie
> > wiadomo jak licencjonowanych, nie wiadomo jak i do czego  używanych i
> > nie wiadomo jak aktualizowanych i administrowanych już aktywnych MSSQL
> > Server-ów w firmie?
> A różnie to bywa; jak wiedzą co i jak, to stawiam bazę na ich instancji. 
> Ale to wyjątek od reguły... zazwyczaj stawiam Expressa i po sprawie.

Zakładam wykorzystanie instancji juz istniejacej u klienta.
Ale to tak w 50%. Wszystko wychodzi w praniu, kto tym w firmie administruje. Bo całkiem czesto dziala to w wersji 2005 Express i od lat tego nikt palcem nie tyka.
Ale czesto gesto jest tak, ze firmy maja "dosc" przyzwoity sprzet jako serwer i wtedy podpinam sie pod ich instancje, zamiast instalowac N-tego MS SQLa.
Generalnie dalej zostane przy oprogramowaniu Microsoftu. A w przyszlosci przy jakims mniejszym projekcie kto wie - moze odswieze watek Firebirda.
Dzieki za konstruktywne wypowiedzi.

--
Pancio

W dniu 2015-03-30 o 14:06, Pancio pisze:
> W dniu poniedziałek, 30 marca 2015 13:34:31 UTC+2 użytkownik
> wloochacz napisał:
>>> Rozumiem ze dorzucasz i uruchamiasz kolejna własną wersje MSSQL
>>> Server-a bo nie wyobrażam sobie łączenia się na sępa do nie
>>> wiadomo jakich, nie wiadomo jak licencjonowanych, nie wiadomo jak
>>> i do czego  używanych i nie wiadomo jak aktualizowanych i
>>> administrowanych już aktywnych MSSQL Server-ów w firmie?
>> A różnie to bywa; jak wiedzą co i jak, to stawiam bazę na ich
>> instancji. Ale to wyjątek od reguły... zazwyczaj stawiam Expressa i
>> po sprawie.
>
> Zakładam wykorzystanie instancji juz istniejacej u klienta. Ale to
> tak w 50%. Wszystko wychodzi w praniu, kto tym w firmie administruje.
> Bo całkiem czesto dziala to w wersji 2005 Express i od lat tego nikt
> palcem nie tyka. Ale czesto gesto jest tak, ze firmy maja "dosc"
> przyzwoity sprzet jako serwer i wtedy podpinam sie pod ich instancje,
> zamiast instalowac N-tego MS SQLa. Generalnie dalej zostane przy
> oprogramowaniu Microsoftu. A w przyszlosci przy jakims mniejszym
> projekcie kto wie - moze odswieze watek Firebirda. Dzieki za
> konstruktywne wypowiedzi.
>

Ten problem występuje chyba niezależnie od serwera bazy danych. Nigdy 
nie można mieć pewności czy istniejąca instancja nie zostanie 
"przekonfigurowana" przy okazji aktualizacji innego oprogramowania.
Miałem ten problem nawet z prostym Firebirdem. Dlatego od pewnego czasu 
stawiamy własną instancję, zwłaszcza że jest lekko zmodyfikowana.

Tomek D.

W dniu 2015-03-30 o 14:17, Tomek D pisze:
/ciach/
> Ten problem występuje chyba niezależnie od serwera bazy danych. Nigdy
> nie można mieć pewności czy istniejąca instancja nie zostanie
> "przekonfigurowana" przy okazji aktualizacji innego oprogramowania.
> Miałem ten problem nawet z prostym Firebirdem. Dlatego od pewnego czasu
> stawiamy własną instancję, zwłaszcza że jest lekko zmodyfikowana.
Taak... tylko jakoś nie przypominam sobie podobnych problemów w 
przypadku MSSQL, ponieważ tam większość ustawień dotyczy bazy danych, a 
nie serwera. Chociaż pewnie, wszystko da się popsuć jak się ktoś uprze...
Poza tym - nie wymagam jakiś cudów (np. dodatkowych bibliotek czy 
funkcji CLR), poza standardem.

-- 
wloochacz

Moje pytanie jest jedno, dlaczego akurat MS SQL 2008 ? A nie nowsza np. 2012/2014?

Jeśli chcesz coś darmowego z czystym sumieniem polecam PostgreSQL :)

W dniu 2015-03-29 o 23:10, Pancio pisze:
> Witam,
> Jestem na początku pisania nowej aplikacji i zastanawiam sie ktory silnik bazy danych wybrac - czy MS SQL Server Express 2008 R2 czy moze Firebird.
> Chcialem na poczatku zrobic aplikacje w miare "uniwersalna" w ktorej uzytkownik na poczatku wybieralby sobie wariant bazy danych. Jednak przez ostatni tydzien troche sobie poczytalem i roznice w budowie obu baz sa dla mnie na tyle duze, ze jednak to sobie odpuszcze. To nie to co, np. Access i MS SQL.
> Docelowo w bazie ma byc okolo 30-40 tabel (glownie slowniki) oraz powiedzmy 5 glownych tabel z liczba rekordow na poziomie 15-20 tysiecy rocznie w kazdej. Do bazy jednoczenie podpietych bedzie okolo 10 uzytkownikow. Calosc pisana jest w Delphi XE3 a do laczenia z baza uzywam AnyDACa 5.
> Poprzedni calkiem spory projekt mialem oparty na MS SQL i poki co klienci nie skarza sie na szeroko pojetosc "awaryjnosc".
> Jednak gdy zobaczylem rozmiar instalki MS SQL i Firebirda 2.5 to no.... sa spore roznice.
> I teraz do Was pytanie, bo jestem w momencie pisania w ktorym jeszcze moge cos pozmieniac w kodzie programu - ktory silnik baz danych czesciej wybieracie do aplikacji komercyjnych - MS SQL (Express) czy Firebird?
> Sorry za tak banalne pytanie, ale nie chce "przedobrzyc" i waham sie troche. Zaznacze moze, ze w gre wchodza jedynie te dwie bazy, nic poza tym.
> Dzieki za podpowiedzi,

Jeżeli baza nie jest bardzo skomplikowana da się napisać - szczególnie z 
FireDAC tak, żeby działało poprawnie z obiema bazami - FB i MS SQL. 
Trochę to upierdliwe, szczególnie jak masz procedury, ale da się. Jeden 
z małych projektów miałem przygotowany tak, że w trybie demo (kompilacja 
warunkowa) automatycznie konfigurował się pod Firebird Embedded, gdzie 
do programu dołączałem bazę z już wypełnionymi przykładowymi danymi 
(kilkanaście tysięcy rekordów), a w trybie docelowym działał z MS SQL - 
oczywiście z bazą klienta.

I właściwie taki model najczęściej wybieram - jak embedded, to Firebird, 
bo gdyby z jakiegoś powodu trzeba było (choć nie zakładam) przejść do 
wersji wielostanowiskowej to można postawić serwer. SQLite jest dobry na 
przechowanie konfiguracji, jak XML nie da rady :D

Natomiast MS SQL to wygoda, bo zwykle - jak już inni pisali - "jakiś" w 
firmie jest. Daje to wygodę administracji, szczególnie jak jest 
kontroler domeny i ludzki admin, który kontroluje dostęp grupami. Tworzę 
sobie zadania dla agenta, gdzie mam swoje backupy, dbanie o indeksy, 
powiadomienia itd. Niestety Firebird wymaga napisania tego wszystkiego w 
dodatkowej aplikacji/usłudze. Do rozwijania aplikacji kupiłem sobie 
wersję Developer Edition i mam to samo, co w Enterprise, co pozwala mi 
testować wszystko to, czego nie mam w Express - w szczególności właśnie 
agenta, pocztę itd.

Sama wersja Express jest świetna i przecież można zrobić nienadzorowaną 
instalację, użytkownik niczego nie musi konfigurować, samo się robi. 
Wyrzucając BLOBy do FILESTREAMa rozmiar bazy w Expressie wystarcza na 
naprawdę dużą ilość danych. Tym, co tak naprawdę ogranicza w tej wersji 
jest RAM dla instancji serwera.

Myślę, że właśnie wersją Express Microsoft wykosił konkurencję do takich 
mniejszych projektów c-s. Podobnie jak z Visual Studio Community, które 
mam właśnie odpalone do testów i tak się zastanawiam, czy jest sens 
wywalania kilku tysięcy na upgrade mojego staruszka Delphi XE2 do 
nowego... :)

jh

On 2015-03-31 00:40, jh wrote:
> W dniu 2015-03-29 o 23:10, Pancio pisze:
>> Witam,
>> Jestem na początku pisania nowej aplikacji i zastanawiam sie ktory
>> silnik bazy danych wybrac - czy MS SQL Server Express 2008 R2 czy moze
>> Firebird.
>> Chcialem na poczatku zrobic aplikacje w miare "uniwersalna" w ktorej
>> uzytkownik na poczatku wybieralby sobie wariant bazy danych. Jednak
>> przez ostatni tydzien troche sobie poczytalem i roznice w budowie obu
>> baz sa dla mnie na tyle duze, ze jednak to sobie odpuszcze. To nie to
>> co, np. Access i MS SQL.
>> Docelowo w bazie ma byc okolo 30-40 tabel (glownie slowniki) oraz
>> powiedzmy 5 glownych tabel z liczba rekordow na poziomie 15-20 tysiecy
>> rocznie w kazdej. Do bazy jednoczenie podpietych bedzie okolo 10
>> uzytkownikow. Calosc pisana jest w Delphi XE3 a do laczenia z baza
>> uzywam AnyDACa 5.
>> Poprzedni calkiem spory projekt mialem oparty na MS SQL i poki co
>> klienci nie skarza sie na szeroko pojetosc "awaryjnosc".
>> Jednak gdy zobaczylem rozmiar instalki MS SQL i Firebirda 2.5 to
>> no.... sa spore roznice.
>> I teraz do Was pytanie, bo jestem w momencie pisania w ktorym jeszcze
>> moge cos pozmieniac w kodzie programu - ktory silnik baz danych
>> czesciej wybieracie do aplikacji komercyjnych - MS SQL (Express) czy
>> Firebird?
>> Sorry za tak banalne pytanie, ale nie chce "przedobrzyc" i waham sie
>> troche. Zaznacze moze, ze w gre wchodza jedynie te dwie bazy, nic poza
>> tym.
>> Dzieki za podpowiedzi,
>
> Jeżeli baza nie jest bardzo skomplikowana da się napisać - szczególnie z
> FireDAC tak, żeby działało poprawnie z obiema bazami - FB i MS SQL.
> Trochę to upierdliwe, szczególnie jak masz procedury, ale da się.

Tu pomaga warstwowy model aplikacji, który jest mocno ograniczony w 
Delphi, Ja się go dopiero w Javie nauczyłem.

Chodzi o to żeby nie używać bezpośrednio bazy danych i SQLi z logiki 
biznesowej, ale wołać odpowiednie metody z serwisów DAO (serwis 
rozumiany jako klasa w aplikacji, singleton, DAO => data access object). 
Zaś same serwisy DAO aplikacji znane są tylko poprzez interfejsy, a dla 
każdego typu bazy jest osobna implementacja. I to tylko ta implementacja 
musi wiedzieć jak się dogadać z bazą, w Javie zwracając logice 
biznesowej albo pojedyncze dane (jak count, itp) czy kolekcje obiektów, 
a w Delphi TDatasety, jeśli ORM Ci nie pasuje.

Fakt, wymaga to więcej pracy. Ale potem jest się w zasadzie niezależnym 
od bazy danych, zawsze można stosunkowo niskim kosztem dopisać kod dla 
nowej bazy. Zresztą zazwyczaj nie ma dużo pisania, bo implementacje 
serwisów DAO dla konkretnych baz najczęściej dziedziczą z jednej bazowej 
klasy, która implementuje wszystko współdzielone, dialekty SQL nie są aż 
tak bardzo różne.
Co więcej, jeśli jakaś baza nie realizuje konkretnej funkcjonalności, 
można ją emulować w samym serwisie DAO. Np dla MSSQLa pewna funkcja może 
być procedurą składowaną, ale dla SQLite tą samą funkcjonalność zrobisz 
w kodzie.

http://pl.wikipedia.org/wiki/Data_Access_Object
http://en.wikipedia.org/wiki/Data_access_object

-- 
Arivald

W dniu 2015-03-31 o 08:08, Arivald pisze:

>> Jeżeli baza nie jest bardzo skomplikowana da się napisać - szczególnie z
>> FireDAC tak, żeby działało poprawnie z obiema bazami - FB i MS SQL.
>> Trochę to upierdliwe, szczególnie jak masz procedury, ale da się.
>
> Tu pomaga warstwowy model aplikacji, który jest mocno ograniczony w
> Delphi, Ja się go dopiero w Javie nauczyłem.
>
> Chodzi o to żeby nie używać bezpośrednio bazy danych i SQLi z logiki
> biznesowej, ale wołać odpowiednie metody z serwisów DAO (serwis
> rozumiany jako klasa w aplikacji, singleton, DAO => data access object).
> Zaś same serwisy DAO aplikacji znane są tylko poprzez interfejsy, a dla
> każdego typu bazy jest osobna implementacja. I to tylko ta implementacja
> musi wiedzieć jak się dogadać z bazą, w Javie zwracając logice
> biznesowej albo pojedyncze dane (jak count, itp) czy kolekcje obiektów,
> a w Delphi TDatasety, jeśli ORM Ci nie pasuje.
>
> Fakt, wymaga to więcej pracy. Ale potem jest się w zasadzie niezależnym
> od bazy danych, zawsze można stosunkowo niskim kosztem dopisać kod dla
> nowej bazy. Zresztą zazwyczaj nie ma dużo pisania, bo implementacje
> serwisów DAO dla konkretnych baz najczęściej dziedziczą z jednej bazowej
> klasy, która implementuje wszystko współdzielone, dialekty SQL nie są aż
> tak bardzo różne.
> Co więcej, jeśli jakaś baza nie realizuje konkretnej funkcjonalności,
> można ją emulować w samym serwisie DAO. Np dla MSSQLa pewna funkcja może
> być procedurą składowaną, ale dla SQLite tą samą funkcjonalność zrobisz
> w kodzie.
>
> http://pl.wikipedia.org/wiki/Data_Access_Object
> http://en.wikipedia.org/wiki/Data_access_object


Na poziomie samego połączenia i datasetów FireDAC też mocno ułatwia taką 
pracę. Ja mam taką mini fabrykę do połączeń, która preparuje odpowiednie 
parametry w zależności od bazy (tcp/local/embedded/typ/baza/autentykacja 
itd.), a ustawienia są trzymane np. w XML. W datasetach FireDAC/AnyDAC 
mam makra, kod warunkowy zależny od RDBMS. Wystarczy te SQLe trzymać 
poza datasetami w kodzie/bazie/plikach, pola definiować w runtime itd. 
Do tego mapowanie typów począwszy od połączenia, dziedziczone przez 
datasety. Jak się to obsłuży fabryką datasetów i połączeń to pomimo 
poświęcenia czasu na kodowanie zamiast wyklikanie wszystkiego na 
DataModule będzie fajnie działać.

jh

W dniu 2015-03-31 o 00:40, jh pisze:
/ciach/

> Jeżeli baza nie jest bardzo skomplikowana da się napisać - szczególnie z
> FireDAC tak, żeby działało poprawnie z obiema bazami - FB i MS SQL.
> Trochę to upierdliwe, szczególnie jak masz procedury, ale da się. Jeden
> z małych projektów miałem przygotowany tak, że w trybie demo (kompilacja
> warunkowa) automatycznie konfigurował się pod Firebird Embedded, gdzie
> do programu dołączałem bazę z już wypełnionymi przykładowymi danymi
> (kilkanaście tysięcy rekordów), a w trybie docelowym działał z MS SQL -
> oczywiście z bazą klienta.
>
> I właściwie taki model najczęściej wybieram - jak embedded, to Firebird,
> bo gdyby z jakiegoś powodu trzeba było (choć nie zakładam) przejść do
> wersji wielostanowiskowej to można postawić serwer.
Nie rozumiem, dlaczego nie wybrałeś SQLLocalDB do demo i nie musiałbyś 
się męczyć z utrzymaniem dwóch silników baz - zwłaszcza, że jeden z nich 
to de-facto demo.
Może i SQLLocalDB waży te ok. 40 MB, ale mam pełną (na poziomie RDBMS i 
T-SQL) zgodność z dużym i małym MSSQL.

> SQLite jest dobry na
> przechowanie konfiguracji, jak XML nie da rady :D
Nie masz racji.

/ciach/

-- 
wloochacz

W dniu 2015-03-31 o 09:48, wloochacz pisze:

>> I właściwie taki model najczęściej wybieram - jak embedded, to Firebird,
>> bo gdyby z jakiegoś powodu trzeba było (choć nie zakładam) przejść do
>> wersji wielostanowiskowej to można postawić serwer.
> Nie rozumiem, dlaczego nie wybrałeś SQLLocalDB do demo i nie musiałbyś
> się męczyć z utrzymaniem dwóch silników baz - zwłaszcza, że jeden z nich
> to de-facto demo.
> Może i SQLLocalDB waży te ok. 40 MB, ale mam pełną (na poziomie RDBMS i
> T-SQL) zgodność z dużym i małym MSSQL.

Masz rację, u mnie to zaszłość z czasu sprzed Denali, do Compacta AnyDAC 
się nie łączył bez dodatkowych sterowników, stąd Firebird jako embedded. 
Potem (LocalDB) nie zmieniałem kodu i tak zostało. Może faktycznie pora 
na zmianę. Tu w wątku bardziej chodziło mi o wskazanie, że dzięki 
FireDAC spokojnie można zrobić aplikację pod różne RDBMS.

>> SQLite jest dobry na
>> przechowanie konfiguracji, jak XML nie da rady :D
> Nie masz racji.

Dałem smile'a. Tak naprawdę to nie skończyłem niczego w SQLite, zawsze 
mi brakowało jakiejś funkcjonalności. Choć ostatnio, kiedy testowałem 
nowe XE7, to testową apkę na iOS/Androida/Maca/Windowsa oparłem właśnie 
o SQLite i nawet działało :)

jh

W dniu 2015-03-31 o 09:48, wloochacz pisze:
> Nie rozumiem, dlaczego nie wybrałeś SQLLocalDB do demo i nie musiałbyś

> Może i SQLLocalDB waży te ok. 40 MB, ale mam pełną (na poziomie RDBMS i
> T-SQL) zgodność z dużym i małym MSSQL.
>
Tak z ciekawości, nie masz już do czynienia z XP, nie musisz zwracać 
uwagi, czy program na nim ruszy?

W dniu 2015-04-01 o 00:48, ktos pisze:
> W dniu 2015-03-31 o 09:48, wloochacz pisze:
>> Nie rozumiem, dlaczego nie wybrałeś SQLLocalDB do demo i nie musiałbyś
>
>> Może i SQLLocalDB waży te ok. 40 MB, ale mam pełną (na poziomie RDBMS i
>> T-SQL) zgodność z dużym i małym MSSQL.
>>
> Tak z ciekawości, nie masz już do czynienia z XP, nie musisz zwracać
> uwagi, czy program na nim ruszy?
Mam, incydentalnie.
Sam program ruszy i działa bez problemu na XP, ale już SQLLocalDB nie. W 
takim przypaku, jeśli się kto uprze, stawiam pełenego MSSQLa w wersji 
2008 R2.

-- 
wloochacz