SQLAlchemy (ORM) kontra surowe kwerendy SQL

Question

w ciągu ostatniego miesiąca poświęciłem się badaniu platformy Flask, architektury Pythona do budowania aplikacji internetowych.

Po różnych samouczkach, które znalazłem w Internecie, odkryłem SQLAlchemy.

Szczerze mówiąc, uważam, że jest skomplikowany i niezbyt przydatny, ponieważ mam dość dobrą znajomość języka SQL.

Co chcę zrozumieć, jeśli istnieje jakikolwiek większy zysk w korzystaniu z ORM, takich jak SQLAlchemy, których mi brakuje (może jakiś problem z bezpieczeństwem w używaniu czystego sql, o którym nie wiem?).

Byłbym również wdzięczny, gdybyś mógł doradzić mi, jaka jest najlepsza biblioteka Pythona do pracy z czystymi zapytaniami SQL.

Answer 1

Jest ich wiele. Największe zalety widzę używania ORM zamiast surowych zapytań SQL to:

1. Solidność: Nie musisz się martwić o błędy składniowe można dokonać w pisanie zapytanie SQL dla różnych źródeł databse. W rzeczywistości nie musisz znać składni wszystkich źródeł DB. To samo zapytanie ORM działa dla wszystkich. Niezależnie od tego, czy jest to silnik oparty na języku SQL, taki jak MySQL, czy oparty na NoSQL silnik, taki jak MongoDB
2. Skalowalność: Przy zmianie wymagań biznesowych lub rodzaju/ilości danych, które przetwarzasz. Bardzo często zmienia się silnik bazy danych. Nie musisz martwić się o złamanie kwerendy, ponieważ ORM to obsługuje. Jedynym warunkiem jest to, że ORM powinien obsługiwać to źródło danych.
3. Bezpieczeństwo: Nie musisz się martwić o naruszeniach bezpieczeństwa ze względu na SQL Injections etc jako ORM już działa tarczę ochronną przed nimi
4. Zaufanie: Istnieje ogromne grono inteligentnych umysłów arround świata, którzy pracowali nad tworzenie ORM, zajmującego się scenariuszami i problemami, z którymi się zetknęli w czasie. Ja, jako jedna osoba, może brakować wielu aspektów. Dlatego korzystanie z ORM jest mniej podatne na nieoczekiwane problemy, z którymi możemy się zetknąć. (To nie znaczy, że ORM są idealne, ale są mniej podatne na błędy).
5. Czas: W przypadku ORM uzyskujesz wsparcie dla dużej liczby bibliotek open-source. Na przykład dla migracji danych , portalu internetowego do sprawdzania danych, serializatorów danych, itd. Dzięki temu można zaoszczędzić czas na coś o wiele ważniejszego.

Choć mają pewne skutki uboczne, a także:

1. prędkość: ORMs są wolniejsze, jak działają one jako warstwy pośredniej między kodu i wykonanie zapytania. W rzeczywistości ORM wewnętrznie tworzy to samo surowe zapytanie, aby uzyskać pożądany wynik, ORM może ograniczyć zakres implementacji. Jak już wspomniałem, działają one jako middleware. Istnieje możliwość, że silnik bazy danych obsługuje niektóre funkcje, ale nie został zaimplementowany w ORM. Ale w takim scenariuszu zawsze masz możliwość napisania surowego zapytania SQL, aby uzyskać pożądany wynik.

Lubię ORM z powodu zalet, o których wspomniałem.