Ujednolicenie programowania i zapytania do bazy danych [zamknięte]

Rozważ wspólny samouczek dla obiektowych języków programowania, takich jak C ++ lub Java: utwórz prosty system przetwarzania zamówień z obiektami reprezentującymi konta, zamówienia, przedmioty itp. (Lub coś mniej więcej równoważnego). Ma to intuicyjny sens, ale słoń przy stole jest taki, że to nie jest prawdziwe, ponieważ są to przedmioty w pamięci; w prawdziwym systemie rachunki, zamówienia itp. w rzeczywistości nie żyją w pamięci , lecz w bazie danych, a ich pamięć stanowi jedynie krótkotrwałe zwierciadło.

Możesz sam napisać dużo kodu do odczytu i zapisu z bazy danych, ale jest to tak żmudne i podatne na błędy, że tak naprawdę nikt tego nie robi.

Wszyscy ostatecznie używają ORM, ale te są tak problematyczne, że słynny artykuł nazywa ich „Wietnamem naszej branży”.

Nie sądzę, że jest to niedopasowanie między obiektem a relacją tak bardzo, jak niedopasowanie między językiem programowania a bazą danych, będące oddzielnymi rzeczami, które się nie znają . Przypuszczenie: rozwiązaniem jest posiadanie jednego języka, który jest zarówno językiem programowania, jak i językiem zapytań do bazy danych, co z kolei wymagałoby, aby językiem wykonawczym języka była również baza danych, a kompilator JIT był również optymalizatorem zapytań.

Oto podsumowanie problemów, które widzę. Moje pytanie brzmi: czy ktoś jeszcze

1. W rzeczywistości zbudował taki ujednolicony system

2. Próbowałem, ale nie udało się zbudować takiego zunifikowanego systemu

3. Napisałeś cokolwiek znaczącego na temat tego, jak poszedłbyś o budowaniu takich lub dlaczego lub dlaczego nie

4. Czy masz alternatywny sposób rozwiązania problemu?

To jest moja opinia. Chociaż widzę, skąd pochodzisz, po prostu nie widzę, aby działo się to z perspektywy projektowania.

Trwałość danych to niezwykle złożony temat. Podobnie są języki programowania. Połączenie tych dwóch elementów spowodowałoby eksplozję złożoności. Zajmie to dużo wysiłku, aby uczynić oba wystarczająco dobrym, aby ludzie naprawdę chcieli z niego skorzystać. Myślę, że wspomniany już MUMPS jest dobrym przykładem. Lub możesz spojrzeć na różne warianty SQL, które mają na sobie pełny język. Mogą być użyteczne, ale nie sądzę, by ludzie chętnie z nich skorzystali.

Tak więc ich rozdzielenie jest jasnym sposobem rozwiązania tej złożoności. Ponadto, nie wiążąc ich ze sobą, pozwala to na zmianę i ewolucję w czasie. Na przykład SQL jest stary i niewiele się zmienił od czasu jego utworzenia. Jednak języki używane do uruchamiania aplikacji zmieniły się drastycznie w tym samym okresie. A teraz dzieje się odwrotnie. Języki pozostają w większości takie same, podczas gdy bazy danych są zmieniane i ewoluowane.

Innym problemem jest wdrożenie środowiska wykonawczego. Połączenie tych dwóch oznaczałoby, że zarówno baza danych, jak i aplikacja lub serwer WWW musiałyby działać w tym samym procesie. Jest to niezwykle ograniczające, zarówno z punktu widzenia konserwacji, jak i możliwości uruchamiania ich na osobnych komputerach lub w relacjach wiele do jednego.

Podział tych dwóch modułów na osobne moduły z przejrzystym interfejsem API między nimi jest najlepszym sposobem na ograniczenie złożoności i zapewnienie elastyczności w zakresie technologii, których chcesz używać i sposobu wdrażania ostatecznych elementów.

Wygląda na to, że dokonujesz pewnych głównych założeń. Na przykład zakładasz, że wszyscy piszą do relacyjnych baz danych. Po prostu tak nie jest, istnieje wiele przykładów baz danych innych smaków (obiekt dbs, dokument dbs itp.), Które używają rodzimego języka programowania do pisania całego kodu i zarządzania trwałością.

Na przykład Db4O jest kompatybilny zarówno z Javą, jak i C #, ObjectDB w Javie, VelocityDB w różnych językach. Sterowniki MongoDB kończą się tym, że piszesz rzeczy w swoim ojczystym języku programowania (premia, jeśli robisz JavaScript, ponieważ oznacza to, że powłoka używa również tej samej składni) i tak dalej.

W różnych miejscach toczy się wiele dyskusji na temat tego, które silniki DB są lepsze w jakich kontekstach i dlaczego, o wiele za dużo dla zakresu tej odpowiedzi, zamieścić zamknięte pytanie na tej samej stronie. Rezultatem jest to, że każdy z nich jest zoptymalizowany pod kątem różnych rzeczy i do niedawna SQL był uważany za „najniższy wspólny mianownik” dla aplikacji biznesowych, ponieważ dostajesz dużo za darmo pod względem ACID i wydajności (chociaż oba się zmieniają ostatnio, gdy zmieniają się architektury i wymagania).

Warto również zauważyć, że wcześniej istniało wiele podejść typu „wszystko w jednym”. Języki komputerów mainframe często mają wbudowaną własną logikę trwałości, a istnieją języki takie jak Smalltalk, które w ogóle nie rozróżniają kodu od danych. Ponownie, często są dobre dla niektórych przypadków użycia, ale nie dla wszystkich.

1. Tak (nie ja). Nazwano świnkę .

2. Zgodnie z tym poprzednim pytaniem SE.SE lub tym artykułem , MUMPy nie były bardzo dobrze zaprojektowane. Ale rzeczywiście był używany w branży medycznej (i myślę, że nadal istnieją systemy, które go używają), więc nie jest to całkowita awaria.

3. Na pewno znajdziesz informacje na ten temat, teraz wiesz, czego szukać. Zacznij od powyższego linku do Wikipedii.

4. Szukaj baz danych zorientowanych obiektowo, wiele z nich jest specyficznych dla języka. Próbowali rozwiązać problem niedopasowania obiektowo-relacyjnego w prostszy sposób niż ORM.

Rzeczywiście istnieje wiele systemów, które ujednolicają bazę danych i język programowania w jednym środowisku.

Smalltalk jest prawdopodobnie najbliżej tego, co opisujesz. Obiekty w pamięci są utrwalane w „obrazie”, więc środowisko językowe może być używane w bazie danych (obiektowych) od razu po wyjęciu z pudełka. Większość współczesnego języka ma wbudowany mechanizm trwałości, co oznacza, że ​​obiekty w środowisku językowym mogą być utrwalane i sprawdzane przy użyciu samego języka.

Jest to bardzo wygodne w przypadku aplikacji dla jednego użytkownika. Ale podejście nie będzie skalowane do wielu użytkowników, ponieważ będą oni potrzebować tego samego miejsca w pamięci, co oczywiście ogranicza liczbę użytkowników. Skalowalne rozwiązanie wymaga osobnego serwera bazy danych, który zarządza współbieżnością. Nawet wtedy istnieje wiele baz danych NoSql, które integrują się z określonym środowiskiem językowym i pozwalają na utrwalanie i odpytywanie obiektów w samym języku.

Z relacyjnej strony rzeczy mamy takie języki, jak T-SQL, który jest pełnoprawnym językiem programowania, który jest nadzbiorem SQL, więc zapytania i DML można przełączyć z dowolną złożoną logiką proceduralną. Złożona aplikacja biznesowa została zbudowana przy użyciu T-SQL, więc z pewnością jest to wykonalne, ale obecny trend polega na oddalaniu logiki biznesowej od bazy danych.

W takich przypadkach integracja bazy danych z językiem programowania jest naprawdę bardzo elegancka i wygodna, co pozwala uniknąć „niedopasowania impedancji”. Dlaczego więc ludzie nadal używają relacyjnych baz danych oddzielnie od środowiska programistycznego i próbują łączyć się z jakimś ORM-kludge?

Okazuje się, że istnieje szereg zalet oddzielenia danych i zapytań od jakiegokolwiek konkretnego języka programowania i środowiska.

• Niezależność danych. W większości organizacji dostęp do danych ma wiele aplikacji. Sklep może mieć bazę danych używaną przez interfejs WWW, narzędzie obsługi klienta, silnik raportowania i tak dalej. Same dane są często długotrwałe, a aplikacje przychodzą i odchodzą. Łączenie danych z jednym konkretnym środowiskiem programowania byłoby zablokowane w określonym środowisku programowania. Ale języki programowania pojawiają się i znikają, a dane żyją wiecznie.
• Zapytania ad hoc. Jest niezwykle wygodne, aby móc otworzyć monit bazy danych i napisać zapytanie. Gdyby zapytania były ściśle powiązane ze środowiskiem programistycznym, byłoby to zadanie programistyczne i tylko programiści mogliby to zrobić.
• Unikaj blokady. Ponieważ SQL jest standardem, wielu dostawców może zapewnić systemy zarządzania bazami danych, które są mniej więcej wymienne. Pozwala to uniknąć blokady dostawcy i ułatwia porównywanie produktów.
• Luźne powiązanie. Dobrze zdefiniowany interfejs między warstwą aplikacji a bazą danych umożliwia dostrajanie i optymalizację bazy danych niezależnie od logiki aplikacji.
• Wspólny interfejs. Ponieważ interfejs bazy danych jest niezależny od logiki aplikacji, gotowe narzędzia mogą być używane do profilowania, replikacji, analizy itd.

To całkiem dobre pytanie, które wielokrotnie analizowałem w głowie. Jednym z przykładów istniejącego rozwiązania problemu jest baza danych grafów ArangoDB, w której używasz JavaScript (działającego na silniku wewnętrznym) do pisania kontrolerów, które mogą generować całe strony internetowe. Dane są przekazywane do / z pamięci przy użyciu JSON, więc są natywnie dostępne w JavaScript, a zapytania są wykonywane we wbudowanym języku zapytań. Ten przypadek jest przykładem rozszerzenia JavaScript do uruchomienia w bazie danych.

W praktyce tacy administratorzy nie powinni być narażani na działanie opinii publicznej ze względu na błędy w konfiguracji bazy danych lub błąd spowoduje ujawnienie twoich cennych danych opinii publicznej.

Moim osobistym zdaniem jest to dobre podejście i biorąc pod uwagę, czy baza danych obsługuje rodzaj funkcji mapowania / zmniejszania, która aktualizuje zagregowane dane / indeksy tekstowe i inne często wyszukiwane dane w czasie rzeczywistym, dodając cienką warstwę bezpieczeństwa pomiędzy nimi (nazwij to ładowaniem balancer) sprawiłoby, że funkcjonalna aplikacja działałaby w rozproszonej bazie danych.

1. W rzeczywistości zbudował taki ujednolicony system

Tak, zrobiłem to w Sciter .

Skrypt Sciter to „ JavaScript ++ ”, który ma wbudowaną trwałość:

var ndb = Storage.open(pathname);
ndb.root = { ... root object ... };

Gdzie ndb.rootjest normalny Obiekt pod względem JS. Wszystkie dostępne w nim właściwości i podobiekty są trwałe - w razie potrzeby przechowywane i pobierane do bazy danych - w sposób przezroczysty dla kodu:

ndb.root.accounts[2].firstName = "John";
var name = ndb.root.accounts[3].firstName;

Dane są przechowywane w DB albo w cyklu GC, gdy nie ma wystarczającej ilości pamięci, albo na wyraźne ndb.commit()wywołanie.

Storageklasie towarzyszy Indexklasa - trwałe zbiory uporządkowane obiektów z unikalnymi / nieunikalnymi kluczami.

Zestaw funkcji jest podobny do MongoDB lub innych baz danych NoSQL, ale identyfikator nie wymaga oddzielnego ORM - dostęp do bazy danych jest wykonywany wyłącznie za pomocą skryptu.

Jestem za to absolutnie i nie mam pojęcia, od czego zacząć. SQL może być genialny i wyobrażam sobie, że wspaniale byłoby mieć całą tę moc, a transakcyjne gwarancje w twoim uniwersalnym języku programowania (zamiast pisać zapytania jako kolekcje ciągów lub używać, na Boga, ORM).

Jedyny system zbliżający się do twojego pomysłu, o którym wiem, nazywa się aquameta (wiersz: „web dev stack zbudowany w PostgreSQL”; patrz https://github.com/aquametalabs/aquameta , http://aquameta.org ). Niektóre filmy wprowadzające nie są mniej szalone niż sam pomysł (youtube.com/watch?v=jz74upW7TN0, youtube.com/watch?v=cWGm9eYUYUk&t=29s, youtube.com/watch?v=xRoUQGUmiMg), a kiedy mówię szalony, mam na myśli to, że wdrożyli własny edytor i własny system kontroli wersji w Postgres.

Myślę, że było to dokładnie uzasadnienie wynalezienia przez Microsoft LINQ. Od wielu lat jest wykorzystywany w produkcji na pełną skalę, więc łatwo jest znaleźć literaturę na ten temat i refleksje z rzeczywistych doświadczeń, zarówno pozytywne, jak i negatywne. (Większość sklepów deweloperskich .net przyjmuje to.)

Dobry punkt wyjścia na linq: https://docs.microsoft.com/en-us/dotnet/csharp/linq/