Discussion:
Przerobienie MS Access na Firebird
(Wiadomość utworzona zbyt dawno temu. Odpowiedź niemożliwa.)
Pancio
2010-04-08 13:52:26 UTC
Permalink
Witam,
Nie mam zbytniego doświadczenia w pisaniu programów bazodanowych, a jakiś
czas temu zacząłem tworzyć aplikację opartą na bazie danych Accessa.
I pytanie do znawców tematu.
Czy nie znająć SQLa (lub znając w stopniu więcej niż podstawowym) można w
jakiś w miarę łatwy i bezbolesny sposób przejść z bazy utworzonej w Accessie
na serwer Firebirda?
Nie przeszkadza mi Access - łatwo tworzy się w nim tabele, relacje, etc... Z
tym, że z aplikacji korzystać będzie około 10 użytkowników jednocześnie, a
baza zawierać będzie kilkanaście tabel z czego największa mieć będzie
docelowo kilkanaście tysięcy rekordów.
AnyDAC na pewno jest pomocnym rozwiazaniem, ale nie chcialbym, aby w miarę
rozrostu bazy nagle zdarzył się "zonk" i wsystkie dane rozsypią się.
Często chwali się Firebirda właśnie za stabilność. O ile wybór serwera SQL
jest jak dla mnie-laika dowolny (byle darmowy) o tyle o wiele bardziej ważne
jest, czy przesiadka i przyzwyczajenia obsługi bazy w Accessie różnią się
znacząco od Firebirda.
Na marginesie tylko dodam, że całość obsługuję z poziomu Delphi 7.

Oczywiście wszystkiego można się nauczyć, ale z uwagi, że działam lekko pod
presją czasu, dlatego stawiam na prostotę a tutaj Access jest dość dobrym
rozwiązaniem. Może nie do końca stabilnym, ale łatwym z punktu obsługi samej
bazy w Delphi.
Ten kto napisał chociaż najprostszą aplikację bazodanową opartą np. na
Firebirdzie, ten powie, że to pestka. Natomiast nie znam się na serwerach
SQL (pobrałem Firebirda, zainstalowałem i pół dnia zastanawiałem się "o co
chodzi").

Dzięki wielkie za odpowiedzi i sugestie.
Witek.
jh
2010-04-08 14:24:12 UTC
Permalink
Proponuję MS SQL Express 2008. Darmowe, razem z serwerem dostajesz darmowe
narzędzie do zarządzania serwerem, tworzeniem baz - graficznie, jak w
Accessie. Znacznie więcej typów danych niż w Firebird, i silnik chyba
znacznie wydajniejszy. Nie to, żebym mial coś do FB, ale odkąd zmieniłem FB
na MS SQL to jakoś tak łatwiej wiele rzeczy zrobić... Pewnie to
nieobiektywne, ale tak mam ;)

jh


__________ Informacja programu ESET NOD32 Antivirus, wersja bazy sygnatur wirusow 5010 (20100408) __________

Wiadomosc zostala sprawdzona przez program ESET NOD32 Antivirus.

http://www.eset.pl lub http://www.eset.com
Eugeniusz Rink
2010-04-08 20:56:50 UTC
Permalink
Post by jh
Proponuję MS SQL Express 2008. Darmowe, razem z serwerem dostajesz
darmowe narzędzie do zarządzania serwerem, tworzeniem baz - graficznie,
jak w Accessie. Znacznie więcej typów danych niż w Firebird, i silnik
chyba znacznie wydajniejszy. Nie to, żebym mial coś do FB, ale odkąd
zmieniłem FB na MS SQL to jakoś tak łatwiej wiele rzeczy zrobić...
Pewnie to nieobiektywne, ale tak mam ;)
jh
__________ Informacja programu ESET NOD32 Antivirus, wersja bazy
sygnatur wirusow 5010 (20100408) __________
Wiadomosc zostala sprawdzona przez program ESET NOD32 Antivirus.
http://www.eset.pl lub http://www.eset.com
Tak.. to postaw MS SQLa np na Linuxie, o innych wybiegach licencyjnych
już nie wspomnę...


Eugeniusz Rink
jh
2010-04-08 22:05:01 UTC
Permalink
Post by Eugeniusz Rink
Post by jh
Proponuję MS SQL Express 2008. Darmowe, razem z serwerem dostajesz
darmowe narzędzie do zarządzania serwerem, tworzeniem baz - graficznie,
jak w Accessie. Znacznie więcej typów danych niż w Firebird, i silnik
chyba znacznie wydajniejszy. Nie to, żebym mial coś do FB, ale odkąd
zmieniłem FB na MS SQL to jakoś tak łatwiej wiele rzeczy zrobić...
Pewnie to nieobiektywne, ale tak mam ;)
Tak.. to postaw MS SQLa np na Linuxie,
A po co? Skoro pytacz ma Delphi i Accessa, to raczej wskazuje to na
Windowsa, niż na Linuxa...
Post by Eugeniusz Rink
o innych wybiegach licencyjnych już nie wspomnę...
Na przykład? Jedynym nie technicznym ograniczeniem wersji Express jest zakaz
używania tej wersji w celach hostingowych-komercyjnych. A jakie to wybiegi
licencyjne masz na myśli?

jh


__________ Informacja programu ESET NOD32 Antivirus, wersja bazy sygnatur wirusow 5011 (20100408) __________

Wiadomosc zostala sprawdzona przez program ESET NOD32 Antivirus.

http://www.eset.pl lub http://www.eset.com
Eugeniusz Rink
2010-04-09 07:24:37 UTC
Permalink
Post by jh
A po co? Skoro pytacz ma Delphi i Accessa, to raczej wskazuje to na
Windowsa, niż na Linuxa...
Też tak kiedyś myślałem ale życie zweryfikowało mój światopogląd na ten
temat, jak kilku klientów zapytało o Linuxa...więc po co się ograniczać?
Zresztą za Linuxem przemawia kilka argumentów.

- Stabilność
- Bezpieczeństwo (brak wirusów i innych śmieci odpadają "wątpliwe"
programy antywirusowe które dodatkowo generują koszta oraz obciążają system)
- Może pracować na sprzęcie o gorszych parametrach (brak X-ów)
- Wydajność
- Mniejsze koszty wdrożenia oraz utrzymania serwera (pracuje
bezobsługowo z darmowymi serwerami baz danych takimi jak Firebird czy
też PostgreSQL)
- możliwość zdalnego zarządzania (via SSH + WAN)
Post by jh
o innych wybiegach licencyjnych już nie wspomnę...
Na przykład? Jedynym nie technicznym ograniczeniem wersji Express jest
zakaz używania tej wersji w celach hostingowych-komercyjnych. A jakie to
wybiegi licencyjne masz na myśli?
Może źle nazwałem tę część tematu, ale zdaje się, że są ograniczenia w
wielkości bazy oraz jednoczesnego podłączenia się większej ilości
klientów do bazy...? Chyba, że w tej wersji się coś zmieniło...


ER
wloochacz
2010-04-09 08:24:57 UTC
Permalink
Post by Eugeniusz Rink
Post by jh
A po co? Skoro pytacz ma Delphi i Accessa, to raczej wskazuje to na
Windowsa, niż na Linuxa...
Też tak kiedyś myślałem ale życie zweryfikowało mój światopogląd na ten
temat, jak kilku klientów zapytało o Linuxa...więc po co się ograniczać?
Zresztą za Linuxem przemawia kilka argumentów.
- Stabilność
Mit.
Miałem do niedawna serwer 2000, który miał uptime po 4, 5 lat.
I był to serwer na którym działy dwie instancje MSSQL, obsługujące
kilkanaście baz. Do tego jeszcze jakieś inne pomniejsze usługi (faxy,
integracja, itp.).
Został wymieniony z jednego powodu - uszkodzony dysk w macierzy no i
sprzęt już się trochę zdewaluował.
Znaczy, że Windows nie jest stabilny?
Post by Eugeniusz Rink
- Bezpieczeństwo (brak wirusów i innych śmieci odpadają "wątpliwe"
programy antywirusowe które dodatkowo generują koszta oraz obciążają system)
Kolejny mit.
Nikt normalny nie otwiera stron niewiadomego pochodzenia na serwerze...
Może nie uwierzysz, ale ja nigdy nie mailem antywirusa bo uważałem to za
zbędne. I co? I nic - komputer czysty, po okresowych skanowaniach...
dziwne, prawda?
Post by Eugeniusz Rink
- Może pracować na sprzęcie o gorszych parametrach (brak X-ów)
A po co, skoro to jest serwer a nie popierdółka?
Post by Eugeniusz Rink
- Wydajność
Bzdura.
Wydajność MSSQL w stosunku do FB na tym samym sprzęcie i przy tych
samych danych jest dużo wyższa.
Post by Eugeniusz Rink
- Mniejsze koszty wdrożenia oraz utrzymania serwera (pracuje
bezobsługowo z darmowymi serwerami baz danych takimi jak Firebird czy
też PostgreSQL)
Kolejny mit - MSSQL i podobne posiadają funkcjonalność typu "self
tuning". Oczywiście i FB po instalacji działa, tyle że MSSQL działa
lepiej - beż żadnego grzebania w konfiguracji.
Poza tym o porównywaniu możliwości silnika lepiej nie wspominać, bo nie
ma czego porównywać - nawet w wersji Express FB zostaje w tyle.
Post by Eugeniusz Rink
- możliwość zdalnego zarządzania (via SSH + WAN)
O maaatko...
A na platformie Windows tego nie ma? VIA RDP lub VPN?
Post by Eugeniusz Rink
Post by jh
o innych wybiegach licencyjnych już nie wspomnę...
Na przykład? Jedynym nie technicznym ograniczeniem wersji Express jest
zakaz używania tej wersji w celach hostingowych-komercyjnych. A jakie to
wybiegi licencyjne masz na myśli?
Może źle nazwałem tę część tematu, ale zdaje się, że są ograniczenia w
wielkości bazy oraz jednoczesnego podłączenia się większej ilości
klientów do bazy...? Chyba, że w tej wersji się coś zmieniło...
Zgadza się - zdawało Ci się.
Ograniczenie na wielkość bazy jest, na ilość userów nie ma.
--
wloochacz
Bogdan Polak (BSC)
2010-04-09 09:29:34 UTC
Permalink
Mit. Mit. ....
Trochę się rozpędziłeś kolego z tymi mitami.

Moim zdaniem nie można porównywać serwera open-source z komercyjnym
serwerem. Bo SQL Server-a Express logicznie myślący biznesmen nie
potraktuje poważnie jako platformę "na lata" - to tylko taki "hłyt
maketingowy" z odroczoną płatnością. Zapłacić za licencje trzeba będzie,
ale trochę później. Ten "hłyt" pozwala przenieść koszt licencyjny
serwera SQL z fazy wdrożenia (firma deweloperska) na fazę utrzymania
(nie koniecznie firma deweloperska) - co może być wygodne dla dewelopera.

Osobiście nie jestem zwolennikiem oszczedzania na platformie
bazodanowej, ale nie zmienia to faktu, że są całkiem sensowne systemy
biznesowe dla których Firebird i MySQL wystarczają jak platformy
bazodanowe na długie lata. Co więcej założyłbym się, że dla większości
(czyli ponad połowy) komercyjnych produktów stworzonych przez
grupowiczów platformy open-source są wystarczające.

Tak czy inaczej porównujesz dwie różne klasy serwerów.

A tak na marginesie to powiem Ci, że miałeś szczęscie z tym swoim
MSSQL-em na serwerze 2000, bo ja dosyć często słyszę narzekania klientów
na problemy z "utrzymaniem logów", z którym od czasu do czasu "coś" się
dzieje. Oczywiście zależy to od tego jak masz napisany kod i jak wiele
rollbacków robisz i ile równoczesnych transakcji masz. Jak znam Twoje
podejście to nie potrzebujesz rollback-ów i może dzięki temu miałeś taki
"experience", ale nie wyciągaj z tego zbyt ogólnych wniosków.

Różnica klas nie polega jedynie na cenie, ale również na segmencie. Bazy
takie jak Firebird i MySQL to rozwiązania typu embeded (czyli wdrzażane
z aplikacją - jedna aplikacja, jeden serwer), a SQL Server pretenduje do
klasy baz Enterprise, czyli: jedna firma - jeden serwer.

Bogdan
wloochacz
2010-04-09 10:31:36 UTC
Permalink
Post by Bogdan Polak (BSC)
Mit. Mit. ....
Trochę się rozpędziłeś kolego z tymi mitami.
Oh, really?
Post by Bogdan Polak (BSC)
Moim zdaniem nie można porównywać serwera open-source z komercyjnym
serwerem.
True, ale nie ja zacząłem tę bezensowna dyskusję.
Post by Bogdan Polak (BSC)
Bo SQL Server-a Express logicznie myślący biznesmen nie
potraktuje poważnie jako platformę "na lata" - to tylko taki "hłyt
maketingowy" z odroczoną płatnością.
IMO, jest dokładnie odwrotnie. Dla większości MSP wystarczy wersja
Express, która doskonale sobie poradzi z obciążeniem i 3x większym niż
podaje pytacz.

Ostatnio byłem w fabryce, w której to działa ERP na Oracle 10g.
Pytam się Admina, ilu użytkowników mają i jak im to działa.
Odpowiada - dużo; 20 licencji (z czego w tym samym czasie działa ok
70%), dedykowany serwer na bazę Oracle w wersji 64 bitowe, 8 GB RAMu,
baza ok. 2GB - jeżeli to jest dużo, to ja jestem...
Dlaczego taka konfiguracja?
Bo producent oprogramowania stwierdził, że przy takim obciążeniu nie
będzie działało to wydajnie - i faktycznie, działało słabo - obecnie lepiej.
Poza tym aplikacja napisana w Delphi i to raczej... tragicznie; po
kilkunastu minutach zabawy, odechciało mi się bliższego spotkania na
dłużej z tym systemem, generuje tak mnóstwo niepotrzebnej komunikacji z
bazą, że niejeden ORM by się zawstydził.
No ja przepraszam, ale faktycznie nie sztuką jest sprzedać dobry system,
tylko drogi.

Poza tym, odroczona płatność dla biznesu jest atrakcyjna. Czasem dla
sprzedającego, a czasem dla kupującego.
Post by Bogdan Polak (BSC)
Zapłacić za licencje trzeba będzie,
ale trochę później. Ten "hłyt" pozwala przenieść koszt licencyjny
serwera SQL z fazy wdrożenia (firma deweloperska) na fazę utrzymania
(nie koniecznie firma deweloperska) - co może być wygodne dla dewelopera.
Błąd.
Dla Develeoperów jest wersja Developer lub Microsoft Empower,
ewentualnie MAPS.
www.microsoft.com/sqlserver/2008/en/us/Developer.aspx
Developer Edition kosztuje tyle co nic i każdego na niego stać - poważnie.
Post by Bogdan Polak (BSC)
Osobiście nie jestem zwolennikiem oszczedzania na platformie
bazodanowej, ale nie zmienia to faktu, że są całkiem sensowne systemy
biznesowe dla których Firebird i MySQL wystarczają jak platformy
bazodanowe na długie lata.
Fireird - zgoda, MySQL...
Post by Bogdan Polak (BSC)
Co więcej założyłbym się, że dla większości
(czyli ponad połowy) komercyjnych produktów stworzonych przez
grupowiczów platformy open-source są wystarczające.
Oczywiście, że są.
Post by Bogdan Polak (BSC)
Tak czy inaczej porównujesz dwie różne klasy serwerów.
Bo dałem się podpuścić ;0)
Post by Bogdan Polak (BSC)
A tak na marginesie to powiem Ci, że miałeś szczęscie z tym swoim
MSSQL-em na serwerze 2000, bo ja dosyć często słyszę narzekania klientów
na problemy z "utrzymaniem logów", z którym od czasu do czasu "coś" się
dzieje.
Ciekawe, wynika z tego że ja ciągle mam szczęście...
To nie jest problem serwera, tylko jego konfiguracji.
Może poleć osobom odpowiedzialny za utrzymanie tych serwerów zapoznanie
się z tym dokumentem:
http://msdn.microsoft.com/en-us/library/ms175987.aspx
Post by Bogdan Polak (BSC)
Oczywiście zależy to od tego jak masz napisany kod i jak wiele
rollbacków robisz i ile równoczesnych transakcji masz. Jak znam Twoje
podejście to nie potrzebujesz rollback-ów i może dzięki temu miałeś taki
"experience", ale nie wyciągaj z tego zbyt ogólnych wniosków.
Na tym serwerem nie działało tylko moje oprogramowanie - w sumie, to
moje generowało jakieś 20% obciążenia dla bazy. Reszta to aplikacje firm
trzecich. Ja tylko odpowiednio skonfigurowałem recovery model i
wdrożyłem politykę wykonywania kopii bezpieczeństwa.
Post by Bogdan Polak (BSC)
Różnica klas nie polega jedynie na cenie, ale również na segmencie. Bazy
takie jak Firebird i MySQL to rozwiązania typu embeded (czyli wdrzażane
z aplikacją - jedna aplikacja, jeden serwer), a SQL Server pretenduje do
klasy baz Enterprise, czyli: jedna firma - jeden serwer.
Nie każda jego wersja.
Wersja Express śmiało może konkurować z każdym serwerem open sourcem
wersje Standard z każdą małą bazą komercyjną - np. z Interbase - cenowo
również.
--
wloochacz
Bogdan Polak (BSC)
2010-04-09 10:49:13 UTC
Permalink
Post by wloochacz
Wersja Express śmiało może konkurować z każdym serwerem
open sourcem wersje Standard z każdą małą bazą komercyjną -
np. z Interbase - cenowo również.
A tutaj już poszedłeś po krawędzi (ang. "on-the-edge"). ;-)
Może porównajmy footprint FB i SQL Servera 2008 Express - wliczając w to
zastartowanie dotnetowego frameworka. SQL Server nie ma najmniejszych
szans, a dla baz segmentu embeded footprint to podstawowy wskaźnik.

Poza tym instalacja w "tybie silent" FB jest dziecinnie prosta, może to
zrobić nawet sama aplikacja kliencka (start serwera w trybie
interaktywnym - konsolowym bez konsoli), a na serwerze można można
odpalić RDBMS z płyty CD lub pendriva. To zdecydowanie poprawia wrażenie
pierwszego kontaktu z aplikacją, np. wersją trial pobieraną ze strony WWW.

Myślę, że jednak masz za duży kontakt z bazami klasy enterprise. Jakbyś
robił soft "na półkę" to widziałbyś te aspekty inaczej. Chociaż zaraz
zaraz, przecież masz zebrę - jak tam kiedy nowa wersja? ;-)

Bogdan
wloochacz
2010-04-09 11:50:35 UTC
Permalink
Post by Bogdan Polak (BSC)
Post by wloochacz
Wersja Express śmiało może konkurować z każdym serwerem
open sourcem wersje Standard z każdą małą bazą komercyjną -
np. z Interbase - cenowo również.
A tutaj już poszedłeś po krawędzi (ang. "on-the-edge"). ;-)
Może porównajmy footprint FB i SQL Servera 2008 Express - wliczając w to
zastartowanie dotnetowego frameworka.
W który, w miarę nowym, Windowsie nie ma .NET?
Post by Bogdan Polak (BSC)
SQL Server nie ma najmniejszych
szans, a dla baz segmentu embeded footprint to podstawowy wskaźnik.
Tak, a dlaczego?
Post by Bogdan Polak (BSC)
Poza tym instalacja w "tybie silent" FB jest dziecinnie prosta, może to
zrobić nawet sama aplikacja kliencka (start serwera w trybie
interaktywnym - konsolowym bez konsoli), a na serwerze można można
odpalić RDBMS z płyty CD lub pendriva. To zdecydowanie poprawia wrażenie
pierwszego kontaktu z aplikacją, np. wersją trial pobieraną ze strony WWW.
Wiesz, ja nie robię programów które uruchamiają się z "pyty".
Jak zacznę, to użyję FB ale na pewno nie "cudownego" MySQL.
Poza tym tak jakby bogactwo SQL i sam silni to innan klasa - chociażby
automatyczne zarządzeni statystykami czy optymalizator.
Po prosty MS SQL działa lepiej, szybciej.
Post by Bogdan Polak (BSC)
Myślę, że jednak masz za duży kontakt z bazami klasy enterprise. Jakbyś
robił soft "na półkę" to widziałbyś te aspekty inaczej.
Robię, ale na ms sql server express 2008.
Ciekawe, że tacy producenci jak Insert, Soneta, Sage Symfonia Forte czy
WAPRO nie podzielają Twoich wniosków. Wszyscy Ci głupcy jadą na MS SQL
Server w wersji Express - i to tylko Ci nasi.
Post by Bogdan Polak (BSC)
Chociaż zaraz
zaraz, przecież masz zebrę - jak tam kiedy nowa wersja? ;-)
Zdechła.
Nowej wersji nie będzie, bo mam inne zajęcia :-)
--
wloochacz
jh
2010-04-09 09:25:40 UTC
Permalink
Post by Eugeniusz Rink
Post by jh
A po co? Skoro pytacz ma Delphi i Accessa, to raczej wskazuje to na
Windowsa, niż na Linuxa...
Też tak kiedyś myślałem ale życie zweryfikowało mój światopogląd na ten
temat, jak kilku klientów zapytało o Linuxa...więc po co się ograniczać?
Przypominam, że rozmawiamy o bazie danych, nie o systemie operacyjnym. Po co
toczyć kolejne wojny, co lepsze - Linux czy Windows? Powiem krótko - mam
sieć domenową, z Active Directory, Exchangem, oprogramowaniem na MS SQL,
wszyscy pracują na Windowsach, nam się bardzo dobrze to administruje, bo
środowisko jest spójne, wygodne w zarządzaniu - wszelkie dobrodziejstwa
zarządzania Active Directory są nie do przecenienia. Za kilka miesięcy
stanie kolejny duży system również oparty na MS SQL (dostawca odchodzi od
Oracle'a) i jakoś nie znajduję argumentów, żeby męczyć się na Linuxie w imię
braku wirusów etc. Za wirusy z sieci odpowiedzialny jest sprzęt Fortigate'a
przy połączeniu z WANem, za stacje lokalne serwerowa wersja antywirusa, poza
tym zasada - nikt nie pracuje na serwerze na co dzień, a zadania
administracyjne można zrobić zdalnie - RDP (architektura stoi na vSphere
VMWare), po KVM wchodzę tylko jeśli muszę do paru sprzętowych gratów, w tym
do ESXów, jak mam taką potrzebę. Więc argument zdalnego zarządzania jest
żaden, bo jeśli z poza pracy chcę zrobić cokolwiek to mam serwer terminali
(MS), VPN etc. Koszty - owszem to kosztuje, ale czasami koszt zakupu
środowiska jest drugorzędny, kiedy liczy się wsparcie, odpowiedzialność,
dostępność pomocy, a przede wszystkim użytkowane narzędzia. Pomijam ESXy,
które chodzą na Linuxie z założenia, to pozostałych zadań nie widzę potrzeby
posiadania serwera Linuxowego. Stabilność? Odkąd zajmuję się serwerami to
poza sprzętowymi awariami większych problemów nie doświadczyłem, a
zaczynałem na NT 4. PostrgreS jest niewątpliwie dobrym serwerem, ale połowa
jak nie więcej z narzędzi, które używam - chociażby cała infrastruktura do
zarządzania VMWarem, backupami używa MS SQL w wersji Express i szczerze
mówiąc nie znam żadnego z tych większych systemów, narzędzi serwerowych
pracujących na serwerach, który używałby Postgresa.

I ciągle słyszę mity, że na Windows jest be, a na Linux jest ok. Być może,
nie znam się na tyle na Linuxach, żeby się wymądrzać, za to znam masę
całkiem sporych firm, w których Linux służy jedynie jak serwer www/ftp a
intranet i cała sieć wewnętrzna to MS. Nie chcę toczyć bojów o OSach, bo to
nie ta grupa.
Post by Eugeniusz Rink
zdaje się, że są ograniczenia w wielkości bazy oraz jednoczesnego
podłączenia się większej ilości klientów do bazy...? Chyba, że w tej
wersji się coś zmieniło...
W skrócie - baza do 4 GB dla plików bazy poza FILESTREAM, FILESTREAM nie
jest wliczany w limit bazy, więc jak planujesz BLOBy to możesz trzymać je w
bazie właśnie w postaci FILESTREAM, gdzie serwer zarządza plikami, masz je w
backupach. Jeśli więc limit 4 GB na same dane okołotekstowe jest kluczowy to
może warto zerknąć na wyższe wersje. Limitu userów nie ma, jest limit
wykorzystania RAMu do 1 GB i jednego CPU. Co do wielu zadań tak naprawdę nie
jest żadnym limitem...

jh


__________ Informacja programu ESET NOD32 Antivirus, wersja bazy sygnatur wirusow 5012 (20100409) __________

Wiadomosc zostala sprawdzona przez program ESET NOD32 Antivirus.

http://www.eset.pl lub http://www.eset.com
miab
2010-04-09 08:48:45 UTC
Permalink
Post by jh
Post by Eugeniusz Rink
Post by jh
Proponuję MS SQL Express 2008. Darmowe, razem z serwerem dostajesz
darmowe narzędzie do zarządzania serwerem, tworzeniem baz - graficznie,
jak w Accessie. Znacznie więcej typów danych niż w Firebird, i silnik
chyba znacznie wydajniejszy. Nie to, żebym mial coś do FB, ale odkąd
zmieniłem FB na MS SQL to jakoś tak łatwiej wiele rzeczy zrobić...
Pewnie to nieobiektywne, ale tak mam ;)
Tak.. to postaw MS SQLa np na Linuxie,
A po co? Skoro pytacz ma Delphi i Accessa, to raczej wskazuje to na
Windowsa, niż na Linuxa...
Post by Eugeniusz Rink
o innych wybiegach licencyjnych już nie wspomnę...
Na przykład? Jedynym nie technicznym ograniczeniem wersji Express jest
zakaz używania tej wersji w celach hostingowych-komercyjnych. A jakie to
wybiegi licencyjne masz na myśli?
Właśnie, zestaw komercyjny M$Windows+M$SQL+M$SerwerAplikacji jest
radykalnie droższy niż jego odpowiedniki Linuxowe.

miab
wloochacz
2010-04-09 08:54:16 UTC
Permalink
miab pisze:
/ciach/
Post by miab
Właśnie, zestaw komercyjny M$Windows+M$SQL+M$SerwerAplikacji jest
radykalnie droższy niż jego odpowiedniki Linuxowe.
Tylko, że nie ma jego odpowiedników Linuxowych...
Ciekawe, że porównujecie tylko koszty licencji na soft - a to tylko
ułamek wartości TCO.

Ale OK, skoro jest taki drogi to pokaż mi odpowiednik SBSa z takimi lub
większymi możliwościami za radykalnie mniejszą kasę, z jednym spójnym
supportem (w jednej firmie).
--
wloochacz
Arivald
2010-04-08 14:36:11 UTC
Permalink
Post by Pancio
Witam,
Nie mam zbytniego doświadczenia w pisaniu programów bazodanowych, a jakiś
[...]

Nie, Accessa to już chyba na nic nie przerobisz. Z płytki instalacyjnej
można spróbować wiatraczek zrobić.
Za to z podręczników do Accessa wyszła mi świetna podpałka do grila!
;->

A tak poważniej, to po prostu poeksperymentuj trochę z Firebirdem,
poczytaj jakiś kurs SQL dla początkujących i możesz zaczynać.
Początki nie są trudne.
--
Arivald
wloochacz
2010-04-08 17:01:42 UTC
Permalink
Post by Arivald
Post by Pancio
Witam,
Nie mam zbytniego doświadczenia w pisaniu programów bazodanowych, a jakiś
[...]
Nie, Accessa to już chyba na nic nie przerobisz. Z płytki instalacyjnej
można spróbować wiatraczek zrobić.
Są automaty do FB i do MS SQL - do MS SQL to i w samym Accessie, z tego
co pamiętam...
Post by Arivald
Za to z podręczników do Accessa wyszła mi świetna podpałka do grila!
;->
To się nie nadaje na podpałkę do grilla, bo mięso będzie śmierdzieć.
No chyba, że grillujesz kiełbasę z marketu, to przepraszam - bo to i tak
bez znaczenia... ;-)
Post by Arivald
A tak poważniej, to po prostu poeksperymentuj trochę z Firebirdem,
poczytaj jakiś kurs SQL dla początkujących i możesz zaczynać.
Początki nie są trudne.
Tam nie ma co eksperymentować - jeżeli Pancio używa AnyDAC'a, t
wystarczuy zmienić ciąg połączenia, dodać sterownik do FB/MS SQL i ta
aplikacja będzie działać na serwerze. Po prostu.
Osobna kwestia, to jak będzie działać - no, ale będzie :)
--
wloochacz
Pancio
2010-04-08 22:21:00 UTC
Permalink
Post by wloochacz
Post by Arivald
Za to z podręczników do Accessa wyszła mi świetna podpałka do grila!
;->
To się nie nadaje na podpałkę do grilla, bo mięso będzie śmierdzieć.
No chyba, że grillujesz kiełbasę z marketu, to przepraszam - bo to i tak
bez znaczenia... ;-)
Papieru jest tyle, że możnaby tym oblecicć sezon grillowy od 2010 do 2032
zakładając, że używamy trzech kartek do rozpalenia i nie robimy więcej niż
12 rozpaleń w sezonie (może inni też mają równie "użyteczne" podręczniki).
:))
Ale do rzeczy...
Post by wloochacz
Tam nie ma co eksperymentować - jeżeli Pancio używa AnyDAC'a, t wystarczuy
zmienić ciąg połączenia, dodać sterownik do FB/MS SQL i ta aplikacja
będzie działać na serwerze. Po prostu.
Osobna kwestia, to jak będzie działać - no, ale będzie :)
I to mnie najbardziej zainteresowało. Ściągnąłem dzisiaj "Microsoft SQL
Server 2008 Express Edition with Advanced Services" i pomijając fakt, że
sama instalka zajmowała prawię pół gigabajta a instalacja trwała ponad 40
minut, to po uruchomieniu tego środowiska wiedziałem mniej więcej o tym
tyle, co o specyfice lotu samolotem F-16. Zero... Baaa, to chyba nawet
zawyżyłem.
Jednak Wloochacz napisał, że samą bazę tj. plik *.MDB możnaby umieścić na
serwerze, dodać do Delphi odpowiednie sterowniki AnyDAC'a np. do Firebird'a
a całość jakoś mogłaby zadziałać.
No i pytania najważniejsze o takie cechy jak:

- szybkość działania w miarę przyrostu kolejnych rekordów (aktywnych na
ekranie nie więcej niż 1000 wierszy, czyli po zastosowaniu formuły "Select *
From Zamowienia Where Data>'2010-01-01'") ale pozostałych (ukrytych)
rekordów mogłoby być nawet i kilka/naście tysięcy.

- stabilność (kurde, przy użytkowaniu przez 10 userów jednocześnie przez
8-10 godzin dziennie baza nie powinna się w ogóle wysypywać, a już na pewno
nie częśniej niż raz na pół roku). Rzecz jasna archiwizować dane mogę w
dowolnie wybranym przedziale czasu

W zasadzie to na dotychczasowej etapie mojej wiedzy i umiejętności Access to
szczyt osiągnięć, ale jeśli AnyDAC mógłby być ku temu pomocny, to dlaczego
nie. A tak zupełnie z innej beczki - to dlaczego tak nie lubicie MS Accessa?
Ale tak na poważnie i w konkretach.
Dlaczego pytam? Bo każdego dnia obsługuję np. program Płatnik (to ustrojstwo
od ZUS-u) i tam baza działa nawet dość sprawnie (mimo całkiem pokaźnego
rozmiaru pliku *.mdb bo na poziomie 95-100 MB).

OK, nie chcę tutaj zachwalać produktu Microsoftu, a raczej czekam na
sugestie na pytania zadane powyżej.
Pozdrawiam serdecznie, Witek.
jh
2010-04-08 22:40:03 UTC
Permalink
Post by Pancio
I to mnie najbardziej zainteresowało. Ściągnąłem dzisiaj "Microsoft SQL
Server 2008 Express Edition with Advanced Services" i pomijając fakt, że
sama instalka zajmowała prawię pół gigabajta a instalacja trwała ponad 40
minut,
Ale razem z serwerem dostajesz pokaźny zestaw startowy ;) Books online -
masa literatury, dobre helpy. Server management Studio w zasadzie jest
wystarczającym narzędziem na początek (i nie tylko). Ma parę drobnych
niedogodności, które można obejść nawet we freeware'owej wersji EMS SQL
Managera. Bez problemu i grzebania w linii poleceń zrobisz prawie wszystkie
zadania administracyjne.
Post by Pancio
to po uruchomieniu tego środowiska wiedziałem mniej więcej o tym tyle, co
o specyfice lotu samolotem F-16. Zero... Baaa, to chyba nawet zawyżyłem.
Szczerze polecam tę książkę: http://helion.pl/ksiazki/sqls25.htm SQL Server
2005. Programowanie. Od podstaw - naprawdę bardzo dobrze napisana, wystarczą
podstawowe wiadomości na temat SQL i ogólna wiedza o programowaniu.
Post by Pancio
- szybkość działania w miarę przyrostu kolejnych rekordów (aktywnych na
ekranie nie więcej niż 1000 wierszy, czyli po zastosowaniu formuły "Select
* From Zamowienia Where Data>'2010-01-01'") ale pozostałych (ukrytych)
rekordów mogłoby być nawet i kilka/naście tysięcy.
Każda sensowna baza poradzi sobie z tym.
Post by Pancio
- stabilność (kurde, przy użytkowaniu przez 10 userów jednocześnie przez
8-10 godzin dziennie baza nie powinna się w ogóle wysypywać, a już na
pewno nie częśniej niż raz na pół roku). Rzecz jasna archiwizować dane
mogę w dowolnie wybranym przedziale czasu
Baza ma się w ogóle nie wysypywać. Gdybyś zakładał, że tak ma się dziać, to
na drzewo z takim rozwiązaniem. Inna sprawa, że już dawno wymyślono
backup...
Post by Pancio
A tak zupełnie z innej beczki - to dlaczego tak nie lubicie MS Accessa?
To nie kwestia lubienia. Pewnie wielu zetknęło się z nim w codziennej pracy.
Jednak ma dosyć ograniczone możliwości - jest to baza plikowa, bez
zarządzania przez serwer, więc tym samym pozbawiasz się wielu mechanizmów
wielodostępu. Owszem, dla kilku osób da radę, ale jeśli przyjdzie połączyć
się z takim plikiem 15-20 klientom, to marne szanse, że kogoś nie trafi
praca z takim systemem. O całej funkcjonalności procedur (UDF), triggerów i
innych mechanizmów we współczesnych bazach nie wspomnę. Inaczej mówiąc -
epoka plikowych baz danych to -naście lat wstecz i nie ma sensu pakować się
w naukę i rozwijanie nowych aplikacji w takim rozwiązaniu.

Jacek


__________ Informacja programu ESET NOD32 Antivirus, wersja bazy sygnatur wirusow 5011 (20100408) __________

Wiadomosc zostala sprawdzona przez program ESET NOD32 Antivirus.

http://www.eset.pl lub http://www.eset.com
wloochacz
2010-04-09 08:28:10 UTC
Permalink
Post by Pancio
Post by wloochacz
Post by Arivald
Za to z podręczników do Accessa wyszła mi świetna podpałka do grila!
;->
To się nie nadaje na podpałkę do grilla, bo mięso będzie śmierdzieć.
No chyba, że grillujesz kiełbasę z marketu, to przepraszam - bo to i
tak bez znaczenia... ;-)
Papieru jest tyle, że możnaby tym oblecicć sezon grillowy od 2010 do
2032 zakładając, że używamy trzech kartek do rozpalenia i nie robimy
więcej niż 12 rozpaleń w sezonie (może inni też mają równie "użyteczne"
podręczniki). :))
Ale do rzeczy...
Post by wloochacz
Tam nie ma co eksperymentować - jeżeli Pancio używa AnyDAC'a, t
wystarczuy zmienić ciąg połączenia, dodać sterownik do FB/MS SQL i ta
aplikacja będzie działać na serwerze. Po prostu.
Osobna kwestia, to jak będzie działać - no, ale będzie :)
I to mnie najbardziej zainteresowało. Ściągnąłem dzisiaj "Microsoft SQL
Server 2008 Express Edition with Advanced Services" i pomijając fakt, że
sama instalka zajmowała prawię pół gigabajta a instalacja trwała ponad
trzeba było zainstalować bez Advanced, bo nie jesteś Advanced...
Post by Pancio
40 minut, to po uruchomieniu tego środowiska wiedziałem mniej więcej o
tym tyle, co o specyfice lotu samolotem F-16. Zero... Baaa, to chyba
nawet zawyżyłem.
To nie gra z pięknym intrem - czego oczekujesz, że co?
Post by Pancio
Jednak Wloochacz napisał, że samą bazę tj. plik *.MDB możnaby umieścić
na serwerze, dodać do Delphi odpowiednie sterowniki AnyDAC'a np. do
Firebird'a a całość jakoś mogłaby zadziałać.
Nie napisałem, że można mdb umieścić na serwerze (bez sensu), tylko że
można ją automatycznie skonwertować. Użyj googl'e!
http://www.jasonbagley.com/2006/02/22/how-to-upgrade-access-to-mssql-2005/

/ciach/
--
wloochacz
Bogdan Polak (BSC)
2010-04-09 09:53:03 UTC
Permalink
Post by Pancio
Jednak Wloochacz napisał, że samą bazę tj. plik *.MDB możnaby
umieścić na serwerze, dodać do Delphi odpowiednie sterowniki
AnyDAC'a np. do Firebird'a a całość jakoś mogłaby zadziałać.
Po pierwsze radzę od razu skalkulować koszt wersji Standard SQL Servera
dla tych wspomnianych przez Ciebie 10 userów. Nie jest to żadna
astronomiczna kwota, co więcej nie trzeba jej płacić od razu tylko za
jakieś 2-3 lata, albo i później. Jednak zapłacić trzeba będzie. Na
początek powinna wystarczyć wersja Express.

Acha i jeszcze jedno, być może do razu warto pomyśleć o Windows Server
SBS, lub czegoś podobnego jeśli MS nazwał to inaczej. Chodzi mi p paczkę
system serwerowy plus serwer baz danych plus wiele ciekawostek.
Oczywiście koszt licencyjny jest wtedy na początku wdrożenia, większe
będą również wymagania hardware-owe (dla najnowyszch 2008-ek), ale może
się opłacać.

Migracja z Accessa do SQL Severa jest najprostszą migracją do RBMS, więc
za nią przemawiają wskaźniki biznesowe TCO i ROI. Koszt utrzymania może
trochę wyższy niż dla Firebirda, ale nie musi być. Poza tym jest
możliwość użycia tych samych aplikacji Access-owych, które nie będę już
przechowywały danych, ale same procedury, formatki i raporty. Aplikacja
Access-owa będzie klientem SQL Servera. Kolejny atut to prawie
bezbolesna migracja kodu Delphi jeżeli korzystałeś z komponentów dbGO
vel ADO. Oczywiście może być potrzebna optymalizacja takiej migracji,
ale to inna para kaloszy. Argumentów za jest więcej, najlepiej poczytaj
to co udało się zgromadzić Microsoft-owi, po odsianiu marketingu,
znajdziesz tam sporo ciekawych wiadomości:

http://www.microsoft.com/Sqlserver/2005/en/us/migration-access.aspx

Bogdan
Przemyslaw Osmanski
2010-04-09 11:13:28 UTC
Permalink
Post by Bogdan Polak (BSC)
Acha i jeszcze jedno, być może do razu warto pomyśleć o Windows Server
SBS, lub czegoś podobnego jeśli MS nazwał to inaczej. Chodzi mi p paczkę
system serwerowy plus serwer baz danych plus wiele ciekawostek.
Oczywiście koszt licencyjny jest wtedy na początku wdrożenia, większe
będą również wymagania hardware-owe (dla najnowyszch 2008-ek), ale może
się opłacać.
A to po kiego? Chyba tylko dla podniesienia kosztów ogólnych, bo nawet
antyvirus dla Windows Server jest kilka(naście) razy droższy.
Z drugiej strony zależy to też od programu i tego jak rozmawia z bazą.
Jeśli każdy użytkownik programu jest definiowany jako Windows User, to
faktyczne Windows Server jest wskazany, w innym przypadku nie ma to
znaczenia.

pozdrawiam,
Przemek O.
--
www.soft-system.pl
Bogdan Polak (BSC)
2010-04-09 11:23:49 UTC
Permalink
Post by Przemyslaw Osmanski
A to po kiego?
To moje osobiste zdanie i nie zamierzam dalej prowadzić polemikę, ale
postaram się zaspokoić ciekawość kolegi.

Ja wychodzę z takiego założenia, że jak w firmie postawisz na serwerze
system desktop-owy to prosisz się o interwencję szefa firmy, żeby tego
kompa wykorzystać do pracy biurowej, bo przyszedł po pracy pan Józek i
nie ma sensu teraz kupować mu maszyny (jak się sprawdzi to pomyślimy), a
mamy przecież wolny komputer z Windows XP - huraa !!!. Wystarszy
doinstalować Office-a i hajda.

Bogdan
Yild
2010-04-09 19:30:09 UTC
Permalink
----- Original Message -----
From: "Bogdan Polak (BSC)" <***@usun-to.bsc.com.pl>
Newsgroups: pl.comp.lang.delphi.bazy-danych
Sent: Friday, April 09, 2010 1:23 PM
Subject: Re: Przerobienie MS Access na Firebird
Post by Bogdan Polak (BSC)
Post by Przemyslaw Osmanski
A to po kiego?
To moje osobiste zdanie i nie zamierzam dalej prowadzić polemikę, ale
postaram się zaspokoić ciekawość kolegi.
Ja wychodzę z takiego założenia, że jak w firmie postawisz na serwerze
system desktop-owy to prosisz się o interwencję szefa firmy, żeby tego
kompa wykorzystać do pracy biurowej, bo przyszedł po pracy pan Józek i
nie ma sensu teraz kupować mu maszyny (jak się sprawdzi to pomyślimy), a
mamy przecież wolny komputer z Windows XP - huraa !!!. Wystarszy
doinstalować Office-a i hajda.
Bogdan
"firma" a "firma" - jesli serwer stoi sobie na stanowisku "produkcyjnym" to ja dziekuje za taka obsluge informatyczna firmy
no chyba ze mowa o "lightowym" zastosowaniu bazy to w takim wypadku moze sobie baza lezec u pani geni z ksiegowosci gdzie wiadomo ze komputer bedzie wlaczony przez te n godzin pracy

ad
Post by Bogdan Polak (BSC)
nie ma sensu teraz kupować mu maszyny (jak się sprawdzi to pomyślimy)
znow sa "firmy" i "firmy" jak mowa o kilku komputerach w firmie to patrz wyzej z genia
jak jest wiecej to informatycy powinni posiadac conajmniej jeden komputer zastepczy (w zaleznosci ile kompow w firmie...)
a co do kosztow - dla pana Jozka wystarczy poleasingowy zestaw za 1 tys zl, byle mial xp pro (co by go do domeny podpiac jesli jest)
(sam pracuje w sluzbie zdrowia, panstwowej - kasa na kompa sie znajdzie jesli stanowisko tego wymaga)

Y.
MKi
2010-04-12 08:24:52 UTC
Permalink
Migracja z Accessa do SQL Severa jest najprostszą migracją do RBMS, więc za nią przemawiają wskaźniki biznesowe TCO i ROI. Koszt
utrzymania może trochę wyższy niż dla Firebirda, ale nie musi być. Poza tym jest możliwość użycia tych samych aplikacji
Access-owych, które nie będę już przechowywały danych, ale same procedury, formatki i raporty. Aplikacja Access-owa będzie
klientem SQL Servera. Kolejny atut to prawie bezbolesna migracja kodu Delphi jeżeli korzystałeś z komponentów dbGO vel ADO.
Oczywiście może być potrzebna optymalizacja takiej migracji, ale to inna para kaloszy. Argumentów za jest więcej, najlepiej
http://www.microsoft.com/Sqlserver/2005/en/us/migration-access.aspx
Ja bym jeszcze polecił
http://sqlserver2000.databases.aspfaq.com/what-are-the-main-differences-between-access-and-sql-server.html

Sam niedwano zmigrowywałem jedną baze z Accessa na SQL Server.
Dwie rzeczy mi sprawiły przykrość:
- brak obsługi tekstów "TRUE" i "FALSE"
- brak funkcji VAL

Pozdrowienia,
MKi
wloochacz
2010-04-12 08:57:11 UTC
Permalink
MKi pisze:
/ciach/
Post by MKi
Ja bym jeszcze polecił
http://sqlserver2000.databases.aspfaq.com/what-are-the-main-differences-between-access-and-sql-server.html
Bardzo fajny doc :)
Post by MKi
Sam niedwano zmigrowywałem jedną baze z Accessa na SQL Server.
- brak obsługi tekstów "TRUE" i "FALSE"
To jest tylko wyświetlanie danych typu logicznego. Pamiętaj, że Access
to również aplikacja i pewne rzeczy robi automatycznie - oczywiście w
Delphi ta się zrobić to tak, aby wyglądało identycznie.
Post by MKi
- brak funkcji VAL
I bardzo dobrze, bo to własny standard Accessa - od tego jest Cast/Convert.
--
wloochacz
MKi
2010-04-12 09:47:17 UTC
Permalink
Post by wloochacz
Post by MKi
- brak funkcji VAL
I bardzo dobrze, bo to własny standard Accessa - od tego jest Cast/Convert.
No i fajnie, ale Accessowiec od lat używający wszędzie, gdzie się da tego Val
musi teraz połatać...

A mógłbyś mi podpowiedzieć, jak bezboleśnie przejść z zapisu takiego jak

SELECT Max(Val(Numer)) FROM Tabela

gdzie Numer jest stringiem zawierającym teksty typu "112/2010"?
Access zgrabnie wywala wszystko, od pierwszego znaku niepasującego do liczby.

Chciałm zrobić rozwiązanie przezroczyste, żeby ten sam kod Delphi
działał z SQL Serverem i z Accessem. Jak na razie mam właśnie powyższy
problem z Val (zrobiłem stosowną funkcję Val w SQL Serverze, ale żeby jej użyć
muszę dać przed jej nazwą "dbo."

Inny problem jest z wspomnianym True/False - jak zrobić to:

UPDATE Tabela SET Zrobiony=TRUE

Dowcip jest ten, że w Accessie TRUE=-1, a w SQL Serverze TRUE=1.

Pozdrowienia,
MKi
Pancio
2010-04-12 21:56:43 UTC
Permalink
Post by MKi
UPDATE Tabela SET Zrobiony=TRUE
Dowcip jest ten, że w Accessie TRUE=-1, a w SQL Serverze TRUE=1.
Ja zrobiłem to w następujący sposób. Dałem True albo False w apostrofy. Nie
wiem czy tak powinno się robić w MSSQL ale... u mnie to działa prawidłowo.
UPDATE Tabela SET Zrobiony='TRUE'

Bogdan Polak (BSC)
2010-04-09 10:25:21 UTC
Permalink
jakiś czas temu zacząłem tworzyć aplikację opartą
na bazie danych Accessa.
Jeżeli używałeś komponentów ADO (dbGO) i pisałeś SELECT-y to już trochę
znasz specyfikę pracy z RDMBS, czyli serwerami relacyjnych baz danych.
Resztę można się nauczyć na swoich "próbach i błędach"
można w jakiś w miarę łatwy i bezbolesny sposób przejść z
bazy utworzonej w Accessie na serwer Firebirda?
"Łatwy" to pojęcie względne. Firebird ma inną specyfikę, np. Access i
SQL Server oparty jest o identyfikatory typu autoinc, Firebird o
generatory, czyli sekwencje. Tego typu różnice mogę powaznie
skomplikować migrację bazy. Z migracją aplikacji będzie jeszcze wiecej
kłopotów. Będziesz musiał użyć innych komponentów. Jeśli miałbyś D 2010
Ent to masz obsługę Firebirda w pakiecie, do D7 Pro musisz kupić
dodatkowe komponenty takie jak IBDAC (najtańszy) lub AnyDAC
(najpopularniejszy na grupie i wszechstronny). Zmiana komponentów w
kodzie to tylko szczyt góry lodowej, a wiele niuansów wychodzi w czasie
samej migracji.
Często chwali się Firebirda właśnie za stabilność.
No i jest bardzo stabilny. :-)
O ile wybór serwera SQL jest jak dla mnie-laika dowolny
(byle darmowy)
To dużego wyboru nie masz: Firebird i MySQL resztę trzeba zignorować.
Zapomnij o tym, że SQL Server jest darmowy, chyba że masz mało danych i
baza rozrasta się bardzo wolno, ale i tak jak dla mnie byłoby to
ryzykowne, jeżeli ta "darmowość" jest "must-be".

Analizując migrację Access -> Firebird lub Access -> MySQL to wybrałbym
tą drugą, bo te bazy mają więcej wspólnych elementów. Przy obydwu
migracjach czeka Ciebie zakup komponentów połączeniowych np. z najtańszych:
http://www.devart.com/mydac/
http://www.devart.com/ibdac/
Czyli ta kwestia jest taka sama.

Jednak zastanowiłbym się na Twoim miejscu nad tą "darmowością", bo być
może koszty migracji będą dużo większe, ale w sumie to może być dla
Ciebie korzyść, bo będziesz miał więcej do zrobienia i za więcej
roboczogodzin będzie musiał zapłacić klient Tobie, a nie np.
Microsoftowi za licencje. :-)
o tyle o wiele bardziej ważne jest, czy przesiadka i
przyzwyczajenia obsługi bazy w Accessie różnią się znacząco
od Firebirda.
Przesiadka będzie kosztowna czasowo, ale przyzwyczajenia po części już
nabyłeś pracując z Accessem przez ADO.

Bogdan
wloochacz
2010-04-09 10:41:57 UTC
Permalink
Post by Bogdan Polak (BSC)
jakiś czas temu zacząłem tworzyć aplikację opartą
na bazie danych Accessa.
Jeżeli używałeś komponentów ADO (dbGO) i pisałeś SELECT-y to już trochę
znasz specyfikę pracy z RDMBS, czyli serwerami relacyjnych baz danych.
Resztę można się nauczyć na swoich "próbach i błędach"
można w jakiś w miarę łatwy i bezbolesny sposób przejść z
bazy utworzonej w Accessie na serwer Firebirda?
"Łatwy" to pojęcie względne. Firebird ma inną specyfikę, np. Access i
SQL Server oparty jest o identyfikatory typu autoinc, Firebird o
generatory, czyli sekwencje.
Punkt dla MS SQL'a :D
Post by Bogdan Polak (BSC)
Tego typu różnice mogę powaznie
skomplikować migrację bazy. Z migracją aplikacji będzie jeszcze wiecej
kłopotów. Będziesz musiał użyć innych komponentów. Jeśli miałbyś D 2010
Ent to masz obsługę Firebirda w pakiecie, do D7 Pro musisz kupić
dodatkowe komponenty takie jak IBDAC (najtańszy) lub AnyDAC
(najpopularniejszy na grupie i wszechstronny). Zmiana komponentów w
kodzie to tylko szczyt góry lodowej, a wiele niuansów wychodzi w czasie
samej migracji.
Często chwali się Firebirda właśnie za stabilność.
No i jest bardzo stabilny. :-)
Wiesz co, mój wspólnik twierdzi że stabilność FB to mit :-)
Ma tak średnio raz na 3, 4 tygodnie klienta z rozjechaną bazą, tylko że
owi kliencie różne cuda potrafią zrobić - np. wyłączyć komputer, kiedy
aplikacja coś sobie tam przelicza... Albo skończy się miejsce na dysku
(w trakcie robienia remanentu) i jest problem.
Ciekawe, bo ja np. z FB problemów miałem bardzo mało.
Post by Bogdan Polak (BSC)
O ile wybór serwera SQL jest jak dla mnie-laika dowolny
(byle darmowy)
To dużego wyboru nie masz: Firebird i MySQL resztę trzeba zignorować.
Trzeba? Chyba sie zagalopowałeś - pisz tak dalej, to będę twierdził, że
Twoje rady trzeba ignorować ;-)
Post by Bogdan Polak (BSC)
Zapomnij o tym, że SQL Server jest darmowy, chyba że masz mało danych i
baza rozrasta się bardzo wolno, ale i tak jak dla mnie byłoby to
ryzykowne, jeżeli ta "darmowość" jest "must-be".
Co?!
Ty mas pojęcie ile zajmuje baza danych w średniej wielkości firmie dla
rozwiązania dedykowanego (bo o takich rozmawiamy w tym kontekście)? Ile?
Post by Bogdan Polak (BSC)
Analizując migrację Access -> Firebird lub Access -> MySQL to wybrałbym
tą drugą, bo te bazy mają więcej wspólnych elementów.
A Ty tak poważnie polecasz komuś aby zaczął od MySQL'a?
Dlaczego taka krzywdę chcesz mu uczynić?
Post by Bogdan Polak (BSC)
Przy obydwu
http://www.devart.com/mydac/
http://www.devart.com/ibdac/
Czyli ta kwestia jest taka sama.
Przy MSSQL nie czeka go zakup ŻADNYCH dodatkowych komponentów.
Może skorzystać z FreeDAC;a (darmowa wersja AnyDAC) lub dbGO (ADO).
Post by Bogdan Polak (BSC)
Jednak zastanowiłbym się na Twoim miejscu nad tą "darmowością", bo być
może koszty migracji będą dużo większe, ale w sumie to może być dla
Jezus Maria - kliknięcie w jedną opcję w menu Accessa aby zmigrować go
do MS SQL'a to są "dużo większe koszty"?
Post by Bogdan Polak (BSC)
Ciebie korzyść, bo będziesz miał więcej do zrobienia i za więcej
roboczogodzin będzie musiał zapłacić klient Tobie, a nie np.
Microsoftowi za licencje. :-)
o tyle o wiele bardziej ważne jest, czy przesiadka i
przyzwyczajenia obsługi bazy w Accessie różnią się znacząco
od Firebirda.
Przesiadka będzie kosztowna czasowo, ale przyzwyczajenia po części już
nabyłeś pracując z Accessem przez ADO.
To chyba Twoja konfabulacja - skąd wiesz, że używał ADO?
Myślałem, że używał AnyDAC'a ;-)
--
wloochacz
Bogdan Polak (BSC)
2010-04-09 11:18:17 UTC
Permalink
Post by wloochacz
Wiesz co, mój wspólnik twierdzi że stabilność FB to mit :-)
Ma tak średnio raz na 3, 4 tygodnie klienta z rozjechaną bazą, tylko że
owi kliencie różne cuda potrafią zrobić - np. wyłączyć komputer, kiedy
aplikacja coś sobie tam przelicza... Albo skończy się miejsce na dysku
(w trakcie robienia remanentu) i jest problem.
Niech postawi im SQL Servera w takich samych warunkach. Jak będzie miał
wnioski po 2 latach to wrócimy dyskusji.

"wyłączyć komputer, kiedy aplikacja coś sobie tam przelicza" - zależy co
wyłączają, jak serwer bazy to sami sobie są winni i jak stracą część
danych to się nauczą, ale jeżeli wyłączenie klienta takie cuda robi to
mogę się założyć, że to wina sposobu napisania aplikacji klienckiej i
być może nie uwzględnienia na przykład specyfiki wielogeneracyjnej
architektury silnika Firebird-a. Ja tam wiem jak można "wyłożyć"
Firebird-a więc nie jest taki wspaniały, ale o takie coś "przypadkowo"
trzeba się bardzo postarać.
Post by wloochacz
Post by Bogdan Polak (BSC)
Zapomnij o tym, że SQL Server jest darmowy, chyba że masz mało danych
i baza rozrasta się bardzo wolno, ale i tak jak dla mnie byłoby to
ryzykowne, jeżeli ta "darmowość" jest "must-be".
Co?!
Ty mas pojęcie ile zajmuje baza danych w średniej wielkości firmie dla
rozwiązania dedykowanego (bo o takich rozmawiamy w tym kontekście)? Ile?
Być może Microsoft coś poprawił w zarządzaniu przestrzenią bazy, ale
znam doświadczenia klientów z MSDE, w którym baza potrafiła puchnąć nie
proporcjonalnie do wzrostu danych i w miarę łatwo przy intensywnym
korzystaniu z bazy dawało radę przekroczyć 2 GB.

Faktycznie z 2005/2008 nie miałem takich doświadczeń, ale chętnie
posłucham Twoich. Możesz napisać jakieś konkrety (rozmiary), a nie tylko
straszyć, że będziesz mnie ignorować. ;-)
Post by wloochacz
A Ty tak poważnie polecasz komuś aby zaczął od MySQL'a?
Dlaczego taka krzywdę chcesz mu uczynić?
Podasz jakieś konkrety? Oczywiście rozmawiamy o wersji 5.x.
Post by wloochacz
Może skorzystać z FreeDAC;a
To też wybór z koniecznością zapłacenia, bo Dymitry nie będzie robił
poprawek do FreeDAC-a, czyli migracja do Delphi 64-bitowego będzie
wiązała się koniecznością kupna wersji komercyjnej. Dlatego moim zdaniem
lepiej od razu kupić AD i korzystać z pełni jego możliwości.
Post by wloochacz
Post by Bogdan Polak (BSC)
Jednak zastanowiłbym się na Twoim miejscu nad tą "darmowością", bo być
może koszty migracji będą dużo większe, ale w sumie to może być dla
Jezus Maria - kliknięcie w jedną opcję w menu Accessa aby zmigrować go
do MS SQL'a to są "dużo większe koszty"?
Pisałem szybciej niż myślałem, chodziło mi o to, że migracja Access ->
MySQL może być dużo droższa, ale za to kasę weźmie Pancio. Chociaż
jeżeli przedstawisz mi konkretne argumenty, że SQL Sever 2008 Express
potrafi starczyć na kilka lat przy intensywnym korzystaniu to wycofam
się z mojej koncepcji alternatywnej.

Osobiście, gdym głosował za wariatami to też wybrałby migrację do SS
Express, ale liczyłbym się z kosztem w przyszłości i raczej wybrałbym od
razu całą platformę SBS, chyba, że miałbym już serwer i system
serwerowy, wtedy sam Express będzie lepszym wyborem.
Post by wloochacz
Post by Bogdan Polak (BSC)
Przesiadka będzie kosztowna czasowo, ale przyzwyczajenia po części już
nabyłeś pracując z Accessem przez ADO.
To chyba Twoja konfabulacja - skąd wiesz, że używał ADO?
Myślałem, że używał AnyDAC'a ;-)
Niech się wypowie Pancio.
A tak na maginesie to jesteś stronniczy :p

Bogdan
wloochacz
2010-04-09 12:13:36 UTC
Permalink
Post by Bogdan Polak (BSC)
Post by wloochacz
Wiesz co, mój wspólnik twierdzi że stabilność FB to mit :-)
Ma tak średnio raz na 3, 4 tygodnie klienta z rozjechaną bazą, tylko że
owi kliencie różne cuda potrafią zrobić - np. wyłączyć komputer, kiedy
aplikacja coś sobie tam przelicza... Albo skończy się miejsce na dysku
(w trakcie robienia remanentu) i jest problem.
Niech postawi im SQL Servera w takich samych warunkach. Jak będzie miał
wnioski po 2 latach to wrócimy dyskusji.
"wyłączyć komputer, kiedy aplikacja coś sobie tam przelicza" - zależy co
wyłączają, jak serwer bazy to sami sobie są winni i jak stracą część
danych to się nauczą,
W tych instalacjach nie istnieje pojęcia serwera.
Serwer to jakiś komputer, na którym działa FB - dopóki ktoś tego
komputera nie wyłączy, bo tak.
Post by Bogdan Polak (BSC)
ale jeżeli wyłączenie klienta takie cuda robi to
mogę się założyć, że to wina sposobu napisania aplikacji klienckiej i
być może nie uwzględnienia na przykład specyfiki wielogeneracyjnej
architektury silnika Firebird-a.
Ja tam wiem jak można "wyłożyć"
Firebird-a więc nie jest taki wspaniały, ale o takie coś "przypadkowo"
trzeba się bardzo postarać.
Wcale nie tak bardzo - mój kolega zabił FB w 2 godziny.
Kilka/kilkadziesiąt insertów na sekundę z CommitRetaining.
I koniec - serwer zdechł ;-)
Post by Bogdan Polak (BSC)
Post by wloochacz
Post by Bogdan Polak (BSC)
Zapomnij o tym, że SQL Server jest darmowy, chyba że masz mało danych
i baza rozrasta się bardzo wolno, ale i tak jak dla mnie byłoby to
ryzykowne, jeżeli ta "darmowość" jest "must-be".
Co?!
Ty mas pojęcie ile zajmuje baza danych w średniej wielkości firmie dla
rozwiązania dedykowanego (bo o takich rozmawiamy w tym kontekście)? Ile?
Być może Microsoft coś poprawił w zarządzaniu przestrzenią bazy, ale
znam doświadczenia klientów z MSDE, w którym baza potrafiła puchnąć nie
proporcjonalnie do wzrostu danych i w miarę łatwo przy intensywnym
korzystaniu z bazy dawało radę przekroczyć 2 GB.
Po pierwsze MSDE to nie był dobry produkt - ich słynny workload governor
uczynił z tego silnika eunucha.
Obecne wersje Express nie mają już takich udziwnień.
Ale i tam była możliwość ustawienia recovery model...
Post by Bogdan Polak (BSC)
Faktycznie z 2005/2008 nie miałem takich doświadczeń, ale chętnie
posłucham Twoich. Możesz napisać jakieś konkrety (rozmiary), a nie tylko
straszyć, że będziesz mnie ignorować. ;-)
Post by wloochacz
A Ty tak poważnie polecasz komuś aby zaczął od MySQL'a?
Dlaczego taka krzywdę chcesz mu uczynić?
Podasz jakieś konkrety? Oczywiście rozmawiamy o wersji 5.x.
Ma dziwny dialekt, dziwne wymagania (żeby pisać triggery trzeba mieć
uprawnienia roota do serwera - i nie chodzi o serwer bazy danych
(sic!)), dużo wolniej działa od MyISAM, ma niejasne licencjonowanie itd,
itp.
Post by Bogdan Polak (BSC)
Post by wloochacz
Może skorzystać z FreeDAC;a
To też wybór z koniecznością zapłacenia, bo Dymitry nie będzie robił
poprawek do FreeDAC-a, czyli migracja do Delphi 64-bitowego będzie
wiązała się koniecznością kupna wersji komercyjnej. Dlatego moim zdaniem
lepiej od razu kupić AD i korzystać z pełni jego możliwości.
Wiesz co, anglosasi mówią na coś takiego "Continuous obsolescence", za
Wikipedią:
"Zjawisko, kiedy firma poświęca więcej uwagi na przenoszenie
istniejącego systemu na nowe platformy i środowiska, niż nad poprawą
jego funkcjonalności. Nazwa została stworzona przez analogię z pojęciem
Ciągła integracja (ang. Continous Integration)."
Post by Bogdan Polak (BSC)
Post by wloochacz
Post by Bogdan Polak (BSC)
Jednak zastanowiłbym się na Twoim miejscu nad tą "darmowością", bo być
może koszty migracji będą dużo większe, ale w sumie to może być dla
Jezus Maria - kliknięcie w jedną opcję w menu Accessa aby zmigrować go
do MS SQL'a to są "dużo większe koszty"?
Pisałem szybciej niż myślałem, chodziło mi o to, że migracja Access ->
MySQL może być dużo droższa, ale za to kasę weźmie Pancio.
Za co? Za niepotrzebną robotę? Myślisz, że klient lubi płacić za
niepotrzebnie wykonaną pracę?
IMO więcej zyska, jeżeli zmigurje to raz-dwa a efekty będą widoczne
natychmiast.
Post by Bogdan Polak (BSC)
Chociaż
jeżeli przedstawisz mi konkretne argumenty, że SQL Sever 2008 Express
potrafi starczyć na kilka lat przy intensywnym korzystaniu to wycofam
się z mojej koncepcji alternatywnej.
Jak mi Pancio poda co to za projekt, to Ci podam.
Z mojego podwórka wynika iż system składający się 340 tabelek (w bazie
też trzymam załączniki, ale raczej niewiele) i obsługujący praktycznie
każdy aspekt firmy wyłożyłby się na expressie po prawie 4 latach, bo
baza przekroczyła 4 GB.
Oczywiście mógłby się nigdy nie wyłożyć, jakbym np. dane archiwalne
przeniósł do innej bazy danych. A że MSSQL pozwala na jednoczesne
zadawania zapytań z wielu baz naraz - to wcale nie jest jakiś tam
ogromny problem do przeskoczenia.
Post by Bogdan Polak (BSC)
Osobiście, gdym głosował za wariatami to też wybrałby migrację do SS
Express, ale liczyłbym się z kosztem w przyszłości i raczej wybrałbym od
razu całą platformę SBS, chyba, że miałbym już serwer i system
serwerowy, wtedy sam Express będzie lepszym wyborem.
SBS wydaje się być dobrym wyborem, ale jest kilka pułapek.
Np. wersja SQL Server która tam działa, to specjalna edycja Workgroup,
która nie obsługuje Analisys Services - co w pewnych zastosowaniach jest
sporą przeszkodą.
Post by Bogdan Polak (BSC)
Post by wloochacz
Post by Bogdan Polak (BSC)
Przesiadka będzie kosztowna czasowo, ale przyzwyczajenia po części już
nabyłeś pracując z Accessem przez ADO.
To chyba Twoja konfabulacja - skąd wiesz, że używał ADO?
Myślałem, że używał AnyDAC'a ;-)
Niech się wypowie Pancio.
A tak na maginesie to jesteś stronniczy :p
Być może, ale za to zazwyczaj najpierw myślę, a potem piszę :p

--
wloochacz
Pancio
2010-04-09 11:45:49 UTC
Permalink
Czytam każdy post z wielką uwagą, ale im bardziej rozwija się dyskusja, tym
więcej mam wątpliwości co wybrać.
Obecnie chyba najbardziej zależy mi na własnej pracy. Mam zrobione jakieś
25% aplikacji z już istniającą bazą Accessa (z wykorzysaniem AnyDACa).
Przy "przesiadce" na wersję serwerową rozwiązanie "free" ważne jest, ale
tylko na początku. Jeśli po roku użytkowania okaże się, że baza rozrasta się
więcej niż przewidywałem, to wówczas rozwiązanie dodatkowego wyłożenia kasy
nie stanowić powinna problemu.

Osobiście dla mnie ważniejsze jest, aby proces migracji nie zmusił mnie do
poprawienia całego kodu pisanego w Delphi. W najgorszym wypadku całość mogę
dalej ciągnąć na bazie Accessa, a za rok zaoferować szybszą i stabilnieją
wersję programu i bazy (za dopłatą).

Z tego co piszecie powinienem wybierać między MySQL a MS SQL.
Jak już wspomniałem w pierwszym poście - nie znam się na tym zupełnie.... A
miałem zapywać poprzednio, ale jakoś mi umknęło. Czy będzie to MySQL czy MS
SQL to czy istnieje jakaś graficzna nakładka dla Windowsa (tylko Windowsa
nie musi być Linux) w której mógłbym tworzyć tabele i powiązane z nimi
relacje?
Fajnie jest to rozwiązane w Accessie - tutaj odpalam program, tworzę co chcę
(ewentualnie przeglądam już wprowadzone dane) i po kłopocie. Mam pustą bazę,
którą podpinam pod napisaną palikację Delphi i... reszta w rękach
użytkowników.

Chciałbym aby w przypadku SQLa było podobnie. Stworzyłbym ogólny "szkielet"
i wygląd bazy w jakimś zewnętrznym programie/nakładce bez konieczności
tworzenia tabel i samym Delphi.

Tak z grubsza o to właśnie mi chodzi. Dlatego właśnie pytam się o Wasze
zdanie, bo pomimo tego, że internecie mnóstwo jest informacji na ten temat,
to jednak ogarnięcie tego wszystkiego przez osobę z taką znajomością tematu
jak ja, jest bądź co bądź dość trudne. Zaufam Waszej wiedzy i
doświadczeniu.

Reasumując, tak określiłbym hierarchię przesiadki z Accessa:
1. najmniejsza ilość poprawek samego kodu w Delphi
2. końcowa szybkość działania samego programu (i bazy)
3. darmowość (ważna na początku a potem już obojętnie)

Pozdrawiam, Witek.
wloochacz
2010-04-09 11:57:04 UTC
Permalink
Post by Pancio
Czytam każdy post z wielką uwagą, ale im bardziej rozwija się dyskusja, tym
więcej mam wątpliwości co wybrać.
Obecnie chyba najbardziej zależy mi na własnej pracy. Mam zrobione jakieś
25% aplikacji z już istniającą bazą Accessa (z wykorzysaniem AnyDACa).
Przy "przesiadce" na wersję serwerową rozwiązanie "free" ważne jest, ale
tylko na początku. Jeśli po roku użytkowania okaże się, że baza rozrasta się
więcej niż przewidywałem, to wówczas rozwiązanie dodatkowego wyłożenia kasy
nie stanowić powinna problemu.
Podaj ile tabel, jaki są skonstruowane i jaki jest przewidywana dynamika
dodawania nowych danych.
To łatwo policzyć.
Post by Pancio
Osobiście dla mnie ważniejsze jest, aby proces migracji nie zmusił mnie do
poprawienia całego kodu pisanego w Delphi. W najgorszym wypadku całość mogę
dalej ciągnąć na bazie Accessa, a za rok zaoferować szybszą i stabilnieją
wersję programu i bazy (za dopłatą).
MS SQL + AnyDAC, powinno dać się odpalić w dwie godziny ;-)
Post by Pancio
Z tego co piszecie powinienem wybierać między MySQL a MS SQL.
Jak już wspomniałem w pierwszym poście - nie znam się na tym zupełnie.... A
miałem zapywać poprzednio, ale jakoś mi umknęło. Czy będzie to MySQL czy MS
SQL to czy istnieje jakaś graficzna nakładka dla Windowsa (tylko Windowsa
nie musi być Linux) w której mógłbym tworzyć tabele i powiązane z nimi
relacje?
http://www.sqlmanager.net/products/mssql/manager
Wersja EMS SQL Manager Lite for SQL Server za free.
Lub narzędzie dostarczone razem z MS SQL, czyli Microsoft® SQL Server®
2008 Management Studio Express
http://www.microsoft.com/downloads/details.aspx?FamilyID=08E52AC2-1D62-45F6-9A4A-4B76A8564A2B&displaylang=en
Post by Pancio
Fajnie jest to rozwiązane w Accessie - tutaj odpalam program, tworzę co chcę
(ewentualnie przeglądam już wprowadzone dane) i po kłopocie. Mam pustą bazę,
którą podpinam pod napisaną palikację Delphi i... reszta w rękach
użytkowników.
Tak samo jak gdzie indziej.
Tak naprawdę, jeżeli w zmigrujesz bazę Accessa dl MS SQLa to wszystko to
co robiłeś z tabelkami Accessa w Accessie możesz dalej robić w Accessie,
tylko z obiektami SQL Servera.
Ergo - nie zmieniasz żadnego narzędzia (DElphi, AnyDAC, Access) a dalej
działa.
Post by Pancio
Chciałbym aby w przypadku SQLa było podobnie. Stworzyłbym ogólny "szkielet"
i wygląd bazy w jakimś zewnętrznym programie/nakładce bez konieczności
tworzenia tabel i samym Delphi.
Tak z grubsza o to właśnie mi chodzi. Dlatego właśnie pytam się o Wasze
zdanie, bo pomimo tego, że internecie mnóstwo jest informacji na ten temat,
to jednak ogarnięcie tego wszystkiego przez osobę z taką znajomością tematu
jak ja, jest bądź co bądź dość trudne. Zaufam Waszej wiedzy i
doświadczeniu.
1. najmniejsza ilość poprawek samego kodu w Delphi
MS SQL Express
Post by Pancio
2. końcowa szybkość działania samego programu (i bazy)
MS SQL Express
Post by Pancio
3. darmowość (ważna na początku a potem już obojętnie)
MS SQL Express
:D
--
wloochacz
Pancio
2010-04-09 12:32:45 UTC
Permalink
Post by wloochacz
Podaj ile tabel, jaki są skonstruowane i jaki jest przewidywana dynamika
dodawania nowych danych.
To łatwo policzyć.
No to już mówię - teraz trudno mi to przewidzieć, bo non-stop wpada mi do
głowy nowy pomysł, ale łączna liczba tabel nie powinna przekroczyć 40 (a
podejrzewam, że będzie ich około 30).
- 5 z nich będą się rozrastać w tempie 30.000 rekordów rocznie
- kolejne 5 będzie mieć około 5.000 rekordów rocznie
- kolejne 5 nie więcej niż 1.000 rekordów rocznie
- pozostałe tabele po kilkaset rekordów rocznie
Post by wloochacz
Post by Pancio
1. najmniejsza ilość poprawek samego kodu w Delphi
MS SQL Express
Post by Pancio
2. końcowa szybkość działania samego programu (i bazy)
MS SQL Express
Post by Pancio
3. darmowość (ważna na początku a potem już obojętnie)
MS SQL Express
Bardziej trafnego przekazu nie mogłem się spodziewać.
Czyli "problem" samego wyboru jakby został już rozwiązany. Teraz tylko jak
to zrobić "w praktyce" i... ponieważ zbliża się weekend, to będę mieć sporo
czasu na lekturę tutoriali czy innych poradników z rodziny "for beginers"...
A tak dla ścisłości MS SQL Express w wersji 2005 czy 2008 ?
wloochacz
2010-04-09 13:38:20 UTC
Permalink
Post by Pancio
Post by wloochacz
Podaj ile tabel, jaki są skonstruowane i jaki jest przewidywana dynamika
dodawania nowych danych.
To łatwo policzyć.
No to już mówię - teraz trudno mi to przewidzieć, bo non-stop wpada mi do
głowy nowy pomysł, ale łączna liczba tabel nie powinna przekroczyć 40 (a
podejrzewam, że będzie ich około 30).
- 5 z nich będą się rozrastać w tempie 30.000 rekordów rocznie
- kolejne 5 będzie mieć około 5.000 rekordów rocznie
- kolejne 5 nie więcej niż 1.000 rekordów rocznie
- pozostałe tabele po kilkaset rekordów rocznie
Z tego co piszesz nie da się wydedukować pól jest w tabelach, i jakie
mają typy danych - jak bez tego policzyć rozmiar wiersza?
Zresztą sam możesz to zrobić opierając się na tych informacjach:
http://msdn.microsoft.com/en-us/library/ms187752.aspx
np. dla typów całkowitych będzie to:
http://msdn.microsoft.com/en-us/library/ms187745.aspx

Może tak - przy średniej wielkości wiersza na poziomie 0,5 KB, limit 4GB
osiągniesz po prawi 42 latach.
Starczy?
Ktoś może powiedzieć, że 0,5 KB na wiersz to mało, ale wcale nie. U mnie
taką wielkość ma tabela o takiej konstrukcji:

CREATE TABLE [dbo].[SOP_DOC_HDR] (
[ID_SOP_DOC] [typ_dex_guid_nnull] NOT NULL,
[ID_SOP_DOC_PARENT] [typ_dex_guid_nnull] NULL,
[ID_CURRENCY] [typ_dex_name_short_nnull] NOT NULL,
[ID_CONTRACTOR] [typ_dex_name_short_nnull] NOT NULL,
[DOC_NUMBER] [typ_dex_name_short_nnull] NOT NULL,
[DOC_TYPE] [typ_dex_int] NOT NULL,
[SOP_DOC_STATUS] [typ_dex_int] NOT NULL,
[SOP_DOC_PRIORITY] [typ_dex_int] NOT NULL,
[SOP_DOC_DATE] [typ_dex_date_nnull] NOT NULL,
[DOC_DATE_SUG] [typ_dex_date_null] NULL,
[DOC_DATE_REAL] [typ_dex_date_null] NULL,
[DOC_DATE_EXP] [typ_dex_date_null] NULL,
[DATE_C] [typ_dex_date_null] NULL,
[ID_USER_C] [typ_dex_int] NULL,
[DATE_M] [typ_dex_date_null] NULL,
[ID_USER_M] [typ_dex_int] NULL,
[ID_PAYMENT_TERM] [typ_dex_name_short_nnull] NULL,
[ID_SY_SHIPPER] [typ_dex_name_short_null] NULL,
[DOC_VER] [typ_dex_name_short_null] NULL,
[ID_SOP_DOC_ROOT] [typ_dex_guid_null] NULL,
[VALUE_GROSS] [typ_dex_numeric] NOT NULL,
[VALUE_NET] [typ_dex_numeric] NOT NULL,
[WAY_BILL_NO] [typ_dex_name_short_null] NULL,
[ID_EXCHTAB] [typ_dex_name_short_null] NULL,
[EXCHRATE] [typ_dex_numeric] NOT NULL,
CONSTRAINT [PK_SOP_DOC_HDR] PRIMARY KEY CLUSTERED ([ID_SOP_DOC])
)
Post by Pancio
Post by wloochacz
Post by Pancio
1. najmniejsza ilość poprawek samego kodu w Delphi
MS SQL Express
Post by Pancio
2. końcowa szybkość działania samego programu (i bazy)
MS SQL Express
Post by Pancio
3. darmowość (ważna na początku a potem już obojętnie)
MS SQL Express
Bardziej trafnego przekazu nie mogłem się spodziewać.
Czyli "problem" samego wyboru jakby został już rozwiązany. Teraz tylko jak
to zrobić "w praktyce" i... ponieważ zbliża się weekend, to będę mieć sporo
czasu na lekturę tutoriali czy innych poradników z rodziny "for beginers"...
Podałem w linku, jak.
Post by Pancio
A tak dla ścisłości MS SQL Express w wersji 2005 czy 2008 ?
Access w wersji co najmniej 2003 (OIDP od tej wersji są projekty ADP:
http://office.microsoft.com/pl-pl/access/HP052731031045.aspx )SQL Server
Express 2008 SP1 - ten ma w końcu typ danych Date :D
--
wloochacz
miab
2010-04-09 11:59:55 UTC
Permalink
Post by Pancio
Czytam każdy post z wielką uwagą, ale im bardziej rozwija się dyskusja, tym
więcej mam wątpliwości co wybrać.
Obecnie chyba najbardziej zależy mi na własnej pracy. Mam zrobione jakieś
25% aplikacji z już istniającą bazą Accessa (z wykorzysaniem AnyDACa).
Przy "przesiadce" na wersję serwerową rozwiązanie "free" ważne jest, ale
tylko na początku. Jeśli po roku użytkowania okaże się, że baza rozrasta się
więcej niż przewidywałem, to wówczas rozwiązanie dodatkowego wyłożenia kasy
nie stanowić powinna problemu.
Osobiście dla mnie ważniejsze jest, aby proces migracji nie zmusił mnie do
poprawienia całego kodu pisanego w Delphi. W najgorszym wypadku całość mogę
dalej ciągnąć na bazie Accessa, a za rok zaoferować szybszą i stabilnieją
wersję programu i bazy (za dopłatą).
Z tego co piszecie powinienem wybierać między MySQL a MS SQL.
M$SQL a FirebirdSQL(lub PostgreSQL).
MySQL ma jakąś porąbaną licencję do tego teraz jeszcze we władaniu ORACLE.
Post by Pancio
Jak już wspomniałem w pierwszym poście - nie znam się na tym zupełnie.... A
miałem zapywać poprzednio, ale jakoś mi umknęło. Czy będzie to MySQL czy MS
SQL to czy istnieje jakaś graficzna nakładka dla Windowsa (tylko Windowsa
nie musi być Linux) w której mógłbym tworzyć tabele i powiązane z nimi
relacje?
Fajnie jest to rozwiązane w Accessie - tutaj odpalam program, tworzę co chcę
(ewentualnie przeglądam już wprowadzone dane) i po kłopocie. Mam pustą bazę,
którą podpinam pod napisaną palikację Delphi i... reszta w rękach
użytkowników.
Chciałbym aby w przypadku SQLa było podobnie. Stworzyłbym ogólny "szkielet"
i wygląd bazy w jakimś zewnętrznym programie/nakładce bez konieczności
tworzenia tabel i samym Delphi.
Dla każdego serwera SQL istnieje wiele płatnych i darmowych desktopów,
niektóre dla wielu serwerów na raz.

miab
Loading...