Po zetknięciu się z licznymi warstwami abstrakcji bazy danych zaczynam się zastanawiać, o co chodzi w tym, że każda biblioteka wymyśla swój własny paradygmat dostępu do danych. Odbieranie nowego DAL przypomina uczenie się nowego języka od nowa, kiedy zwykle wszystko, co chcę zrobić, to po prostu przekonać warstwę do wygenerowania zapytania SQL, które już napisałem w mojej głowie.
I to nawet bez wpływu na czytelność po fakcie:
# Exhibit A: A typical DAL
rows = db(db.ips_x_users.ip_addr == '127.0.0.1')
.inner_join(db.ips_x_users.user_id == db.users.id)
.select(order=(db.ips_x_users.last_seen, 'desc'), limit=10)
# Exhibit B: Another typical DAL
rows = db.ips_x_users
.join(db.users, on=db.ips_x_users.user_id == db.users.id)
.filter(db.ips_x_users.ip_addr == '127.0.0.1')
.select(sort=~db.ips_x_users, limit=10)
# Exhibit C: A hypothetical DAL based on standard SQL syntax
rows = db('''SELECT * FROM ips_x_users
INNER JOIN users ON
(ips_x_users.user_id = users.id)
WHERE ips_x_users.ip_addr = ip
ORDER BY last_seen DESC LIMIT 10''', ip='127.0.0.1')Co jest złego w standardowej składni SQL? Został stworzony do określonego celu i doskonale pasuje do tego celu. Może to tylko ja, ale rozumiem fragment C znacznie łatwiej niż pierwsze dwa. Zmienione nazwy słów kluczowych i sztuczki składniowe są urocze, ale IMO, jeśli chodzi o to, nie ułatwiają koderowi pobierania wierszy.
To prawdopodobnie wydawało się długim rantem, ale tutaj jest prawdziwe pytanie. Ponieważ każdy DAL wydaje się wymyślać nową DSL dla zapytań, a nie tylko analizować wypróbowany i prawdziwy SQL, muszą istnieć korzyści z użycia innej składni lub braki w standardowej składni SQL, o których nie wiem, że istnieją. Czy ktoś mógłby wskazać, co tutaj przeoczam?
źródło
Odpowiedzi:
Najbardziej podstawowym problemem typowego użycia SQL jest to, że zapytania SQL są łańcuchami, które są w jakiś sposób złożone z innego języka. Stąd pochodzą zastrzyki SQL oraz inne podatności i WTF (twój przykład jest dość źle wybrany, ponieważ twoje zapytanie nie ma żadnych parametrów).
Następnym problemem jest w rzeczywistości następstwo: jeśli w kodzie jest zapisany kod SQL, kompilator nic na to nie poradzi. Błędy, takie jak literówki w nazwach kolumn, pojawią się tylko w czasie wykonywania. Zasadniczo jest to spowodowane tym, że nie chcesz reprezentować ciągu zapytania w kodzie źródłowym, ale coś, co kompilator może przeanalizować statycznie, aby zapobiec 95% wszystkich błędów facepalm.
Ostatni problem występuje, gdy próbujesz odwzorować relacyjną bazę danych na semantykę języka i model programowania: RDBMS nie idą dobrze razem z OOP (lub nawigacyjnym odzyskiwaniem danych). W rzeczywistości jest to dość okropny pomysł, łącząc te dwa, ale o to chodzi w tym wszystkim zorientowanym obiektowo DAL dla baz danych SQL (tj. ORM). Ale wszystkie te warstwy abstrakcji są skazane na wyciek. Myślę, że właśnie dlatego jest ich tak wiele: ponieważ pracujesz z nimi, widzisz, że są wadliwe, postanowiłeś napisać DAL, który robi to dobrze i ostatecznie kończy się niepowodzeniem.
Tak więc, chociaż problemy pierwszy i drugi sugerują posiadanie DAL, które pozbywają się SQL, problem trzeci implikuje, że nie ma prostego rozwiązania posiadania jednego (przynajmniej dla OOP), a zatem zawsze będzie morze DAL o różnych mocach i ograniczeniach. Ostatecznie wszystko, co możesz zrobić, to starannie wybrać kilka i trzymać się ich.
źródło
Pomija się oczywisty fakt, że nie wszystkie platformy baz danych akceptują tę samą składnię SQL, więc osadzanie instrukcji SQL w całej aplikacji po prostu nie będzie działać na każdej platformie bazy danych. Jeśli kiedykolwiek będziesz musiał obsługiwać wiele platform baz danych, będziesz musiał przemyśleć większość (jeśli nie wszystkie) tych instrukcji SQL.
źródło
Wydaje mi się, że SQL ulega tej samej zasadniczej zmianie, co wskaźniki 10 lat temu. Trwa próba wyeliminowania pracy ręcznej za pomocą SQL i przeniesienia jej na wyższy poziom abstrakcji. To samo stało się ze wskaźnikami i ręcznym zarządzaniem pamięcią wiele lat temu.
Ponieważ prace są obecnie w toku, możesz cieszyć się widokiem wielu różnych podejść sugerowanych, wypróbowanych, porzuconych i zintegrowanych. Jestem pewien, że zobaczymy ich więcej przed jakimś wspólnym podejściem lub standardem branżowym, jeśli chcesz się manifestować.
Z pewnością daje ci to przewagę, gdy możesz manipulować kodem dostępu do danych na tym samym poziomie iz tym samym paradygmatem, jaki stosujesz podczas pracy z kodem aplikacji.
W kilku słowach - uproszczenie, zwinność, szybkość - oto cele.
źródło
Joel napisał fajny artykuł 10 lat temu: Nie pozwól, aby astronauci z architektury cię przestraszyli
Myślę, że dokładnie tak jest. Użyłem warstwy abstrakcji we własnych aplikacjach, ponieważ znalazłem wzory i było mi łatwo to zrobić. Ale to był mój DAL Znałem każdy wiersz w kodzie źródłowym => pełna kontrola. Ale nie sugerowałbym, aby używać tego frameworka osobom spoza mojego zespołu / projektów.
Kiedy używasz czegoś takiego, ważne jest, aby wiedzieć, jak to jest zaimplementowane, co oznacza, że powinieneś poświęcić dużo czasu na naukę biblioteki / narzędzia. Jeśli nie masz czasu na naukę - nie używaj. Nawet jeśli od samego początku wygląda to bardzo łatwo.
źródło