Полистаю вечерком. А в двух словах можете подсказать, если есть опыт.
1. Почему тогда не делать прямые запросы в бд, если основным из аспектов SQLAlchemy сложные/более_гибкие запросы(если я правильно понял её направление). То есть на простые и типовые задачи оставить джанго-орм, а на сложные запросы не реализуемые ОРМ, делать прямые запросы в БД в обход ОРМ.
2. Работает ли SQLAlchemy с хранимыми процедурами, триггерами, евентами и тем многообразием функционала самой базы данных, с которыми не работает джанго-орм?
Мне не приходилось использовать SQLAlchemy. Я так понимаю вы про неё говорите как замену джанго-орм?
Если да, то как в джанге работать с формами, админкой, обработкой данных полученых из ОРМ… и всем тем где вызывается класс модели и потом с ним работается по сути средствами ОРМ? Если мы заменяем орм на SQLAlchemy.
А если уже написана не одна сотня тысяч строк?
Говорим про HL проект, который долго делали и развиваем. А не про мелкие штамповки на пару тысяч строк кода.
Как правило это останавливает к «быстрому» переходу на новую версию.
С учётом того, что скорее всего сидят человеки и тупо мучают гугл/яндекс по запросам «наркотики», «суицид» и так далее. И потом не разобравшись даже в тексте, а тупо найдя «страшные слова» заносят в реестр. Ничего хорошего нас не ждёт.
Вспомнить туже статью по игрушке EVE-online, где за статью как прокачивать игрового персонажа. На игровом сленге описывают использование бустеров(наркотиков/стимуляторов). Тупо внесли в реестр.
Зато 98% всех обращений к БД делать проще средствами ОРМ джанги. И только под оставшиеся 2% приходится лезть в глубину SQL`я. При этом как говорилось выше, средствами джанги удобно в последствии и обрабатывать полученные результаты. Говорю по личному, субъективному опыту.
Просто не стоит городить велосипед нагромождая кучу прямых запросов там где это не нужно. А только «узкие» и «скользкие» места.
P.S. Есть отдельная специализация «программист баз данных». Тут тоже нужно знать грань, когда питон программист бакэнда и фронтенда, лезет в дебри базы данных. При действительно большом HL проекте, стоит задумываться о вынесении обязанностей по работе с БД на отдельного специалиста. А то можно на программиста и дизайн с контентом по вешать, рассуждая что должен знать и уметь всё.
Не, ну если так рассуждать. То с помощью ОРМ сложно создавать и работать с триггерами, функциями, процедурами и много чем ещё, что позволяет SQL. Зато есть и несколько плюсов. К примеру портирования на разные БД поддерживаемые джангой. Ну или из запредельного, не обязательность глубоких знаний скуль запросов разработчиком. Достаточно ограничится знаниями ОРМ.
Плюс, джанговские связи между таблицами. ОРМ запрос на связи проще и красивее писать, чем городить прямой запрос с кучей джоинов. Так же и про вложенные запросы.
Везде есть своя грань, которую нужно понимать и применять инструменты там где это действительно нужно.
Да, можно и без user_ptr_id. Мне нужна была цифра, визуально отображаемая, сколько дублей есть. Так как делалось прямым запросом в БД, проблем выбора поля для COUNT() не ставилось. Можно смело брать другое поле из тех что есть в GROUP BY. Правда не помню, позволит ли джанговская ОРМ взять его.
«SELECT COUNT(`user_ptr_id`) as cnt, `user_ptr_id`, `p_second_name`, `p_name`, `p_third_name`, `p_phone_code`, `p_phone_numb`
FROM `personal_person`
GROUP BY `p_name`, `p_second_name`, `p_third_name`, `p_phone_code`, `p_phone_numb`
HAVING COUNT(`user_ptr_id`) > 1
ORDER BY cnt DESC»
Есть клоны профилей юзеров, зарегистрированные в разное время с совпадениями по Ф.И.О. и Телефону. Нужно вывести список всех юзеров сгруппировав по ФИОТ, показав кол-во дублей у каждого совпадения и не выводя юзеров у которых нету дублей.
Сейчас всё реализовано через такой, прямой запрос в БД :)
Пару лет назад, меня взяли в большой проект. Который существовал уже несколько лет и активно рос и развивался. При этом, я до этого писал только на пхп и работал с фреймворками пхп. А проект был на питоне и под джангой. Изучить питон и джангу, мне хватило где-то недели. И ещё недели три я вникал во все те тонны кода, написанные до меня и никак не документированные (даже комменты к классам и функциям не везде были, не говоря о строках кода).
Через год, я уже сам проводил собеседования и последующее обучение нового программиста.
Лично мне было проще(быстрее) выучить новые технологии, принципы работы, язык,… Чем понять логику реализованного функционала.
1. Почему тогда не делать прямые запросы в бд, если основным из аспектов SQLAlchemy сложные/более_гибкие запросы(если я правильно понял её направление). То есть на простые и типовые задачи оставить джанго-орм, а на сложные запросы не реализуемые ОРМ, делать прямые запросы в БД в обход ОРМ.
2. Работает ли SQLAlchemy с хранимыми процедурами, триггерами, евентами и тем многообразием функционала самой базы данных, с которыми не работает джанго-орм?
Если да, то как в джанге работать с формами, админкой, обработкой данных полученых из ОРМ… и всем тем где вызывается класс модели и потом с ним работается по сути средствами ОРМ? Если мы заменяем орм на SQLAlchemy.
Говорим про HL проект, который долго делали и развиваем. А не про мелкие штамповки на пару тысяч строк кода.
Как правило это останавливает к «быстрому» переходу на новую версию.
Вспомнить туже статью по игрушке EVE-online, где за статью как прокачивать игрового персонажа. На игровом сленге описывают использование бустеров(наркотиков/стимуляторов). Тупо внесли в реестр.
Просто не стоит городить велосипед нагромождая кучу прямых запросов там где это не нужно. А только «узкие» и «скользкие» места.
P.S. Есть отдельная специализация «программист баз данных». Тут тоже нужно знать грань, когда питон программист бакэнда и фронтенда, лезет в дебри базы данных. При действительно большом HL проекте, стоит задумываться о вынесении обязанностей по работе с БД на отдельного специалиста. А то можно на программиста и дизайн с контентом по вешать, рассуждая что должен знать и уметь всё.
Плюс, джанговские связи между таблицами. ОРМ запрос на связи проще и красивее писать, чем городить прямой запрос с кучей джоинов. Так же и про вложенные запросы.
Везде есть своя грань, которую нужно понимать и применять инструменты там где это действительно нужно.
inosmi.ru/world/20130401/207592522.html
Не знаю, было ли такое ранее, первый раз там.
www.securitylab.ru
Очередное профессиональное заболевание компьютерщиков
Еврокомиссия подала в суд на ФБР за дискриминацию хакеров
Банда “гаммельнских крысоловов” угрожает владельцам пылесосов Samsung
…
«SELECT COUNT(`user_ptr_id`) as cnt, `user_ptr_id`, `p_second_name`, `p_name`, `p_third_name`, `p_phone_code`, `p_phone_numb`
FROM `personal_person`
GROUP BY `p_name`, `p_second_name`, `p_third_name`, `p_phone_code`, `p_phone_numb`
HAVING COUNT(`user_ptr_id`) > 1
ORDER BY cnt DESC»
Есть клоны профилей юзеров, зарегистрированные в разное время с совпадениями по Ф.И.О. и Телефону. Нужно вывести список всех юзеров сгруппировав по ФИОТ, показав кол-во дублей у каждого совпадения и не выводя юзеров у которых нету дублей.
Сейчас всё реализовано через такой, прямой запрос в БД :)
Через год, я уже сам проводил собеседования и последующее обучение нового программиста.
Лично мне было проще(быстрее) выучить новые технологии, принципы работы, язык,… Чем понять логику реализованного функционала.