Acces vs MSSQL

Witam, chciałbym się zapytać specjalistów od baz danych jak to jest: jak korzystam z MSSQL, MySQL itd (powiedzmy lokalnie) to potrzebuje mieć zainstalowany silnik bazodanowy (odpowiedni serwer baz danych) a jak jest z plikami accesa. Czy jeżeli w jakimś programie (powiedzmy napisanym w C#) korzystam z bazy danych accesa to po przeniesienu jej na inny komputer też powinno wszystko działać? Jak wobec tego jest z wydajnością baz danych z accesa? W jakiej sytuacji mogą być obserwowane różnice między wydajnością MSSQL i accesa? (czytaj kiedy wydajność accesa jest znacząco mniejsza od MSSQL - jak duża musi być baza danych, jak dużo zapytań musi być do niej kierowanych aby to zauwarzyć)

Chętnie poczytam też jakieś dokładniejsze opisy, więc proszę również o linki.

p.s. czy bazy danych accesa dadzą się chociaż jakoś obejrzeć pod *unix.

Jeśli na innym komputerze jest MS Access albo to, to i owszem.

Silnik nie jest jakiś super wydajny, w końcu jest to proste rozwiązanie dla małych firm. Ograniczeniem jest maksymalny rozmiar bazy danych - 2GB, więc jeśli potrzebujesz większej, to na pewno nie jest to rozwiązanie. Zwróć uwagę na to, że darmowy MS SQL Server Express może zmieścić 2 razy więcej danych i na pewno będzie wydajniejszy, obsługuje więcej typów danych i na ich poziomie jest zintegrowany z .NET.

Myślę, że się da. Więcej info tutaj.

Myslałem o wykorzystaniu podobnego rozwiazania

A jak jest z dystrybucją MS SQL Server Expres. Czy mogę wykorzystać jako część mojego programu, czy muszę to zrobić jakoś “inteligentniej”? Czy w przypadku braku pliku MS SQL mam po prostu poprosić użytkownika o zainstalowanie jakiegoś MS SQL?

Jak to jako część?

Razem ze swoją aplikacją możesz dostarczać instalator MS SQL Server Express, który użytkownik musi mieć zainstalowany i skonfigurowany, aby móc korzystać z bazy danych.Możesz zrobić instalator swojej aplikacji, który sprawdzi, czy serwer jest zainstalowany, a jeśli nie to go zainstaluje, a potem go odpowiednio skonfiguruje.

Jeśli bazy danych mają być małe, to warto rozważyć użycie “lekkich” serwerów, które działają tylko wtedy, gdy aplikacja pracuje. Mają one mniejsze możliwości i wydajność, ale nie obciążają tak komputera. Przykładami są MS SQL Server Compact Edition bądź SQLLite - to też lepsze rozwiązania niż Access.

dokładnie o to mi chodziło w pytaniu, sory za nieprecyzyjność.

SQLLite - bardzo fajne rozwiązanie, podoba mi się, szkoda że nie słyszałem o nim wcześniej, by nie było tematu. Dziękuję :smiley:

Dlatego często lepiej pytać o to, co chce się osiągnąć, bo często można to zrobić inaczej, niż się zakłada na początku :slight_smile:

Tylko nie wiem, czy jeśli piszesz w .NET, to nie lepiej jednak użyć bazy MS, zapewne jest wygodniej z tym pracować.

Też już to zauważyłem. Czas mnie jakoś bardzo nie nagli, więc sprawdze jakie rozwiązanie jest lepsze. Dziękuje

Jak dojdziesz do jakichś wniosków, to nie zapomnij się podzielić.

BTW: SQLLite ma chyba dość ograniczony zasób typów danych, trzeba się liczyć z koniecznością konwersji.

Wrażenia cz1.

Na razie przetestowałem MS SQL Servwer CE.

Porównywałem MS SQL Server CE i MS SQL Server Express (każdy z porównywanych produktów jest darmowy do celów komercyjnych).

Jeśli chodzi o rozmiar plików, to trudno dostrzec jakąś regułę, ale wygląda na to, że rozmiary plików (baz danych) SQL CE są nieznacznie mniejsze. Jeśli chodzi o wydajność, to zapytania były dłużej wykonywane w przypadku SQL CE. Jednak według mnie różnice są żadne, bo są mniejsze niż 1% czasu wykonywania zapytania (nie twierdzę, że zrobiłem wiarygodne testy, po prostu porównywałem czas wykonywania określonych zapytań, w tle chodził winamp, całe VS, przeglądarka, TotalCmd itd więc pomiar może być zaburzony). Bazy danych na których przeprowadzałem testy składały się z 2-5 tabelek w każdej 5-10 kolumn i około 300-500 wierszy. Większość była typu varchar(10-300) lub int.

Ku mojemu zdziwieniu VS po zainstalowaniu SQL CE nie wykryło automatycznie odpowiednich bibliotek pomimo restartu komputera :frowning: (Vista), ale za to nie miało problemów z wykryciem tego, że ‘działa’ server SqlCE. Po założeniu jakiejś bazy danych przez ‘klikanie’ w VS nie było już problemów.

Polecenia są praktycznie identyczne jak w przypadku zwykłego SQL, więc w przypadku istniejącego kodu pod SQL wystarczy zmienić w kodzie SQL* na SQLCE* i działa bez zarzutów.

Polecam wersję 2005 SQL CE (oczywiście z wszystkim SP), bo wersja 2008 SQL CE jest jakaś koszmarnie wielka (zresztą pewnie nie bez powodów, ale jak głównym celem tak jak u mnie jest pozbycie się XML z projektu + posiadanie zalet relacyjnych baz danych to w zupełności wystarcza 2005).

Myślę, że za jakiś czas trzeba będzie skorzystać z 2008 czy się chce czy nie.

Niewątpliwą zaletą SQL CE jest to, że nie obciąza tak systemu jak SQL Express

Podsumowując:

MS SQL Server CE to dobre rozwiązanie gdzy

  1. Chcemy się pozbyć XML z projektu

  2. Potrzebujemy używać małych baz danych, a chcielibyśmy mieć wszystkie zalety bazy danych (zapiszczcie sobie w XML tabelkę i spróbujcie napisać kod odpowiadający

    select kol1, kol2 from tabelka order by kol1

  • jest to już ładnych kilka linii kodu
  1. Chcemy mieć pewność, że nie zirytujemy użytkownika naszego programu działającym bez powodu MS SQL Express.

Windows Vista Basic - 32 bit, VS2008 Proffesional, 3GB DDR2, INTEL Core 2 Duo T5750 2GHz

Hmmm… A robiłeś kiedyś bazę danych w postaci DataSetów przechowywanych na dysku? Od strony programu możesz na nich działać praktycznie tak, jak na zwykłej bazie danych, nie trzeba żadnego serwera, dla Ciebie jest to przezroczyste, więc nie ma znaczenia, że pliki są xml :slight_smile:

Robiłem kiedyś wyobraź sobie (nawet nie raz), było to bardzo fajne i lubiłem takie rozwiązanie, nawet bardzo, ale czasami było widać, że to jednak nie baza danych, ale to dawało się obejść. Bardziej nieprzyjemne było coś innego (chyba, ze o tym nie wiedziałem, jak nie to uświadom mnie) jak wbudować w to typowe mechanizmy z baz danych, jak trigery, procedury, view i potem przenieść np plik na inny komputer lub inną wersję programu i aby dalej z tym nie było problemów.

Poza tym niektórzy użytkownicy mieli ochotę ręcznie modyfikować coś w XML :o, Wystarczy w kodzie programu ustawić jakieś hasło do bazy i już się tak łatwo nikt nie weźmie za ręczne modyfikowanie plików, a dla takiego XML nie jest to już takie łatwe (chyba ze też o czymś nie wiem).

No cóż, plik to jednak nie baza i nie spotkałem się jeszcze z robieniem procedur czy wyzwalaczy na nich. Ale to raczej nie jest potrzebne, gdy korzysta się z rozwiązania plikowego.

A co do grzebania przez użytkowników - pewno da się obejść na wiele sposobów: szyfrowanie, kompresja, isolated storage…