ФорумПрограммированиеPythonDjango → Обсуждение ORM vs SQL

Обсуждение ORM vs SQL

  • AlexB

    Сообщения: 4306 Репутация: N Группа: в ухо

    Spritz 26 июня 2012 г. 19:37, спустя 2 минуты 49 секунд

    Это продолжение поста


    Очередное подтверждение, что ОРМ для SELECT запросов - зло пиздецовое.
  • adw0rd

    Сообщения: 22959 Репутация: N Группа: в ухо

    Spritz 26 июня 2012 г. 13:35, спустя 17 часов 57 минут 55 секунд


    Очередное подтверждение, что ОРМ для SELECT запросов - зло пиздецовое.
    не понял как ты пришел к этому суждению из этого топика
    https://smappi.org/ - платформа по созданию API на все случаи жизни
  • AlexB

    Сообщения: 4306 Репутация: N Группа: в ухо

    Spritz 26 июня 2012 г. 14:24, спустя 48 минут 33 секунды

    Ну вместо короткой строчки с DISTINCT непосредственно в запросе пришлось написать 12 строк кода. И так на каждую, чуть нестандартную конструкцию. В итоге проект обрастает кучей хаков.
  • adw0rd

    Сообщения: 22959 Репутация: N Группа: в ухо

    Spritz 26 июня 2012 г. 14:41, спустя 16 минут 57 секунд


    Ну вместо короткой строчки с DISTINCT непосредственно в запросе пришлось написать 12 строк кода. И так на каждую, чуть нестандартную конструкцию. В итоге проект обрастает кучей хаков.
    Какой короткой строчки? В MySQL нету DISTINCT ON, который как раз я и пытался сэмулировать, в SQL теперь тоже придется хакать

    > непосредственно в запросе пришлось написать 12 строк кода
    В запросе надо только писать .distinct('field1', 'field2'), никаких более строчек не надо

    > И так на каждую, чуть нестандартную конструкцию
    На прошлом месте работы у нас в проекте было очень много SQL - это был кашмар.
    Для своего проекта я использую только ORM, мне его вполне хватает. Бывает конечно что надо UNION (редко, но бывает), то гда я просто сливаю квересеты и сортирую по необходимости, но в любом случае это мелочи по сравнению с тем как меня спасает и радует ORM

    Надо просто сильно себя не связывать с РСУБД, они хорошие, но хороши в плане табличных отчетов, а не для хранения объектов, поэтому я абстрагируюсь от реалиционной их природы и юзаю только ORM.
    Спустя 157 сек.
    Вообщем я не понимаю твоих негодований, либо они пройдут со временем, если будешь использовать ORM, либо ты закоренелый адепт SQL.
    Когда-то и SQL пришел со своей философией управления данными, теперь ORM диктует как надо работать, ничего в этом плохого нет, потом ещё что-то появится и снова будут недовольные
    https://smappi.org/ - платформа по созданию API на все случаи жизни
  • AlexB

    Сообщения: 4306 Репутация: N Группа: в ухо

    Spritz 26 июня 2012 г. 15:00, спустя 19 минут 13 секунд


    Какой короткой строчки? В MySQL нету DISTINCT ON, который как раз я и пытался сэмулировать, в SQL теперь тоже придется хакать
    ну не DISTINCT, а GROUP BY
    суть разве в этом?


    Вообщем я не понимаю твоих негодований, либо они пройдут со временем, если будешь использовать ORM, либо ты закоренелый адепт SQL.
    Я закоренелый адепт SQL. Мне он кажется более гибким и читабельным, чем ОРМ-ские конструкции, которые ИМХО противоречат окамовскому принципу. )))
    Но юзаю ОРМ, потому что такая политика проекта. Но самое смешное, что один хрен находятся запросы, которые ну никак в ОРМ не влезают, и на всю эту политику приходится время от времени класть болт.
    Спустя 233 сек.
    Например вот, запрос считает командный рейтинг стран в биатлонном турнире:
                    '''
                   SELECT points_filter.id as id, COALESCE(PC.correction, 0) + points_filter.points as points, PC.correction as correction FROM (
                       SELECT id, array_sum(arr_points[0:array_length(arr_points, 1) - {bad_result_count}]) as points FROM (
                           SELECT id, array_agg(points) as arr_points FROM (
                               SELECT
                                   T.country_id as id,
                                   P.points as points
                               FROM
                                   {sport}_result as R
                                   JOIN {sport}_competition as C ON R.competition_id = C.id
                                   JOIN {sport}_event as E ON C.event_id = E.id
                                   JOIN sports_placepointsschema as S ON E.place_points_schema_id = {place_points_schema_id}
                                   JOIN sports_placepoints as P ON P.schema_id = S.id
                                   JOIN {sport}_team as T ON R.team_id = T.id
                                   JOIN gaming_pro_region as O ON T.country_id = O.id
                               WHERE
                                   E.id IN ({ids_events})
                                   AND R.team_id IS NOT NULL
                                   AND C.sportsmans_category IN ({sportsmans_category})
                                   AND P.place = R.finish_position
                                   {competition_type}
                               ORDER BY T.country_id, points DESC
                           ) points_agg GROUP BY id
                       ) as points_sum
                   ) as points_filter
           LEFT JOIN biathlon_pointscorrection as PC ON points_filter.id = PC.country_id AND PC.event_id = {id}
                   WHERE points > 0 ORDER BY points DESC
                   '''.format(
                           id = self.id,
                           bad_result_count = self.bad_result_count,
                           sport = self.params['sport'],
                           place_points_schema_id = self.place_points_schema_id,
                           ids_events = ','.join([str(e.id) for e in self.get_descendants()]),
                           sportsmans_category = ','.join([str(s) for s in sportsmans_category]),
                           competition_type = ' AND C.competition_type_id = ' + str(competition_type) if competition_type else '')


    Техдир, тоже большой поклонник ОРМ, уверял, что на ОРМ-е все возможно. На спор ебался с этим запросом дня два, потом плюнул. На чистом SQL я его написал и отладил минут за 20-30.
  • adw0rd

    Сообщения: 22959 Репутация: N Группа: в ухо

    Spritz 26 июня 2012 г. 15:22, спустя 21 минуту 41 секунду



    Какой короткой строчки? В MySQL нету DISTINCT ON, который как раз я и пытался сэмулировать, в SQL теперь тоже придется хакать
    ну не DISTINCT, а GROUP BY
    суть разве в этом?
    Так я и добавил это в ORM, теперь то не вроденадо ничего фиксить "на месте".
    Если ты говоришь о том, что надо постоянно фиксить Django (или люой другой фреймворк, ORM и т.д.), то это применимо вообще к фреймворкам, они нам дают некую функциональность, эволюционируют и надо им в этом помогать
    Спустя 78 сек.
    Если ты пользуешься Open Source - будь добр помочь в его развитии, при этом не важно какого софта, главное Open Source.
    Только так он эфолюционирует
    https://smappi.org/ - платформа по созданию API на все случаи жизни
  • AlexB

    Сообщения: 4306 Репутация: N Группа: в ухо

    Spritz 26 июня 2012 г. 15:31, спустя 9 минут 46 секунд


    Если ты говоришь о том, что надо постоянно фиксить Django (или люой другой фреймворк, ORM и т.д.), то это применимо вообще к фреймворкам, они нам дают некую функциональность, эволюционируют и надо им в этом помогать
    Дык в том-то и дело, что никакой новой функциональности ОРМ не дает … это то и напрягает, функциональности нет, а фиксить надо.
  • adw0rd

    Сообщения: 22959 Репутация: N Группа: в ухо

    Spritz 26 июня 2012 г. 15:48, спустя 16 минут 10 секунд

    AlexB, мне дает и очень даже много, не надо городить кучу строк SQL для JOIN, особенно с many-to-many, можно скрывать логику получения данных, например:
    self.queryset.filter(field__search="data")
    при этом orm сходит в sphinx, заберет оттуда id, всунет их в запрос и выполнит
    и все это прозначно

    Спустя 88 сек.
    а так тебе придется, без использования ORM писать свои методы моделей для получения данных, потом добавлять к ним логики, копировать в другие места функционал… и что получится? свой-не-до-ORM в итоге
    https://smappi.org/ - платформа по созданию API на все случаи жизни
  • AlexB

    Сообщения: 4306 Репутация: N Группа: в ухо

    Spritz 26 июня 2012 г. 15:50, спустя 2 минуты 27 секунд

    Ну ладно уговорил, иногда в типовых случаях бывает удобно ))))
  • adw0rd

    Сообщения: 22959 Репутация: N Группа: в ухо

    Spritz 26 июня 2012 г. 15:50, спустя 19 секунд

    SQL прослойка над физическим хранением данных, ORM над SQL, строчек кода все меньше пишется, логикой управлять проще - профит
    https://smappi.org/ - платформа по созданию API на все случаи жизни
  • adw0rd

    Сообщения: 22959 Репутация: N Группа: в ухо

    Spritz 26 июня 2012 г. 15:55, спустя 5 минут 12 секунд


    Например вот, запрос считает командный рейтинг стран в биатлонном турнире:

    да, что-то сложное я тоже реализую на SQL, это отличный язык для составления отчётов, по сути твой запрос тоже отчёт

    Надо просто сильно себя не связывать с РСУБД, они хорошие, но хороши в плане табличных отчетов, а не для хранения объектов, поэтому я абстрагируюсь от реалиционной их природы и юзаю только ORM.

    Спустя 41 сек.

    одному мне похуй, что тема была одна, а сделали две?)

    одному мне кажется что кнопка "ХУЕТА" не работает?
    https://smappi.org/ - платформа по созданию API на все случаи жизни
  • AlexB

    Сообщения: 4306 Репутация: N Группа: в ухо

    Spritz 26 июня 2012 г. 15:55, спустя 23 часа 59 минут 6 секунд

    да
  • adw0rd

    Сообщения: 22959 Репутация: N Группа: в ухо

    Spritz 26 июня 2012 г. 16:01, спустя 6 минут 39 секунд

    AlexB, я сам по правде очень люблю SQL за его гибкость в определенных моментах, конечно гибче вообще работать с файлами, но не удобно и не безопасно для целостности и т.д. Да и много логики придется повторять из некоторых СУБД

    То же самое с Django и Python, я бы не стал писать большой-сайт-сервис-проект-что-то-ещё на чистом питоне, это не практично и надо будет решать много проблем которые не относятся напрямую к цели, я бы использовал Django (или любой другой фреймворк) и покрыл бы большинство проблем. Но Django не везде может помочь, всеравно приходится писать какие-либо библиотеки на python и пользоваться ими. Тоже самое и с ORM vs SQL.
    https://smappi.org/ - платформа по созданию API на все случаи жизни
  • Sinkler

    Сообщения: 7958 Репутация: N Группа: в ухо

    Spritz 26 июня 2012 г. 18:33, спустя 2 часа 31 минуту 18 секунд

    одному мне кажется что кнопка "ХУЕТА" не работает?

    нет, это карма)
  • kostyl

    Сообщения: 5210 Репутация: N Группа: Джедаи

    Spritz 26 июня 2012 г. 18:57, спустя 24 минуты 13 секунд

    я уже говорил, что ОРМ без поддержки plain sql и dynamic object properties - дерьмовая ОРМ. Поддерживаю ТС об неэффективности ОРМ в результате отсутсвия указанной гибкости при получение хитрожопых наборов данных…

Пожалуйста, авторизуйтесь, чтобы написать комментарий!