Форум → Программирование → Python → Django → Обсуждение ORM vs SQL
Обсуждение ORM vs SQL
Страницы: ← Следующая страница →
-
-
26 июня 2012 г. 13:35, спустя 17 часов 57 минут 55 секунд
не понял как ты пришел к этому суждению из этого топика
Очередное подтверждение, что ОРМ для SELECT запросов - зло пиздецовое.https://smappi.org/ - платформа по созданию API на все случаи жизни -
26 июня 2012 г. 14:24, спустя 48 минут 33 секунды
Ну вместо короткой строчки с DISTINCT непосредственно в запросе пришлось написать 12 строк кода. И так на каждую, чуть нестандартную конструкцию. В итоге проект обрастает кучей хаков. -
26 июня 2012 г. 14:41, спустя 16 минут 57 секунд
Какой короткой строчки? В MySQL нету DISTINCT ON, который как раз я и пытался сэмулировать, в SQL теперь тоже придется хакать
Ну вместо короткой строчки с DISTINCT непосредственно в запросе пришлось написать 12 строк кода. И так на каждую, чуть нестандартную конструкцию. В итоге проект обрастает кучей хаков.
> непосредственно в запросе пришлось написать 12 строк кода
В запросе надо только писать .distinct('field1', 'field2'), никаких более строчек не надо
> И так на каждую, чуть нестандартную конструкцию
На прошлом месте работы у нас в проекте было очень много SQL - это был кашмар.
Для своего проекта я использую только ORM, мне его вполне хватает. Бывает конечно что надо UNION (редко, но бывает), то гда я просто сливаю квересеты и сортирую по необходимости, но в любом случае это мелочи по сравнению с тем как меня спасает и радует ORM
Надо просто сильно себя не связывать с РСУБД, они хорошие, но хороши в плане табличных отчетов, а не для хранения объектов, поэтому я абстрагируюсь от реалиционной их природы и юзаю только ORM.Спустя 157 сек.Вообщем я не понимаю твоих негодований, либо они пройдут со временем, если будешь использовать ORM, либо ты закоренелый адепт SQL.
Когда-то и SQL пришел со своей философией управления данными, теперь ORM диктует как надо работать, ничего в этом плохого нет, потом ещё что-то появится и снова будут недовольныеhttps://smappi.org/ - платформа по созданию API на все случаи жизни -
26 июня 2012 г. 15:00, спустя 19 минут 13 секунд
ну не DISTINCT, а GROUP BY
Какой короткой строчки? В MySQL нету DISTINCT ON, который как раз я и пытался сэмулировать, в SQL теперь тоже придется хакать
суть разве в этом?
Я закоренелый адепт SQL. Мне он кажется более гибким и читабельным, чем ОРМ-ские конструкции, которые ИМХО противоречат окамовскому принципу. )))
Вообщем я не понимаю твоих негодований, либо они пройдут со временем, если будешь использовать ORM, либо ты закоренелый адепт 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. -
26 июня 2012 г. 15:22, спустя 21 минуту 41 секунду
Так я и добавил это в ORM, теперь то не вроденадо ничего фиксить "на месте".
ну не DISTINCT, а GROUP BY
Какой короткой строчки? В MySQL нету DISTINCT ON, который как раз я и пытался сэмулировать, в SQL теперь тоже придется хакать
суть разве в этом?
Если ты говоришь о том, что надо постоянно фиксить Django (или люой другой фреймворк, ORM и т.д.), то это применимо вообще к фреймворкам, они нам дают некую функциональность, эволюционируют и надо им в этом помогатьСпустя 78 сек.Если ты пользуешься Open Source - будь добр помочь в его развитии, при этом не важно какого софта, главное Open Source.
Только так он эфолюционируетhttps://smappi.org/ - платформа по созданию API на все случаи жизни -
26 июня 2012 г. 15:31, спустя 9 минут 46 секунд
Дык в том-то и дело, что никакой новой функциональности ОРМ не дает … это то и напрягает, функциональности нет, а фиксить надо.
Если ты говоришь о том, что надо постоянно фиксить Django (или люой другой фреймворк, ORM и т.д.), то это применимо вообще к фреймворкам, они нам дают некую функциональность, эволюционируют и надо им в этом помогать -
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 на все случаи жизни -
26 июня 2012 г. 15:50, спустя 2 минуты 27 секунд
Ну ладно уговорил, иногда в типовых случаях бывает удобно )))) -
26 июня 2012 г. 15:50, спустя 19 секунд
SQL прослойка над физическим хранением данных, ORM над SQL, строчек кода все меньше пишется, логикой управлять проще - профитhttps://smappi.org/ - платформа по созданию API на все случаи жизни -
26 июня 2012 г. 15:55, спустя 5 минут 12 секунд
Например вот, запрос считает командный рейтинг стран в биатлонном турнире:
да, что-то сложное я тоже реализую на SQL, это отличный язык для составления отчётов, по сути твой запрос тоже отчётНадо просто сильно себя не связывать с РСУБД, они хорошие, но хороши в плане табличных отчетов, а не для хранения объектов, поэтому я абстрагируюсь от реалиционной их природы и юзаю только ORM.
Спустя 41 сек.одному мне похуй, что тема была одна, а сделали две?)
одному мне кажется что кнопка "ХУЕТА" не работает?https://smappi.org/ - платформа по созданию API на все случаи жизни -
-
26 июня 2012 г. 16:01, спустя 6 минут 39 секунд
AlexB, я сам по правде очень люблю SQL за его гибкость в определенных моментах, конечно гибче вообще работать с файлами, но не удобно и не безопасно для целостности и т.д. Да и много логики придется повторять из некоторых СУБД
То же самое с Django и Python, я бы не стал писать большой-сайт-сервис-проект-что-то-ещё на чистом питоне, это не практично и надо будет решать много проблем которые не относятся напрямую к цели, я бы использовал Django (или любой другой фреймворк) и покрыл бы большинство проблем. Но Django не везде может помочь, всеравно приходится писать какие-либо библиотеки на python и пользоваться ими. Тоже самое и с ORM vs SQL.https://smappi.org/ - платформа по созданию API на все случаи жизни -
26 июня 2012 г. 18:33, спустя 2 часа 31 минуту 18 секунд
одному мне кажется что кнопка "ХУЕТА" не работает?
нет, это карма) -
26 июня 2012 г. 18:57, спустя 24 минуты 13 секунд
я уже говорил, что ОРМ без поддержки plain sql и dynamic object properties - дерьмовая ОРМ. Поддерживаю ТС об неэффективности ОРМ в результате отсутсвия указанной гибкости при получение хитрожопых наборов данных…
Страницы: ← Следующая страница →
Пожалуйста, авторизуйтесь, чтобы написать комментарий!