Cześć wszystkim!
Czasami wskazując swe rozwiązanie w którym użyta przeze mnie została baza danych oparta o plik access wielokrotnie słyszałem, że to rozwiązanie złe i przestarzałe. Dlaczego? Co "złego" jest w bazie danych access i dlaczego lepsze są inne rozwiązania?
0
1
Pytanie, jaki to system. Ale jak dobrze pamiętam to do Accessa może mieć dostęp tylko jedne użytkownik jednocześnie. No i trzeba mieć licencje gdzie bazy jak postgres czy mysql (nie polecam) są za free.
3
Po pierwsze jest plikową - tj nie opartą o serwer bazy danych
To drobne zdanie, pewnie nie od razu widzisz implikacje, a są poważne:
- nie istnieje serwer implementujacy jezyk SQL - jest robione na pececie
- o odróżnieniu od serwera, błaha operacja aktualizacji danych wymaga ściągnięcia kilku "stron" ze zbioru głównego (to jeszcze by przeżył) ale np 70% ze zbioru indeksowego.. Te same 70% na innych stanowiskach /procesach nie może być cachowane, bo będzie nieaktualne. Wiec bazy plikowe z definicji nie keszują indeksów wcale, lub bardzo pesymistycznie.
- duża ilość transmisji
- praca współbieżna jest jakoś-tam możliwa (nie wnikam w licencje), ale szybko dochodzi do wąskiego gardła.
- dostęp R/W do fizycznego pliku bazy - lepiej zrozumiesz, jak przyjdzie jakiś wirus, który szyfruje pliki
- jak duża ilość transmisji, a klient jest "niepewny" (np biurwa, która wyłączy zasilanie, bo swój Enter ona już wcisnęła) - znaczne szanse na uszkodzenie danych. Access jest profesjonalnym produktem, dzieje sie to rzadko, a jak się dzieje, da się naprawić toolem (przynajmniej zawsze mi się jak do tej pory dało) - ale blondynką przez telefon tego nie przeprowadzisz
- dla baz plikowych nie istnieje jakaś sprofesjonalizowana procedura backupu. a) każdy może to zrobić na swoje pendraka - i zaje..ć do konkurencji b) nikt nie zrobi, bo dane będą zajęte.
Po drugie mocno odchodząca od standardów SQL
To boli:
- budujesz swoja wiedzę mocno nieprzenośną
- jak zajdzie przymus konwersji, oj będzie trudno.
Podobnie jak projekty wykorzystujące każdy możliwy feature MySQL-a. To się fajnie używa, wchodzi w to coraz wiecej, ale potem jest buuu...
2
Po trzecie, i to nie dotyczny samej bazy.
prawie zawsze mi to się wiąże z "lokalnym guru Excell/VBA", ja jakoś takiego pecha mam, że jeszcze nie trafiłem na gościa, który by się rozwijał, coś solidnego czytał, dobrze organizował projekty w jakieś moduły / warstwy, uznawał, że skorzystałby pracując pod jakimś "seniorem": itd
Być może tacy istnieją, a ja mam pecha.
0
Ale czy "serwer" nie jest też swoistym plikiem? Przecież każdą informację zapisaną na dysku w taki czy inny sposób można nazwać plikiem. Sam plik access może mieć przecież też lokalizację ukrytą (i zewnętrzną znajdującą się z dala od przypadkowego wyłączenia zasilania) umożliwiającego w niego ingerencję.
0
2
Dodaj do tego ograniczenie danych do 2GB. Powyżej plik nie pojedzie.
0
Cały czas @eninede nie powidzałąś/łęś co to za system w pewnych rozwiązaniach się sprawdza w pewnych nie. Trochę wygląda, że nie do końca ogarniasz te serwery, bazy itp itd i wybór technologi należałoby zostawić komuś z taką wiedzą. Parę razy widziałem wydziergane systemy w Accessie bez zachowania podstawowych zasad sztuki.
2
Taka bez serwerowa czy tam plikowa baza danych (choć wolę SQLite zamiast Access) jest fajna jak się ma aplikację używaną przez jedną osobę. Np SQLite jest często używany w aplikacjach mobilnych do trzymania danych aplikacji na telefonie użytkownika.
Jeżeli z aplikacji ma korzystać więcej niż jedna osoba to wtedy lepiej postawić centralny serwer bazodanowy (choćby nieduży) bo lepiej się skaluje i łatwiej jest tym zarządzać.
2
S4t napisał(a):
Pytanie, jaki to system. Ale jak dobrze pamiętam to do Accessa może mieć dostęp tylko jedne użytkownik jednocześnie. No i trzeba mieć licencje gdzie bazy jak postgres czy mysql (nie polecam) są za free.
Uściślijmy trochę. Sam format bazy mdb/accdb pozwala na wielodostęp. Jeżeli aplikacja jest rozdzielona od danych (czyli jeden plik na dane, drugi na "front").
Korzystanie z pliku danych nie wymaga, licencji, łączymy się do pliku nie jest wymagana aplikacja Access.
Jeżeli jednak chcemy mieć całą aplikację w Accessie, to końcowy użytkownik nie musi mieć licencji na Access. Wystarczy mu wersja runtime tego produktu.
@eninede: Proponuje się dokształcić. To że serwer bazodanowy, zapisuje dane w plikach nie czyni go bazą plikową.
Rozmiar bazy 2GB można obejść, ale to nie rozwiąże problemów uzytkowników z wydajnością. Twoja aplikacja przestanie wyrabiać i żadne rozbijanie na osobne pliki Cię nie uratuje. Możesz też mieć scenariusz, że tabela sama w sobie przekroczy limit danych i wtedy to ją będziesz dzielił na 2 pliki i działał na unionie?
Nie wiem co tam piszesz, ale to wszystko jest policzalne i spokojnie możesz policzyć rozmiar jaki osiągniesz w okresie czasu. Jeżeli jednak już szukałeś sposobu na obejście limitu rozmiaru, to poszedłbym w serwer bazodanowy.
Zapominasz też o czymś takim jak utrzymanie. Usunięcie danych z tabel nie zmniejsza rozmiaru pliku, czyli dochodzi ci reguralne kompaktowanie, przy tym rozwiązaniu wystarczy, że jeden użytkownik się nie wyloguje i już proces się nie powiedzie.
Żeby nie było, używam plików accessa, ale w momencie jak potrzebuje zapisać dane lokalnie dla 1 instancji programu użytkownika. Nie oparłbym jednak na nim rozwiązania dla wielu użytkowników.
0
Panczo napisał(a):
S4t napisał(a):
@eninede: Proponuje się dokształcić. To że serwer bazodanowy, zapisuje dane w plikach nie czyni go bazą plikową.
...a jaką?
Mimo, że do plików serwera nie masz bezpośredniego dostępu bo są zaszyfrowane to nadal rekordy/dane zapisywane są w plikach i tak czy inaczej to jest to też baza plikowa. Serwerowość SQL wynika przecież z jego zewnętrznej wydzielonej natury, a nie budowy. Konstrukcja bazy plikowej nie jest ściśle zdefiniowana i przecież zależy od nas lub od koncepcji serwera.
1
A do czego konkretniej ta baza danych ma być wykorzystana? Bo patrząc na tagi, to możesz mieć na myśli jakąś aplikację desktopową, która przechowuje dane lokalnie. Natomiast mam wrażenie, że komentujący tutaj ludzie mają bardziej na myśli aplikacje webowe.
0
ly000 napisał(a):
A do czego konkretniej ta baza danych ma być wykorzystana? Bo patrząc na tagi, to możesz mieć na myśli jakąś aplikację desktopową, która przechowuje dane lokalnie. Natomiast mam wrażenie, że komentujący tutaj ludzie mają bardziej na myśli aplikacje webowe.
Pytanie było o ogólne zastosowanie, ale w zamyśle - koncepcja miałaby opierać się o aplikację desktopowej łączącej się z bazą danych na zewnętrznym serwerze/lokalizacji zdalnej.
5
eninede napisał(a):
(...) i Co "złego" jest w bazie danych access i dlaczego lepsze są inne rozwiązania?
Nie są lepsze tylko stworzone w innym celu. To pytanie w stylu dlaczego jabłko jest lepsze od śrubokręta?
Nie należy pisać, że jakieć rozwiązanie jest do bani argumentując to zestawianiem jego cech z narzędziami, które służą do czegoś innego.
Zarówno Excel jak i Access są specyficznymi rodzajami aplikacji bardzo ułatwiającymi życie milionom użytkowników na całym świecie.
Osobiście nigdy nie korzystałem z nich w zaawansowany sposób jednak wiem, że w pewnych obszarach są niezastąpione.
Wielodostęp, szybkość wyszukiwania, ograniczenia wielkości w porównaniu z klasycznymi bazami SQL oczywiście występują ale mimo to nadal mamy potężny obszar zastosowań gdzie te ograniczenia nie stanowią problemu.
Coś co ma lepsze parametry nie zawsze jest lepsze dla użytkownika - mam wrażeniem że niektórym bardzo ciężko jest to zrozumieć.
Cięższy i większy młotek nie zawsze jest lepszy od małego a w niektórych przypadkach mała wiertaka na baterię sprawdzi się dużo lepiej niż kombajn do obróbki CNC.
Podstawowe zalety Access to:
- dostępność dla niemal każdego użytkownika, który nie musi wiedzieć czym są bazy danych, znać SQL, umieć instalować serwerów;
- wszystko mamy w jednym pliku zapisanym na pulpicie obok zdjęcia wnuczka lub córeczki;
- duża ilość materiałów do nauki;
- można ogarnąć tym większość prostych analiz nie wymagających wielodostępu;
- świetne dla tych co chcą sobie pogrzebać w danych a nie chcą zostać programistami;
- ma wbudowane narzędzie do tworzenia formularzy i raportów (wszystko banalne w użyciu dla średnio ogarniętego człowieka nie programisty);
- ma możliwość pracy na plikach excel i połączeniu z niemal dowolną bazą SQL MSSQL, Oracle, MySQL itp...
Nie polecałbym:
- programistom aby na postawie tego uczyć się baz danych bo nie w tym celu to stworzono.