Dlaczego SQL nie jest tak rozpowszechniony w dużych aplikacjach komputerowych?

Jako programista pracowałem nad projektami od małych domowych aplikacji po średnie aplikacje dla przedsiębiorstw. W prawie każdym projekcie korzystałem z bazy danych lub żałowałem, że nie korzystałem z niej od samego początku.

Zastanawiam się teraz kilka rzeczy na temat baz danych i ich wykorzystania w ogólnych aplikacjach:

• Dlaczego sam system Windows nie korzysta z żadnej „centralnej” bazy danych SQL? Na przykład:
  • Błędy Zgłaszanie danych jest przechowywane w wiązce plików,
  • Windows Update przechowuje wszystko w plikach płaskich,
  • Pamięć podręczna ikon jest przechowywana w bardzo dziwnym pojedynczym pliku, do którego wydaje się, że nie można uzyskać dostępu przez SQL itp.
• Dlaczego tak wiele dużych aplikacji unika korzystania z baz danych? Na przykład, czy Microsoft Outlook nie zyskałby na tym, że używałby prawdziwej bazy danych zamiast wymyślać koło, mając swój własny format plików .pst i przechowując niektóre dane w rejestrze?

Jeśli baza danych dodaje dodatkową warstwę o ogólnej złożoności i niewielkiej utracie wydajności, jest to ogromna zaleta polegająca na uproszczeniu kodu w większości przypadków, zwłaszcza jeśli chodzi o przechowywanie małych zorganizowanych porcji danych zamiast dużych plików binarnych strumienie. Dlaczego więc tak niewiele produktów korzysta z baz danych? Prawdopodobnie jedyną aplikacją, którą znam, która faktycznie korzysta z bazy danych Sqlite, jest Firefox, a może Microsoft Exchange (ale ta ostatnia nie jest aplikacją komputerową)?

Ponadto zestaw aplikacji, takich jak Microsoft Office lub Microsoft Expression, nie skorzystałby na zunifikowanej bazie danych SQL , która ułatwiłaby wdrażanie aplikacji, aktualizację / aktualizację danych, udostępnianie danych między tymi aplikacjami, tworzenie kopii zapasowych itp.?

1) Ogólnie mówiąc, narzut związany z uruchomieniem pełnego RDBMS jest zbyt duży i spowodowałby niepotrzebne obciążenie systemu i złożoności.

Zainstalowanie jednego z nich ułatwia życie programistom, ale pogarsza życie właściciela maszyny, ponieważ maszyna może działać wolniej i ma więcej problemów. W konfrontacjach między programistami a użytkownikami użytkownik prawie zawsze powinien wygrywać.

2) Wiele magazynów danych ma określone potrzeby, które nie są zaspokajane przez coś takiego jak SQL Server Express.

Na przykład dzienniki błędów powinny być zapisywane w najprostszej możliwej rzeczy, aby zmaksymalizować szansę, że nastąpi zapis i dane będą dostępne. SQL Server nigdy nie będzie tak prosty.

W przypadku bardziej złożonych aplikacji argumentem jest raczej optymalizacja do bardzo konkretnych przypadków użytkowników - płaskie pliki mogą być błyskawiczne.

Osadzanie wielu aplikacji SQLite . Cytowanie z ich strony internetowej:

SQLite to biblioteka oprogramowania, która implementuje niezależny, bezserwerowy, transakcyjny silnik bazy danych SQL. SQLite to najczęściej wdrażany silnik bazy danych SQL na świecie. Kod źródłowy SQLite jest w domenie publicznej. ”.

Wystarczy użyć jednego z dostępnych interfejsów API, utworzyć bazę danych, tabele itp., A silnik SQL zapisze wszystko w pliku binarnym, który można umieścić w dowolnym miejscu w systemie plików użytkownika. A co najważniejsze, to FLOSS.

System Windows jest dostarczany z silnikiem bazy danych o nazwie Extensible Storage Engine (ESE) i korzysta z niego .

ESE jest używany przez Active Directory, Exchange Server, Windows Mail i Desktop Search wśród wielu innych usług i aplikacji Windows.

Do opracowania istnieją opakowania ESE typu open source:

• Zestaw narzędzi ESE C # / C ++ 1.2
• ManagedEsent dla platformy .NET

Dzięki wysyłce ESE z każdą nowoczesną wersją systemu Windows nie ma obaw o wdrożenie bazy danych. Architektonicznie ESE pełni rolę podobną do wbudowanych baz danych, takich jak SQLite.

Relacyjne bazy danych nie są najbardziej wydajną strukturą danych dla każdej domeny. Wiele aplikacji komputerowych korzysta z wbudowanych baz danych, po prostu nie można łatwo powiedzieć, że robią to, jeśli widzisz tylko kilka plików danych.

Dlaczego sam system Windows nie korzysta z żadnej „centralnej” bazy danych SQL?

W rzeczywistości pomysł ten był rozwijany w firmie Microsoft od pewnego czasu. Nazywa się WinFS . Jest to intrygująca technologia i jest dostępna dla subskrybentów MSDN. Niedługo zamierzam zainstalować go na maszynie wirtualnej i bawić się nim.

Bazy danych oferują elastyczność i jak każda funkcja prawie na pewno wiąże się z pewnymi kosztami. Jeśli plik płaski będzie działał, możesz założyć, że nikt nie będzie musiał wyszukiwać danych w nieoczekiwany sposób, jak w raporcie ad hoc.

Bazy danych wykonują również dobrą robotę, obsługując wiele połączeń / danych wejściowych. Ponownie, jeśli nie jest to wymagane w przypadku aplikacji komputerowej, po co dodawać dodatkową złożoność? Poza interfejsem użytkownika / samą instalacją programu Outlook, ile innych aplikacji lub użytkowników próbuje zapisać w pliku programu Outlook na komputerze?

Byłoby łatwiej, gdyby wszystkie dane znajdowały się w relacyjnej bazie danych z perspektywy „Chcę móc przesyłać zapytania do wszystkich danych w dowolny sposób zgodny z jednym językiem, takim jak SQL”, ale w wielu aplikacjach rzadko jest to priorytet.

Większość programistów patrzy na to z:

• Wiem, co powinna robić aplikacja, to wszystko, co powinna robić

• moja aplikacja jest jedynym podmiotem, który będzie kiedykolwiek uzyskiwał dostęp do tych danych i / lub manipulował nimi

• zadziała prosta struktura plików mojego projektu

• dla co najmniej jednej aplikacji chciałbym uniknąć polegania na kodzie innych osób i mieć pełną kontrolę.