powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PHP, Perl, Python [игнор отключен] [закрыт для гостей] / ORM vs голый SQL
110 сообщений из 110, показаны все 5 страниц
ORM vs голый SQL
    #37883709
Возможна данная тема уже обсуждалась.
Какие есть плюсы и минусы использования ORM на проекте?

На чем быстрее разрабатывать приложение?
Позволяет ли доступ к таблицам как к объектам ускорить процесс разработки?


Ведь получается еще одна прослойка, в которой могут быть баги. Хитрые запросы писать удобнее на голом sql.

Каково Ваше мнение?
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37883737
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37883824
ScareCrow http://symfony.com/symfony-explained-to-a-developer


Вот собственно на симфонию я и пытаюсь перейти.

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

Насколько мирно это всё будет существовать с ORM?
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37883935
рубист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ORM как раз и предназначен для инкапсуляции бизнес логики, но не на уровне СУБД, а на уровне приложения.

Использовать хранимки не советую, только если очень прижмет.
Причина в том, что вам понадобится еще один разработчик для хранимок.
Если текущий специалист может это делать и сам, то найти такого в случае его ухода будет сложнее,
а значт все равно понадобится еще спец по БД.
Есть еще ряд минусов использования хранимок ....
- сложность тестирования бизнес логики
- понадобится решать, каким образом будет обеспечиватся контроль версий (svn/git)
- каким образом будет происходить развертывание хранимок на продакшн.
- как делать откат версий в случае неудачного развертывания. ...
- в конце концов, что делать если нужно перейти на SQL сервер другого вендера.
короче гемор.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37884005
Фотография SmeL_md
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
рубистИспользовать хранимки не советую, только если очень прижмет.
Причина в том, что вам понадобится еще один разработчик для хранимок.
Если текущий специалист может это делать и сам, то найти такого в случае его ухода будет сложнее,
а значт все равно понадобится еще спец по БД.
Есть еще ряд минусов использования хранимок ....
- сложность тестирования бизнес логики
- понадобится решать, каким образом будет обеспечиватся контроль версий (svn/git)
- каким образом будет происходить развертывание хранимок на продакшн.
- как делать откат версий в случае неудачного развертывания. ...
- в конце концов, что делать если нужно перейти на SQL сервер другого вендера.
короче гемор.
Как то все натянуто за уши. Нужна скорость пишите хранимки. И все эти минусы из пальца высосаны.
И про ORM тоже самое, нужна скорость отказываемся и от него.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37884013
рубистORM как раз и предназначен для инкапсуляции бизнес логики, но не на уровне СУБД, а на уровне приложения.

Использовать хранимки не советую, только если очень прижмет.
Причина в том, что вам понадобится еще один разработчик для хранимок.
Если текущий специалист может это делать и сам, то найти такого в случае его ухода будет сложнее,
а значт все равно понадобится еще спец по БД.
Есть еще ряд минусов использования хранимок ....
- сложность тестирования бизнес логики
- понадобится решать, каким образом будет обеспечиватся контроль версий (svn/git)
- каким образом будет происходить развертывание хранимок на продакшн.
- как делать откат версий в случае неудачного развертывания. ...
- в конце концов, что делать если нужно перейти на SQL сервер другого вендера.
короче гемор.

Спасибо, за развернутый ответ.

А по скорости разработки что может быть быстрее? ORM или php + голый sql?
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37884033
Фотография SmeL_md
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Начинающий ORM-щикА по скорости разработки что может быть быстрее? ORM или php + голый sql?
Скорость разработки выше с ORM чем с простым sql, а производительность наоборот
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37884155
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторСкорость разработки выше с ORM чем с простым sql, а производительность наоборот
а потом имеем сотую реализацию getById()
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37884158
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Начинающий ORM-щикБольшую часть бизнес логики хочется реализовать с помощью внутренних средств СУБД.
FK, хранимые процедуры, на крайний случай тригера.Что за СУБД, если не секрет?
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37884240
рубист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SmeL_mdрубистИспользовать хранимки не советую, только если очень прижмет.
Причина в том, что вам понадобится еще один разработчик для хранимок.
Если текущий специалист может это делать и сам, то найти такого в случае его ухода будет сложнее,
а значт все равно понадобится еще спец по БД.
Есть еще ряд минусов использования хранимок ....
- сложность тестирования бизнес логики
- понадобится решать, каким образом будет обеспечиватся контроль версий (svn/git)
- каким образом будет происходить развертывание хранимок на продакшн.
- как делать откат версий в случае неудачного развертывания. ...
- в конце концов, что делать если нужно перейти на SQL сервер другого вендера.
короче гемор.
Как то все натянуто за уши. Нужна скорость пишите хранимки. И все эти минусы из пальца высосаны.
И про ORM тоже самое, нужна скорость отказываемся и от него.

"Нужна скорость пишите хранимки" - как-то натянуто за уши и высасано из пальца :) ....

Единственное где оправдано использование хранимок это отчеты или обработка древовидных структур данных,при условии, что этих хранимок не много или у вас есть кому ими заниматься.
В остальном, скорости обычно не хватает если выбрано неудачное алгоритмическое решение или само приложение написано не качественно.
Компенсировать недостатки приложение написанием хранимок это не выход.
Мне доводилось работать с системой у которой вся бизнес логика была на хранимках ....
больше сотни таблиц и еще больше хранимок. В конторе был целый отдел, который знаимался только хранимками (T-SQL). жесть.

ORM действительно снижает скорость приложения (увиличивается количество запросов и снижается их качество),
но это решаемо, в любом ORM есть возможность писать запросы на прямую и вызывать хранимки. Зато ORM дает много других приемуществ ....
валидация, кеширование, разделение прав доступа, миграции и т.п. короче много готовых вещей, которые не нужно изобретать заново.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37884252
рубист,

наверное спорный вопрос где лучше расположить бизнес логику в t-sql или в orm.
Просто вместо отдела t-sql был бы отдел php программистов :)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37884281
рубист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Начинающий ORM-щикрубист,

наверное спорный вопрос где лучше расположить бизнес логику в t-sql или в orm.
Просто вместо отдела t-sql был бы отдел php программистов :)

Отдел программистов тоже был, как ни странно :),
но ты прав вопрос не просто и зависит от многих факторов.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37884311
Фотография SmeL_md
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
рубист"Нужна скорость пишите хранимки" - как-то натянуто за уши и высасано из пальца :) ....
Аргументы.

Единственное где оправдано использование хранимок это отчеты или обработка древовидных структур данных,при условии, что этих хранимок не много или у вас есть кому ими заниматься.
При чем здесь количество хранимок, при чем здесь штат

В остальном, скорости обычно не хватает если выбрано неудачное алгоритмическое решение или само приложение написано не качественно.
или потому что не пользуетесь хранимками т.к. нет специалиста по БД, а так как его нет вот и не справляются запросы после того как системой годик второй поработаю.

Мне доводилось работать с системой у которой вся бизнес логика была на хранимках ....
больше сотни таблиц и еще больше хранимок. В конторе был целый отдел, который знаимался только хранимками (T-SQL). жесть.

И что тут плохого :) вы тут про безопасность поразмышляйте про целосность

ORM действительно снижает скорость приложения (увиличивается количество запросов и снижается их качество),
но это решаемо, в любом ORM есть возможность писать запросы на прямую и вызывать хранимки. Зато ORM дает много других приемуществ ....
Вот тут согласен на 100%

валидация, кеширование, разделение прав доступа, миграции и т.п. короче много готовых вещей, которые не нужно изобретать заново.
Кэширование :) разделение прав уж точно дела не ORM а СУБД.
Про миграцию через ORM DBA вам бы точно руки по отрывал:)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37884341
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторПро миграцию через ORM DBA вам бы точно руки по отрывал:)
очень интересно послушать как сделать миграцию без запуска скриптов.
делать хранимку, выполнять её и тут же грохать?
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37884361
рубист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SmeL_md,

При чем здесь количество хранимок, при чем здесь штат
При том, что львиная доля расходов на проект это этап "эксплуатации\сопровождения"
Если бы 1С-шники зарулили логику в хранимки, то давно бы обонкротились.

или потому что не пользуетесь хранимками т.к. нет специалиста по БД, а так как его нет вот и не справляются запросы после того как системой годик второй .....
Я написал уже, хранимками нужно пользоватся только по делу, если действительно нет другого решения.
Но лучше старатся их избегать. Это мое ИМХО, сложившееся годами. Ни кому не навязываю.

И что тут плохого :) вы тут про безопасность поразмышляйте про целосность
Безопасность и целостность ни как не зависят от использования или не использования хранимок.
Это зависит только от прямоты рук.

Кэширование :) разделение прав уж точно дела не ORM а СУБД.
Про миграцию через ORM DBA вам бы точно руки по отрывал:)
Да, СУБД кеширует запросы, но на уровне ORM тоже есть возможность кеширования.
Разделение прав это дело приложения и ORM очень в этом помогает.
Здесь я имею ввиду не права доступа в саму СУБД, а права доступа пользователей на уровне приложения.
имхо: СУБД, по бальшому счету, должна отвечать только за получение\хранение\отдачу данных.

Мне вот интересно, как вы собираетесь обходить те минусы о которых я писал выше, при создании бизнес логики на основе хранимок?
Я их специально упомянул, так как по ним почти нет готовых решений. Наколенные велосипеды не предлагать :)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37884376
Фотография SmeL_md
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowавторПро миграцию через ORM DBA вам бы точно руки по отрывал:)
очень интересно послушать как сделать миграцию без запуска скриптов.
делать хранимку, выполнять её и тут же грохать?
Уточню что я имел ввиду.
Предположим у нас вот такая ситуация простейшая ситуация поле int4 нужно сделать int8. ORM с такой задачей думаю справится и напишет там какой то ALTER TABLE. Выполнение даже такого простого запроса в версионных СУБД просто заблокирует таблицу (для некоторого бизнеса может и не быть проблемой). После таких операций таблица с индексами могут разбухнуть в двое да и выполняться может не только доли секунд а часы.
На мой взгляд это должен быть пакет sql запросов выполненный через консоль, а не через какой то там ORМ и выполнен человеком который понимает, как данные запросы отрабатывает СУБД

Но выполнение миграции в одной хранимке (транзакции) вариант надежный т.к. любая проблема (exception) откатит все что выполнялось внутри.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37884391
Фотография SmeL_md
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И что тут плохого :) вы тут про безопасность поразмышляйте про целосность
Безопасность и целостность ни как не зависят от использования или не использования хранимок.
Это зависит только от прямоты рук.

Не согласен что будет с вашей базой, если просто зайти на нее с консоли.
Завтра продолжим... ;)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37884401
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторВыполнение даже такого простого запроса в версионных СУБД просто заблокирует таблицу
авторНа мой взгляд это должен быть пакет sql запросов выполненный через консоль
уровень дискуссии ниже плинтуса.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37884406
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
мое имхо. ORM нужен, ибо в прикладном коде вместо getById(продолжить по вкусу экранированием параметров, sql инъекциями etc ) руками писать запрос просто глупо, надоедает после второго раза, и все, всё равно пишут что-то свое.
ORM нужен готовый потому что свой велосипед обычно с квадратными колесами, глючит, не покрыт тестами и хорошо документирован только на языке php.
Меру использования ORM каждый выбирает сам для себя.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37884486
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ОРМ не нужен нафиг. Придуман для ламеров, чтобы подсадить на иглу.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37884524
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторприкладном коде вместо getById(продолжить по вкусу экранированием параметров, sql инъекциями etc ) руками писать запрос
???
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885001
Кто нибудь считает спорным утверждение, что с помощью ORM приложение разрабатывается быстрее?


Я склоняюсь к следующему подходу:
1) Редактирование простых сущностей в базе осуществлять через ORM
2) Тяжелые запросы, хитрые джойны и апдейты осуществлять прямыми запросами к базе или хранимками.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885014
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
еще вьюхи есть, да. и триггеры.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885103
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Начинающий ORM-щикКто нибудь считает спорным утверждение, что с помощью ORM приложение разрабатывается быстрее?...
Угу. Имеются такие.
А особенно, если учесть, что над вашей базой не только пхп разрабатывается, а ещё и всякие делфи, сишарпы и т.д. и т.п. . Короче, ясно.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885345
рубист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShSergeНачинающий ORM-щикКто нибудь считает спорным утверждение, что с помощью ORM приложение разрабатывается быстрее?...
Угу. Имеются такие.
А особенно, если учесть, что над вашей базой не только пхп разрабатывается, а ещё и всякие делфи, сишарпы и т.д. и т.п. . Короче, ясно.
По моем автор вообще php не упамянал.
При чем тут всякие делфи и сишарпы?, речь об использовании ORM в принципе.

Походу вы нормальный ORM в глаза не видели и не работали с ним в реальном проекте.
.... типа "не читал, но осуждаю" :)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885368
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
рубистShSergeпропущено...

Угу. Имеются такие.
А особенно, если учесть, что над вашей базой не только пхп разрабатывается, а ещё и всякие делфи, сишарпы и т.д. и т.п. . Короче, ясно.
По моем автор вообще php не упамянал.
При чем тут всякие делфи и сишарпы?, речь об использовании ORM в принципе.

Походу вы нормальный ORM в глаза не видели и не работали с ним в реальном проекте.
.... типа "не читал, но осуждаю" :)
Приколись, таки много видел (и использовал), но что такое "нормальный ORM" не очень понимаю. Знаю ормы и на яве, и на сишарпе. Они на порядок круче, чем в пхп. Только от своих слов я не отказываюсь. Это всё - фигня, на ламеров расчитанная. Это несмотря на то, что являюсь модератором форума, в котором буковки ОРМ написаны.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885372
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Наверное 80% запросов приложения, это простенькие селекты.
Бывают, конечно, кое какие неудобности, но плюсов то больше. Среди главных плюсов, я бы выделил два:
1. Удобность, по сравнению с нативным SQL
2. Отсутствие (ну до определенной степени) возможности допустить SQL-уязвимость.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885377
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShSergeУгу. Имеются такие.
А особенно, если учесть, что над вашей базой не только пхп разрабатывается, а ещё и всякие делфи, сишарпы и т.д. и т.п. . Короче, ясно.
Ой ну не знаю, не знаю... Коль мы находимся в этом топике, где больше обсуждается вебдев, то...
По-моему в большинстве веб-проектов грешно НЕ использовать ОРМ. Сомневаюсь, что для отдачи фронтэнда обычному пользователю нужно выполнение сложных многоуровневых запросов с кучей джойнов, вложенных запросов и оконных функций. В большинстве случаев банальщина на выборку с парочкой джойнов, которую удобнее всего инкапсулировать в ОРМе.
Алсо, использую MongoEngine, и уже давно не возникало потребности писать "сырые" запросы к БД. К тому же, есть ОРМы, которыми можно городить запросы любой сложности (например SQLAlchemy), хотя это немного бьёт по производительности, но ведь... Есть божественный кэш типа Redis'а.

Насчёт сисярпов: у сисярпа есть LINQ и прочие плюшки, которые явно ускоряют процесс разработки, избавляя от сырых запросов. Насчёт дельфей: не знаю, давно не пользовался этой порочной и мутной технологией
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885388
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Какой смысл использовать редис, если используете монгодб?
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885409
Фотография Джибс
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
я пока не очень люблю ОРМ-ы.

как тосам запросы пишу.
так хоть я знаю как я их написал. и что они из себя представляют.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885413
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
HettКакой смысл использовать редис, если используете монгодб?
Наверное, чтобы кэшировать выборки, чтобы не было лишних запросов
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885419
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
чем отличается запрос по одному ключу к монго, от запроса на получение данных из редиса?
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885422
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Джибс,

Плюсадин.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885440
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hett,

Начнём с того, что просто по ключам к монго мало запросов. Далее идёт время на парсинг запроса, обращение к дисковой памяти. В случае запроса к редису используется некоторая свёртка запроса и данные берутся из оперативной памяти из определённого пространства ключей
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885443
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не понял. А что под модгоДБ появились ормы?
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885446
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NekZВ случае запроса к редису используется некоторая свёртка запроса и данные берутся из оперативной памяти из определённого пространства ключей

Как будто монго не кэширует данные в ОЗУ и как будто я предлагаю сохранять кэш в таблицу пользователями.
Ничего не мешает создать дополнительную коллекцию и сохранять и получать из нее данные. В случае сохранения с fsync = false - запись будет ОЧЕНЬ быстрая, а получение данных по ключу, (пусть это будет MongoID) - аналогично.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885447
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShSergeНе понял. А что под модгоДБ появились ормы?
да даже для Yii есть ОРМ для монги)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885462
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hettкак будто я предлагаю сохранять кэш в таблицу пользователями
как будто я предлагаю сохранять кэш в коллекцию с пользователями
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885468
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
HettКак будто монго не кэширует данные в ОЗУ и как будто я предлагаю сохранять кэш в таблицу пользователями.
Ничего не мешает создать дополнительную коллекцию и сохранять и получать из нее данные. В случае сохранения с fsync = false - запись будет ОЧЕНЬ быстрая, а получение данных по ключу, (пусть это будет MongoID) - аналогично.
Чувак, если ты так любишь спорить то вот, результаты тестов .
Можешь дальше продолжать спорить и показывать какой ты клёвый (эвфемизм).
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885471
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NekZЧувак, если ты так любишь спорить то вот, результаты тестов .
Можешь дальше продолжать спорить и показывать какой ты клёвый (эвфемизм).
И что я должен тут увидеть?
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885475
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hett,

Nuff said
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885523
рубист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShSergeрубистпропущено...

По моем автор вообще php не упамянал.
При чем тут всякие делфи и сишарпы?, речь об использовании ORM в принципе.

Походу вы нормальный ORM в глаза не видели и не работали с ним в реальном проекте.
.... типа "не читал, но осуждаю" :)
Приколись, таки много видел (и использовал), но что такое "нормальный ORM" не очень понимаю. Знаю ормы и на яве, и на сишарпе. Они на порядок круче, чем в пхп. Только от своих слов я не отказываюсь. Это всё - фигня, на ламеров расчитанная. Это несмотря на то, что являюсь модератором форума, в котором буковки ОРМ написаны.
Опять, при чем тут php? модератор, читать умеешь?
Это не фигня расчитанная на ламеров, а один из инструментов достижения цели,
а цель - завершить проект качественно и в приемлемые сроки.
Какие инструменты использовать решается в контексте задачи.

"нормальный ORM" это например SQLAlchemy(Python), DataMapper(Ruby), ActiverRecord(Ruby), ActiveRecord(PHP)

PS Мне вобще не в лом писать голый SQL если что, благо опыта в этом лет 15,
но во всем должен быть здоровый прагматизм, а не фанатизм.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885550
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
рубист...благо опыта в этом лет 15...
На каком сервере, под какую платформу?
ПС. Я таки не отказываюсь от своих слов, что ОРМ - зло. А если база должна работать с разными клиентами, а не только с пхп, то ОРМ - вообще не при делах.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885570
Фотография SmeL_md
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кто со мной не согласится? что ORM позволяет срубить быстрей бабло с клиента и заодно увеличить требование к серверу (хостингу)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885580
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShSergeА если база должна работать с разными клиентами, а не только с пхп, то ОРМ - вообще не при делах.
Вам не кажется, что это по-прежнему огульные обвинения? И вы сильно громко заявляете о ненужности ОРМ в любых случаях. Если в вашем мире снов к одной базе цепляются с разных клиентов, в современном мире это не так часто случается
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885596
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SmeL_mdКто со мной не согласится? что ORM позволяет срубить быстрей бабло с клиента и заодно увеличить требование к серверу (хостингу)

Что есть то есть :)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885608
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Даже если к базе цепляются разные клиенты, что с того? Чем это может помешать использованию ORM на одном из них, или всех?
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37885643
рубист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShSergeрубист...благо опыта в этом лет 15...
На каком сервере, под какую платформу?
ПС. Я таки не отказываюсь от своих слов, что ОРМ - зло. А если база должна работать с разными клиентами, а не только с пхп, то ОРМ - вообще не при делах.
Вообще это офтоп, но раз хотите, извольте ....
FoxPro(начиная с dos версий, настольные системы), Sybase ASA(win, распределенка с оффлайн репликациями), MSSQL(win,настольные системы), MySQL(nix-ы,для web), PostgreSQL(nix-ы,для web)
это только то, с чем работал продолжительное время.

По моему это пустой разговор, не нравится, не используйте. Кто заставляет? :)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886199
дико извиняюсь! НО! любителям ОРМ не кажется, что, с вашей стороны, идёт некая подмена понятий?

ORM - http://ru.wikipedia.org/wiki/ORM
Model - http://ru.wikipedia.org/wiki/Model-View-Controller

это не одно и то же, как не крути...

P.S.
1. причём тут MongoDB, которая по определению не нуждается в ОРМ т.к. является "документо-ориентированной", и сохраняет в себя объекты напрямую???
2. зачем, в приложении, использовать ОРМ, если сервер БД находится отдельно (физически), как это и должно быть! от приложения и общение происходит посредством сервиса, котрый собственно уже выдаёт данные, структурированные опр. образом??? - И мне, как вэб-разрабу, фиолетово, как там организован к ним доступ, людьми, которые за это отвечают!
3. зачем мне в приложении "виртуальная объектная база данных" , если я могу\умею работать с реальной РСУБД напрямую?
4. ну и так далее!

...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886299
рубист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторкто-то из толпы,

2. зачем, в приложении, использовать ОРМ, если сервер БД находится отдельно (физически), как это и должно быть! от приложения и общение происходит посредством сервиса, котрый собственно уже выдаёт данные, структурированные опр. образом??? - И мне, как вэб-разрабу, фиолетово, как там организован к ним доступ, людьми, которые за это отвечают!
3. зачем мне в приложении "виртуальная объектная база данных", если я могу\умею работать с реальной РСУБД напрямую?
4. ну и так далее!
По моему вы совсем не понимаете, что такое ORM.
Никакой "виртуальной обьектной базы данных" ORM не создает, это глупость.
Не нужно путать ORM с обьектно орентированными БД, это не тоже самое.

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

Модели в MVC и есть ORM или некое подобие ORM-a (зависит от реализации).
т.е. это классы ООП, описывающие обьекты реального мира (пользователи, статьи, заказы, товары и т.п.)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886300
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot кто-то из толпы]

1. причём тут MongoDB, которая по определению не нуждается в ОРМ т.к. является "документо-ориентированной", и сохраняет в себя объекты напрямую???

То есть, вы хотите сказать, что вот эти ребята трудились впустую?
Алсо, его интерфейс такой же как и у ОРМ Django. Дабы придерживаться единого интерфейса описания моделей и взаимодействия с ними. Ещё один важный факт - MongoEngine ведёт себя как ОРМ реляционной БД, сам реализуя отношения между таблицами коллекциями. Я не буду сейчас распинаться и объяснять почему был выбран именно MongoDB, а не какой-нибудь там MySQL или Pg :)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886354
Наличие в отдельной части приложения конструкции
User->save()
не придаёт автоматом вызываемой части статус ORM!!!
авторТо есть, вы хотите сказать, что вот эти ребята трудились впустую?
нет! я хочу сказать, что эти ребята не зря потратили время! ;)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886373
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кто-то из толпы,

Я не понимаю... Либо чувак не в теме, либо это такой качественный троллинг :)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886415
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NekZкто-то из толпы,

Я не понимаю... Либо чувак не в теме, либо это такой качественный троллинг :)
Я знаю этого чувака. Он в теме, поверь. А вот тема "ORM vs голый SQL " - самый холивар с провокацией на троллинг.
Этот баян уже тыщу раз обсуждался. Лично я высказался за "голый SQL". Потому что вижу, как влюблённые в ОРМ люди через некоторое время таки спрыгивают на простой SQL.
ПС. А монгоДБ здесь точно не при делах. Потому что это - не SQL, а документоориентированная БД, которая уже хранит объекты. Поэтому в отдельной ОРМ не нуждается.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886465
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShSergeПС. А монгоДБ здесь точно не при делах. Потому что это - не SQL, а документоориентированная БД, которая уже хранит объекты. Поэтому в отдельной ОРМ не нуждается.
Как бы... Это не мешает использовать её как РСУБД. и ОРМ не обязан инкапсулировать в себе SQL-вызовы.

Я не знаю, что это были у вас за люди, но мне после полу года использования ОРМов использование прямого SQL уже кажется каменным веком. Опять же, я не говорю, что ОРМ - это панацея. Например разные статистические сложные запросы проще всё же сделать на SQL. Однако, как я уже говорил, это единичные случаи и в данном разделе (вебдев), они применяются очень редко.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886526
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: php
1.
Это не мешает использовать её как РСУБД


Джоин сделать например?
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886541
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
HettДжоин сделать например?
Да. В принципе, бОльшего и не надо для веб-приложения
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886591
Фотография SmeL_md
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NekZПотому что вижу, как влюблённые в ОРМ люди через некоторое время таки спрыгивают на простой SQL. NekZЯ не знаю, что это были у вас за люди, но мне после полу года использования ОРМов использование прямого SQL уже кажется каменным веком. На мой взгляд ключевые слова подчеркнул
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886595
Фотография SmeL_md
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Опечатался в авторах исправляю :(
ShSerge Потому что вижу, как влюблённые в ОРМ люди через некоторое время таки спрыгивают на простой SQL. NekZЯ не знаю, что это были у вас за люди, но мне после полу года использования ОРМов использование прямого SQL уже кажется каменным веком. На мой взгляд ключевые слова подчеркнул
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886597
NekZ
авторОРМ не обязан инкапсулировать в себе SQL-вызовы
чувак! ОРМ - сотавная часть того или иного FW или набора библ, облегчающих несообразительному разрабу жизнь при работе его ОО приложения с РБД, и тянущих за собой шлейф подводных камней, а никак не самостоятельное произведение искуств!

Контрольный выстрел!!!
Код: php
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
<?php
$arr = array('a' => 1, 'b' => 2, 'c' => 3, 'd' => 4, 'e' => 5);

echo json_encode($arr);
?>
<?php
$json = '{"a":1,"b":2,"c":3,"d":4,"e":5}';

var_dump(json_decode($json));
var_dump(json_decode($json, true));

?>


зы: OJM - object json mapper!!!

авторЭто не мешает использовать её как РСУБД
жесть!!!

ТС - если нету сил\возможности самостоятельно составить запросы в БД напрямую - используй FrameWork с ORM\ODM\OJM\HZzachem, если хватает сил и знаний не парься и пиши прямые запросы!
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886604
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NekZHettДжоин сделать например?
Да. В принципе, бОльшего и не надо для веб-приложения
Для сайта-визитки, но не для сайта подачи деклараций, или бухгалтерской отчётности.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886605
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторОРМ - сотавная часть того или иного FW или набора библ, облегчающих несообразительному разрабу жизнь при работе его ОО приложения с РБД
Да не обязательно с Р БД
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886618
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SmeL_mdНа мой взгляд ключевые слова подчеркнул
На мой взгляд, сударь, вы просто сами не в теме, либо у вас не было достаточно практики работы с ОРМ, либо не те ОРМы использовали. Я уже сказал, ОРМ - не панацея. И если понадобится сложный запрос - напишу на SQL. Если у меня куча простых запросов - использую ОРМ.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886629
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: php
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
<?php
$arr = array('a' => 1, 'b' => 2, 'c' => 3, 'd' => 4, 'e' => 5);

echo json_encode($arr);
?>
<?php
$json = '{"a":1,"b":2,"c":3,"d":4,"e":5}';

var_dump(json_decode($json));
var_dump(json_decode($json, true));

?>


Скажите, что тут нужно увидеть?
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886632
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кто-то из толпычувак! ОРМ - сотавная часть того или иного FW или набора библ, облегчающих несообразительному разрабу жизнь при работе его ОО приложения с РБД, и тянущих за собой шлейф подводных камней, а никак не самостоятельное произведение искуств!

Контрольный выстрел!!!
Код: php
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
<?php
$arr = array('a' => 1, 'b' => 2, 'c' => 3, 'd' => 4, 'e' => 5);

echo json_encode($arr);
?>
<?php
$json = '{"a":1,"b":2,"c":3,"d":4,"e":5}';

var_dump(json_decode($json));
var_dump(json_decode($json, true));

?>


зы: OJM - object json mapper!!!

авторЭто не мешает использовать её как РСУБД
жесть!!!

ТС - если нету сил\возможности самостоятельно составить запросы в БД напрямую - используй FrameWork с ORM\ODM\OJM\HZzachem, если хватает сил и знаний не парься и пиши прямые запросы!
Ну это похвально, что вы старой закалки, только сейчас этим потенциального заказчика не обрадуешь.
Упс... Промах. Я не знаю PHP и никогда его не использовал в практических целях.

Приведите пример подводных камней кроме нормализации БД и дополнительных зависимостей?
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886638
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShSergeДля сайта-визитки, но не для сайта подачи деклараций, или бухгалтерской отчётности.
Ну да :) Каких сайтов в интернете больше?
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886650
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И совсем уж оффтоп по поводу сложных запросов, которые сказываются на производительности - можно заполнять дополнительные промежуточные коллекции периодически каким-нибудь скриптом, запускаемым через cron, а ОРМом лишь вытаскивать оттуда готовенькие данные не сильно нагружая сервер во время этого
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886652
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NekZShSergeДля сайта-визитки, но не для сайта подачи деклараций, или бухгалтерской отчётности.
Ну да :) Каких сайтов в интернете больше?
Фиг его знает. Наверное, таки визиток. Но обобщать, наверное, не нужно.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886692
авторНу это похвально, что вы старой закалки, только сейчас этим потенциального заказчика не обрадуешь .
заказчики бывают разные - некоторые платят за знания! ;)
авторУпс... Промах. Я не знаю PHP и никогда его не использовал в практических целях.
пример из жизни! ;)
автордля того что бы составить мнение о той или иной книге (RDB) мне не нужен человек, который мне её прочтёт\перескажет (ORM\ODM) - я сам в состоянии её прочесть (SQL)!!!
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886706
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кто-то из толпы,

Вы похоже тоже живёте в своём уютном мирке.

P. S. Выходит, OJM можно реализовать в любом языке, поддерживающем такие структуры данных, как списки и словари. Ну ещё парсилка/дампилка JSON'а. Няяя! ^^ Зачем тогда монги и прочая фигня) Давайте налабаем свой FVMas
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886707
ShSergeNekZкто-то из толпы,

Я не понимаю... Либо чувак не в теме, либо это такой качественный троллинг :)
Я знаю этого чувака. Он в теме, поверь. А вот тема "ORM vs голый SQL " - самый холивар с провокацией на троллинг.
Этот баян уже тыщу раз обсуждался. Лично я высказался за "голый SQL". Потому что вижу, как влюблённые в ОРМ люди через некоторое время таки спрыгивают на простой SQL.
ПС. А монгоДБ здесь точно не при делах. Потому что это - не SQL, а документоориентированная БД, которая уже хранит объекты. Поэтому в отдельной ОРМ не нуждается.


Нет, это не троллинг.

Есть старый,старый сайт со старой базой. Объем php кода порядка 50 000 строк. Встал вопрос перепроектирования базы с нуля и переход на новые технологии. И вот я мучаюсь вопросом, подключать ли ORM.
В качестве фреймверка была выбрана вторая симфония.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886713
рубист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кто-то из толпы,
авторОРМ - сотавная часть того или иного FW или набора библ, облегчающих несообразительному разрабу жизнь при работе его ОО приложения с РБД, и тянущих за собой шлейф подводных камней, а никак не самостоятельное произведение искуств!
Подводные камни есть везде, не только в ORM, что, теперь вообще ни чем не пользоватся? :)
Раскажите на java форуме, что hibernate используют не сообразительные девелоперы, вас засмеют.

авторесли нету сил\возможности самостоятельно составить запросы в БД напрямую - используй FrameWork с ORM\ODM\OJM\HZzachem, если хватает сил и знаний не парься и пиши прямые запросы!
Выборка данных или их сохранение в БД это процентов 20% функций, которые в проекте выполняет ORM.
Если у вас нет сил\возможности самостоятельно освоить остольные 80% и вы любите велосипеды, не парьтесь, пишите только прямые запросы. :)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886736
Фотография SmeL_md
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Начинающий ORM-щикЕсть старый,старый сайт со старой базой. Объем php кода порядка 50 000 строк. Встал вопрос перепроектирования базы с нуля и переход на новые технологии. И вот я мучаюсь вопросом, подключать ли ORM.
В качестве фреймверка была выбрана вторая симфония.Симфони интересная штука многое делает за тебя и ORM doctrine там есть, когда я начал с ней работать, я понял что нужно купить новый ПК а старый отдать родителям :) Без ORM я бы пользовался старым ПК, так что нельзя хаять ORM.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886765
Фотография SmeL_md
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хочу отметить я не отговариваю от Symfony, она мне помогла реализовать пару проектов, которыми пользуется фирма где я работаю. Я использовал 1.4.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886798
http://mongoengine.org/ - Object-document mapper - ODM!!!
http://ru.wikipedia.org/wiki/ORM - Object-relational mapping - ORM!!!
авторВыходит, OJM можно реализовать в любом языке, поддерживающем такие структуры данных, как списки и словари. Ну ещё парсилка/дампилка JSON'а.
OJM можно реализовать в любом языке, где есть объекты нуждающиеся в преобразовании Object -> JSON -> Object
т.к. джейсон строка прекрасно сохраняется практически в любом хранилище и с лёгкостью преобразуется обратно в объект без лишних телодвижений, если при этом в качестве серверного яп использовать js - это вообще станет банальщиной!
Можно на основе OJM написать свою либу (fw) которая облегчит нам жизнь и будет ещё сохранять\выбирать данные, валидировать их и тд
авторИ вот я мучаюсь вопросом, подключать ли ORM.
В качестве фреймверка была выбрана вторая симфония.
ну если за тебя выбор уже сделали, что же тут думать? ;)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886819
рубист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кто-то из толпы,
авторНаличие в отдельной части приложения конструкции
User->save()
не придаёт автоматом вызываемой части статус ORM!!!
http://ru.wikipedia.org/wiki/Утиная_типизация
цитата "Если что-то выглядит как утка, плавает как утка и крякает как утка, то, вероятно, это утка"
и еще цитата "То есть считается, что объект реализует интерфейс, если он содержит все методы этого интерфейса, независимо от связей в иерархии наследования и принадлежности к какому-либо конкретному классу."
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886843
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кто-то из толпы http://mongoengine.org/ - Object-document mapper - ODM!!!
http://ru.wikipedia.org/wiki/ORM - Object-relational mapping - ORM!!!
авторВыходит, OJM можно реализовать в любом языке, поддерживающем такие структуры данных, как списки и словари. Ну ещё парсилка/дампилка JSON'а.
OJM можно реализовать в любом языке, где есть объекты нуждающиеся в преобразовании Object -> JSON -> Object
т.к. джейсон строка прекрасно сохраняется практически в любом хранилище и с лёгкостью преобразуется обратно в объект без лишних телодвижений, если при этом в качестве серверного яп использовать js - это вообще станет банальщиной!
Можно на основе OJM написать свою либу (fw) которая облегчит нам жизнь и будет ещё сохранять\выбирать данные, валидировать их и тд

Слова... Всего лишь название. Главная суть вот в этом "It uses a simple declarative API, similar to the Django ORM."
>Можно на основе OJM написать свою либу (fw) которая облегчит нам жизнь и будет ещё сохранять\выбирать данные, валидировать их и тд
Дедал, ну залогинься уже!
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886876
авторЕсли что-то выглядит как утка, плавает как утка и крякает как утка, то, вероятно, это утка
Код: php
1.
2.
$mongo = new Mongo();
$mongo->archive->audio->save($audio);


гыгы - это тоже ОРМ? ;)
авторСлова... Всего лишь название. Главная суть вот в этом...
да перестань ты!
видеть больше, чем сказано - удел паталогии (С)

Удачи! С вами становиться скучно...
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886885
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кто-то из толпы,

Нену чувак, мне не важно что у него там под капотом, я просто знаю, что у него такой же интерфейс как и у Джанговского ОРМа. Остальное мне пофиг. В этом и есть один из основных принципов программирования - абстракция
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886923
авторНену чувак, мне не важно что у него там под капотом
вероятнее всего, ты не программист, а, возможно - пианист, подрабатывающий созданием хоме-паг для непривередливых заказчиков! ;)
P.S. извини, если угадал! ;)))
ББ!!!
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886953
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NekZ...В этом и есть один из основных принципов программирования - абстракция
Чтобы уметь гладить вовсе не обязательно знать, как устроен утюг. Это должны знать соответствующие специалисты.
Так вот, здесь нередко эти самые специалисты и собираются, обсуждая устройство утюгов.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37886989
рубист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кто-то из толпы
Код: php
1.
2.
$mongo = new Mongo();
$mongo->archive->audio->save($audio);


гыгы - это тоже ОРМ? ;)

Это не ORM.
Вы совершенно плаваете в понятиях. :)

Здесь у нас присутствует соотношение "БД хронящая Обьекты "->"Обьекты языка программирования" ,
а ORM это "БД хронящая реляционные данные "->"Обьекты языка программирования".
Чувствуете разницу?

Это скорее можно назвать OOM(Object to Object Mapping)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887089
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShSergeNekZ...В этом и есть один из основных принципов программирования - абстракция
Чтобы уметь гладить вовсе не обязательно знать, как устроен утюг. Это должны знать соответствующие специалисты.
Так вот, здесь нередко эти самые специалисты и собираются, обсуждая устройство утюгов.

Тогда наверное можно сказать, что нативный SQL - подошва от утуюга, в принципе и гладить можно, но геморроя много и больше вероятности обжечься.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887389
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кто-то из толпы,

Оу, ну прям в точку ты меня уязвил Что ж ты на похапе-то пишешь, а не Си и Асме?
У меня как бы более важные задачи, нежели копание в исходниках ОРМа. Когда я хочу посмотреть как и что там работает - лезу в исходники, но это редкость, так как, все основные плюшки документированы. В общем, сударь, думаю, мы поняли друг друга :)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887392
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShSergeNekZ...В этом и есть один из основных принципов программирования - абстракция
Чтобы уметь гладить вовсе не обязательно знать, как устроен утюг. Это должны знать соответствующие специалисты.
Так вот, здесь нередко эти самые специалисты и собираются, обсуждая устройство утюгов.
Ой да ладно бородой трясти. Сейчас мы обсуждаем нужность использования ОРМов, а не то как они сделаны :)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887401
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
HettТогда наверное можно сказать, что нативный SQL - подошва от утуюга, в принципе и гладить можно, но геморроя много и больше вероятности обжечься.
Нет, это голая спираль, за которую надо держаться голыми руками и гладить - оверхеда меньше, ожогов больше
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887405
авторСейчас мы обсуждаем нужность использования ОРМов, а не то как они сделаны :)
да не нужны они вовсе - тк уже существуют более подходящие решения !!!
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887423
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кто-то из толпы,

FVMas?
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887450
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кто-то из толпыавторСейчас мы обсуждаем нужность использования ОРМов, а не то как они сделаны :)
да не нужны они вовсе - тк уже существуют более подходящие решения !!!
это какие?
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887548
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NekZ...Ой да ладно бородой трясти. Сейчас мы обсуждаем нужность использования ОРМов, а не то как они сделаны :)
Во-первых, у меня нету бороды, а во-вторых, ОРМы усложняют дело и подсаживают на иглу.
Короче, проект проще сделать на "голом SQL", а не на орме. Это раз.
А два - если над базой ещё висят пара-тройка десктопных приложений, написанных хоть на сях, хоть на делфях, то свои ормы можно засунуть ... . По простой причине, что твоё приложение, по сравнению с ценностью базы - г-но, которому цена три копейки.
Всё понятно?
Хотя, если это сайт-визитка, то не понятно нафига здесь серверная часть, если можно сделать всё на чистом хтмл.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887551
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShSerge,

По-моему у вас какие-то максималистичные понятия об этом. Только чёрное и белое - сайты визитки и сайты с бухгалтерской отчётностью. Знаете, а есть ещё и гостевухи :)) Скажите, а сайт free-lance.ru вы к какому отнесёте?
21-ый век на дворе и пора уже задуматься об удобстве разработки. К тому же, мы сейчас в вебдеве (!!!) и десктопные приложения не обсуждаем (и потом, что мешает использовать веб-интерфейс для работы с БД?). К тому же, десктопные приложения, ориентированные на работу с БД скорее всего не для всех пользователей Интернета, а лишь для корпоративных сетей (не так ли? автоматизированная система учёта компьютерного оборудования, сделанная студентом второкурсником на дельфях и акцессе. победа чо!). Я уже сказал, что говорю за большинство, а не за узкоспециализировнную область
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887563
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Только когда начинаешь лабать - охота завернуть SQL-вызовы во что-то более абстрактное... Так дорастаем до DAO
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887629
рубист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShSergeОРМы усложняют дело и подсаживают на иглу.

По моему только упрощают. Это особенно ощутимо на стадии сопровождения.

ShSergeКороче, проект проще сделать на "голом SQL", а не на орме. Это раз.

Спорное утверждение. При отсутствии опыта согласен, проще на "голом SQL".
Я меня создалось впечатление, что у вас нет достаточного опыта в использовани ORM и вы об этом судите поверхностно.
ORM ценен не сам по себе, он ценен тем, что стандартизует интерфейсы доступа к данным на уровне приложения,
заставляя разработчика следовать определенным шаблонам проектирование. Это в свою очередь дает больше возможностей
в автоматизация процесса разработки и тестирования, повторном использование кода, использовании классов и модулей от других разработчиков и т.д.
Но эфективное использование ORM подразумевает в то числе и хорошее знание SQL, иначе это будет управление атомным реактором без знания ядерной физики.

ShSergeА два - если над базой ещё висят пара-тройка десктопных приложений, написанных хоть на сях, хоть на делфях, то свои ормы можно засунуть ... . По простой причине, что твоё приложение, по сравнению с ценностью базы - г-но, которому цена три копейки.
Всё понятно?
С чего вы взяли, что использование ORM само по себе может как-то повредить БД? Если руки кривые, то БД повредится и без него.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887667
Фотография SmeL_md
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
рубистС чего вы взяли, что использование ORM само по себе может как-то повредить БД? Если руки кривые, то БД повредится и без него.как бы Вам сказать не совсем навредить а подкинуть "мусорка". СУБД кэширует подогревает данные и если она выполняет в большинстве своем не оптимальные запросы ей придется высвобождать данные из рам и записывать на винт.
ORM ничего хорошего конечному пользователю продукта не дает.
ORM-щикам интересно знакомо такое понятие как тюнить запросы.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887672
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
рубист...При отсутствии опыта согласен, проще на "голом SQL"... .
Феноменальное утверждение!
Короче, до свидания. Надеюсь, лет через пять.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887673
авторORM ценен не сам по себе, он ценен тем, что стандартизует интерфейсы доступа к данным на уровне приложения
стандартизация интерфейсов доступа к данным на уровне приложения происходит за счёт хорошо спроектированной МОДЕЛИ!!!
ОРМ тут вообще ни причём!!! Тот же контроллер получает данные от представления и отдаёт их модели через её методы, либо получает данные из модели и отдаёт их в представление (если угодно) - модель в свою очередь проверяет эти данные строит зависимости (манипулирует ими) и отдаёт в БД (либо маппит в случае с ОРМ->РБД, либо напрямую в случае той же Mongo)!!!
автор21-ый век на дворе и пора уже задуматься об удобстве разработки.
NoSQL
авторЯ уже сказал, что говорю за большинство, а не за узкоспециализировнную область
тынц
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887753
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А ты сначала ответьте на это 12894662
кто-то из толпыNoSQL

Не в тему сказано
кто-то из толпы тынц
Луркофакер детектед

У меня есть мнение, что вы использовали какие-то ущербные ОРМы и поэтому вот сейчас судите так обо всех и стараетесь изобретать велосипеды, называя их FW (Оу щи, FVMas же). Ну понятно, на PHP других быть и не может :) А может, вам просто лень читать TFM. Проще всё-таки так написать
Код: php
1.
2.
3.
4.
$res = mysql_query("SELECT id, name, money FROM users ORDER BY id");
while ($row = mysql_fetch_array($res)) {
//Трали-вали, выводим на страницу через echo
}



Нежели описать модель один раз и обращаться к ней в коде
Код: python
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
class User(Model):
    name = StringField(default="Вася Пупкин")
    money = IntegetField(default=0)

    @property
    def first_name(self):
        return self.name.split(' ')[0]
#...

users = User.objects.order_by('id')

#передаём в шаблон
return render_to_response('my_super_template.html', { 'users': users })


Текст шаблона
Код: html
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
<html>
<body>
<div class="user_list>
{% for user in users %}
<span class="user_first_name">{{ user.first_name }}</span>
<span class="user_money">{{ user.money }}</span>
{% endfor %}
</div>
</body>
</html>


Пример написан на коленке и сферический в вакууме.
Удачи с сопровождением кода и рефакторингом

З. Ы. А вот похапе точно подсаживает на иглу, слезть с которой уже нельзя это точно. Слава Б-гу что я до него другие языки изучал, иначе бы сейчас спорил с рубистом по поводу ненужности ОРМов
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887784
авторНежели описать модель один раз и обращаться к ней в коде
Ааааааааааа................
MVC
Model
Код: php
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
namespace models\mongo;

class administration {

    private
    $_connection,
    $_db,
    $_users,
    $_roles;

    public function __construct() {

        $this->_connection = new \Mongo();
        $this->_db = $this->_connection->selectDB('administration');
        $this->_users = $this->_db->selectCollection('users');
        $this->_roles = $this->_db->selectCollection('roles');
        
        $this->_users->ensureIndex(
                array('name' => 1),
                array('unique' => true, 'background' => true)
        );    
        $this->_roles->ensureIndex(
                array('name' => 1),
                array('unique' => true, 'background' => true)
        );
    }

    public function getRoles($sort) {
        return iterator_to_array(
                        $this->_roles->find()->sort($sort), FALSE
        );
    }

    public function getUsers($sort) {
        return iterator_to_array(
                        $this->_users->find()->sort($sort), FALSE
        );
    }
}


Controller
Код: php
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
namespace controllers;

class administration {

    private
    $_administrationModel;

    public function __construct() {
        $this->_administrationModel = new \models\mongo\administration ();        
    }

    public function index_get() {        
        return array(
            'users' => $this->_administrationModel->getUsers(array('name' => 1)),
            'roles' => $this->_administrationModel->getRoles(array('name' => 1))
        );
    }
}


view
ну и шаблон!!!

заметь, в модели я волен делать что пожелаю с методами getRoles(), getUsers()!!! Это Важно!!!
могу написать прямой запрос в РБД, могу навернуть ОРМ и замапить полученные значения из РБД на объекты, могу не париться и передать так как есть!!!

Код: php
1.
2.
3.
4.
users = User.objects.order_by('id')

#передаём в шаблон
return render_to_response('my_super_template.html', { 'users': users })


гыгы!!!
и чё буш делать при смене хранилища данных - искать новый FW который обеспечит поддержку конструкции
users = User.objects.order_by('id')

12890589 - с самого начала говорил, что вы плохо втыкаете в разницу между ORM vs MODEL!!!
Теперь в этом убедился окончательно!!!
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887785
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автормогу написать прямой запрос в РБД
И давно монго стала реляционной?
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887786
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кто-то из толпы,

Дедал, ну залогинься уже, мне трудно общаться с тобой, когда ты не залогинен.

Я описал MTV, это не совсем MVC ;-) Кстати, на пыхе это по-прежнему смотрится страшно, что охота вырвать на себе все волосы. Столько много лишнего кода...
>ORM vs MODEL!!!
RTFM MAZAFAKA
А я ведь говорил, что похапе влияет на моск... И лишний раз в этом убеждаюсь
>и чё буш делать при смене хранилища данных - искать новый FW который обеспечит поддержку конструкции.
Нет, дорогуша, у джанги под разные хранилища единый интерфейс. Как и у SQLAlchemy. Видимо, у похапе с этим делом совсем всё плохо, коль вы на каждый чих ищете "FW"... Мне вас жаль.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887796
рубист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кто-то из толпыв модели я волен делать что пожелаю с методами getRoles(), getUsers()!!! Это Важно!!!
могу написать прямой запрос в РБД, могу навернуть ОРМ и замапить полученные значения из РБД на объекты, могу не париться и передать так как есть!!!

т.е. модели в каком-то виде все же нужно использовать, а не просто голый SQL и массивы\хеши? речь то у нас об этом :)
PS Не знаю что это за фреймворк, с php не работал уже тыщу лет.

кто-то из толпыи чё буш делать при смене хранилища данных - искать новый FW который обеспечит поддержку конструкции
users = User.objects.order_by('id')

Вы удивитесь, но ORM может быть подключен в том числе и к NoSQL, почти без изменения кода.
https://github.com/solnic/dm-mongo-adapter
https://github.com/jimm/activerecord-mongo-adapter
При условии, что в проекте ни где нет "голого SQL и бизнес логики в хранимках", иначе придется рефакторить.
PS Это ж как надо планировать проект, чтобы после всех работ инициировать переход с SQL на NoSQL! :)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887830
авторНет, дорогуша, у джанги под разные хранилища единый интерфейс.
дорогой мой лемминг - больше можешь не продолжать вовсе - бо то о чём ты говоришь я уже успел позабыть (ASP.NET MVC LinqToSQL EntityFramework and etc.) - всё очень единое и универсальное! ;)
ПРОФЕССИОНАЛЬНЫХ УНИВЕРСАЛЬНЫХ ВЕЩЕЙ НЕБЫВАЕТ В ПРИРОДЕ ПО ОПРЕДЕЛЕНИЮ!!!
авторВы удивитесь, но ORM может быть подключен в том числе и к NoSQL, почти без изменения кода.
NoSQL НЕ НУЖЕН DATAMAPER!!! ИМ НЕНУЖНЫ ПРИБЛУДЫ КОТОРЫЕ МАПЯТ ОБЪЕКТ НА ОБЪЕКТ!!! ТЕМ БОЛЕЕ ИМ НЕНУЖНЫ ORM тк ORM МАПЯТ ОБЪЕКТ НА ТАБЛИЦЫ РБД И ОБРАТНО!!!
Hett
авторИ давно монго стала реляционной?

Model
Код: php
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
public function getAllUsers()
    {
        $query = 'SELECT
            id,
            name,
            name_full,
            guid,
            password,
            strftime(:format, created, \'localtime\') AS created,
            strftime(:format, visited, \'localtime\') AS visited,
            visited_ip,
            active
            FROM users
            ORDER BY name ASC;';

        $this->stmt = $this->conn->prepare( $query );
        $this->stmt->execute( array( $this->_format ) );

        return $this->stmt->fetchAll( \PDO::FETCH_ASSOC );
    }


OFFавторPS Это ж как надо планировать проект, чтобы после всех работ инициировать переход с SQL на NoSQL! :)

падстолом!!!
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887835
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887836
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кто-то из толпы,

>ASP.NET MVC LinqToSQL EntityFramework and etc.
Я эти дьявольские технологии не использовал и даже не видел, но по вам видно, что вы оттуда ;-)

К тому же, вам не кажется что вы отрекаетесь от универсальности в ущерб удобству и скорости разработки, там где она вообще редко бывает нужна? Нену, крутится сайт на мускуле - так и пускай крутится... Или мсье предпочитает менять хранилища данных как перчатки, да ещё используя разные интерфейсы для них? :)
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887838
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кто-то из толпы,

Дабл фэйспалм
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887853
авторК тому же, вам не кажется что вы отрекаетесь от универсальности в ущерб удобству и скорости разработки
Model
1.
Код: php
1.
2.
3.
4.
5.
public function getRoles($sort) {
        return iterator_to_array(
                        $this->_roles->find()->sort($sort), FALSE
        );
    }


2.
Код: php
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
public function getRoles($sort) {
        $query = 'SELECT
            id,
            name,
            name_full,
            guid,
            password,
            strftime(:format, created, \'localtime\') AS created,
            strftime(:format, visited, \'localtime\') AS visited,
            visited_ip,
            active
            FROM users
            ORDER BY name ASC;';

        $this->stmt = $this->conn->prepare( $query );
        $this->stmt->execute( array( $this->_format ) );

        return $this->stmt->fetchAll( \PDO::FETCH_ASSOC );
    }


3.
Код: php
1.
2.
3.
public function getRoles($sort) {
        return какая-нибудь фигня из какого-нибудь датаадаптера\маппера (ORM\ODM\OJM)
    }


в чем конкретно данная модель не универсальна?!
почему вызовы данной модели в контроллере должны зависеть от какого-то jango или ещё кого-то (мало мне знакомого)?
Почему написание прямого SQL запроса (в случае с RBD - п.2) у меня должно вызвать какие-то затруднения?

Ещё раз повторю - ты ошибаешься, когда сравниваешь модель приложения и её составную часть (к примеру ORM)

авторЯ эти дьявольские технологии не использовал и даже не видел, но по вам видно, что вы оттуда ;-)
попробуй! тебе точно понравится!!! ;)

Успехов!!!
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887866
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кто-то из толпы,

>в чем конкретно данная модель не универсальна?!
>УНИВЕРСАЛЬНЫХ ВЕЩЕЙ НЕБЫВАЕТ В ПРИРОДЕ ПО ОПРЕДЕЛЕНИЮ!!!
Да даже текстом запроса. У всех субд есть функция strftime и все они поддерживают синтаксис передачи параметров через двоеточие?
Для монги её пришлось бы переписать в совсем другое.
Эта модель привязана железно к мускулю и его синтаксису и нет той красоты и удобства
>попробуй! тебе точно понравится!!! ;)
Это врядли. Я на светлой стороне :)
>когда сравниваешь модель приложения и её составную часть (к примеру ORM)
Что это за наркоманство? Т упрлс? я не сравнивал модель. Я вообще про всякие MVC и слова не обронил, это вы уже там себе что-то надумали. Я говорил о модели как о сущности БД.
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887936
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NekZ...Я на светлой стороне :)...
Самое главное не перепутать светлое с тёмным.
Классики говорят, что в тёмную комнату можно принести свечку, и станет светло. А вот в светлую комнату, чтобы стало темно, чего надо принести?
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887949
авторДля монги её пришлось бы переписать в совсем другое.
да понял я уже
- самое трудное в программировании конкретно для тебя! - ПИСАТЬ КОД (со всеми вытекающими)!!!
...
Рейтинг: 0 / 0
ORM vs голый SQL
    #37887975
Фотография NekZ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ShSergeСамое главное не перепутать светлое с тёмным.
Классики говорят, что в тёмную комнату можно принести свечку, и станет светло. А вот в светлую комнату, чтобы стало темно, чего надо принести?
Я думаю, достаточно будет зашторить источники света. :)

кто-то из толпыавторДля монги её пришлось бы переписать в совсем другое.
да понял я уже
- самое трудное в программировании конкретно для тебя! - ПИСАТЬ КОД (со всеми вытекающими)!!!
Да, это самое ужасное что может быть. Хлебом меня не корми лишь дай не писать код А зачем тогда вообще фреймворки использовать если не ради сокращения объёма кода и упрощения сопровождения?
...
Рейтинг: 0 / 0
110 сообщений из 110, показаны все 5 страниц
Форумы / PHP, Perl, Python [игнор отключен] [закрыт для гостей] / ORM vs голый SQL
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]