Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / PHP, Perl, Python Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
 ORM vs голый SQL  [new]
Начинающий ORM-щик
Guest
Возможна данная тема уже обсуждалась.
Какие есть плюсы и минусы использования ORM на проекте?

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


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

Каково Ваше мнение?
18 июл 12, 14:00    [12883262]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 16827
http://symfony.com/symfony-explained-to-a-developer
18 июл 12, 14:15    [12883323]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
Начинающий ORM-щик
Guest
ScareCrow
http://symfony.com/symfony-explained-to-a-developer



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

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

Насколько мирно это всё будет существовать с ORM?
18 июл 12, 14:41    [12883550]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
рубист
Member

Откуда: с кудыкиных гор
Сообщений: 98
ORM как раз и предназначен для инкапсуляции бизнес логики, но не на уровне СУБД, а на уровне приложения.

Использовать хранимки не советую, только если очень прижмет.
Причина в том, что вам понадобится еще один разработчик для хранимок.
Если текущий специалист может это делать и сам, то найти такого в случае его ухода будет сложнее,
а значт все равно понадобится еще спец по БД.
Есть еще ряд минусов использования хранимок ....
- сложность тестирования бизнес логики
- понадобится решать, каким образом будет обеспечиватся контроль версий (svn/git)
- каким образом будет происходить развертывание хранимок на продакшн.
- как делать откат версий в случае неудачного развертывания. ...
- в конце концов, что делать если нужно перейти на SQL сервер другого вендера.
короче гемор.
18 июл 12, 15:10    [12883809]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
SmeL_md
Member

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

Как то все натянуто за уши. Нужна скорость пишите хранимки. И все эти минусы из пальца высосаны.
И про ORM тоже самое, нужна скорость отказываемся и от него.
18 июл 12, 15:30    [12883960]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
Начинающий ORM-щик
Guest
рубист
ORM как раз и предназначен для инкапсуляции бизнес логики, но не на уровне СУБД, а на уровне приложения.

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


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

А по скорости разработки что может быть быстрее? ORM или php + голый sql?
18 июл 12, 15:32    [12883976]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
SmeL_md
Member

Откуда:
Сообщений: 1065
Начинающий ORM-щик
А по скорости разработки что может быть быстрее? ORM или php + голый sql?

Скорость разработки выше с ORM чем с простым sql, а производительность наоборот
18 июл 12, 15:38    [12884016]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 16827
автор
Скорость разработки выше с ORM чем с простым sql, а производительность наоборот

а потом имеем сотую реализацию getById()
18 июл 12, 16:31    [12884392]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
miksoft
Member

Откуда:
Сообщений: 38444
Начинающий ORM-щик
Большую часть бизнес логики хочется реализовать с помощью внутренних средств СУБД.
FK, хранимые процедуры, на крайний случай тригера.
Что за СУБД, если не секрет?
18 июл 12, 16:33    [12884404]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
рубист
Member

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

Как то все натянуто за уши. Нужна скорость пишите хранимки. И все эти минусы из пальца высосаны.
И про ORM тоже самое, нужна скорость отказываемся и от него.


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

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

ORM действительно снижает скорость приложения (увиличивается количество запросов и снижается их качество),
но это решаемо, в любом ORM есть возможность писать запросы на прямую и вызывать хранимки. Зато ORM дает много других приемуществ ....
валидация, кеширование, разделение прав доступа, миграции и т.п. короче много готовых вещей, которые не нужно изобретать заново.
18 июл 12, 17:08    [12884714]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
Начинающий ORM-щик
Guest
рубист,

наверное спорный вопрос где лучше расположить бизнес логику в t-sql или в orm.
Просто вместо отдела t-sql был бы отдел php программистов :)
18 июл 12, 17:13    [12884746]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
рубист
Member

Откуда: с кудыкиных гор
Сообщений: 98
Начинающий ORM-щик
рубист,

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


Отдел программистов тоже был, как ни странно :),
но ты прав вопрос не просто и зависит от многих факторов.
18 июл 12, 17:30    [12884865]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
SmeL_md
Member

Откуда:
Сообщений: 1065
рубист
"Нужна скорость пишите хранимки" - как-то натянуто за уши и высасано из пальца :) ....
Аргументы.

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

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

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

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

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

валидация, кеширование, разделение прав доступа, миграции и т.п. короче много готовых вещей, которые не нужно изобретать заново.
Кэширование :) разделение прав уж точно дела не ORM а СУБД.
Про миграцию через ORM DBA вам бы точно руки по отрывал:)
18 июл 12, 17:59    [12885019]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 16827
автор
Про миграцию через ORM DBA вам бы точно руки по отрывал:)

очень интересно послушать как сделать миграцию без запуска скриптов.
делать хранимку, выполнять её и тут же грохать?
18 июл 12, 18:28    [12885145]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
рубист
Member

Откуда: с кудыкиных гор
Сообщений: 98
SmeL_md,

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

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

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

Кэширование :) разделение прав уж точно дела не ORM а СУБД.
Про миграцию через ORM DBA вам бы точно руки по отрывал:)

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

Мне вот интересно, как вы собираетесь обходить те минусы о которых я писал выше, при создании бизнес логики на основе хранимок?
Я их специально упомянул, так как по ним почти нет готовых решений. Наколенные велосипеды не предлагать :)
18 июл 12, 18:41    [12885220]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
SmeL_md
Member

Откуда:
Сообщений: 1065
ScareCrow
автор
Про миграцию через ORM DBA вам бы точно руки по отрывал:)

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

Уточню что я имел ввиду.
Предположим у нас вот такая ситуация простейшая ситуация поле int4 нужно сделать int8. ORM с такой задачей думаю справится и напишет там какой то ALTER TABLE. Выполнение даже такого простого запроса в версионных СУБД просто заблокирует таблицу (для некоторого бизнеса может и не быть проблемой). После таких операций таблица с индексами могут разбухнуть в двое да и выполняться может не только доли секунд а часы.
На мой взгляд это должен быть пакет sql запросов выполненный через консоль, а не через какой то там ORМ и выполнен человеком который понимает, как данные запросы отрабатывает СУБД

Но выполнение миграции в одной хранимке (транзакции) вариант надежный т.к. любая проблема (exception) откатит все что выполнялось внутри.
18 июл 12, 18:52    [12885269]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
SmeL_md
Member

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

Не согласен что будет с вашей базой, если просто зайти на нее с консоли.
Завтра продолжим... ;)
18 июл 12, 19:01    [12885308]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 16827
автор
Выполнение даже такого простого запроса в версионных СУБД просто заблокирует таблицу

автор
На мой взгляд это должен быть пакет sql запросов выполненный через консоль

уровень дискуссии ниже плинтуса.
18 июл 12, 19:10    [12885333]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 16827
мое имхо. ORM нужен, ибо в прикладном коде вместо getById(продолжить по вкусу экранированием параметров, sql инъекциями etc ) руками писать запрос просто глупо, надоедает после второго раза, и все, всё равно пишут что-то свое.
ORM нужен готовый потому что свой велосипед обычно с квадратными колесами, глючит, не покрыт тестами и хорошо документирован только на языке php.
Меру использования ORM каждый выбирает сам для себя.
18 июл 12, 19:14    [12885348]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
ShSerge
Member

Откуда: ʚонɔ dиw
Сообщений: 24874
ОРМ не нужен нафиг. Придуман для ламеров, чтобы подсадить на иглу.
18 июл 12, 20:30    [12885544]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 16827
автор
прикладном коде вместо getById(продолжить по вкусу экранированием параметров, sql инъекциями etc ) руками писать запрос

???
18 июл 12, 21:28    [12885661]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
Начинающий ORM-щик
Guest
Кто нибудь считает спорным утверждение, что с помощью ORM приложение разрабатывается быстрее?


Я склоняюсь к следующему подходу:
1) Редактирование простых сущностей в базе осуществлять через ORM
2) Тяжелые запросы, хитрые джойны и апдейты осуществлять прямыми запросами к базе или хранимками.
19 июл 12, 11:17    [12887236]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 16827
еще вьюхи есть, да. и триггеры.
19 июл 12, 11:23    [12887276]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
ShSerge
Member

Откуда: ʚонɔ dиw
Сообщений: 24874
Начинающий ORM-щик
Кто нибудь считает спорным утверждение, что с помощью ORM приложение разрабатывается быстрее?...

Угу. Имеются такие.
А особенно, если учесть, что над вашей базой не только пхп разрабатывается, а ещё и всякие делфи, сишарпы и т.д. и т.п. . Короче, ясно.
19 июл 12, 12:04    [12887605]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs голый SQL  [new]
рубист
Member

Откуда: с кудыкиных гор
Сообщений: 98
ShSerge
Начинающий ORM-щик
Кто нибудь считает спорным утверждение, что с помощью ORM приложение разрабатывается быстрее?...

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

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

Походу вы нормальный ORM в глаза не видели и не работали с ним в реальном проекте.
.... типа "не читал, но осуждаю" :)
19 июл 12, 14:08    [12888384]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
Все форумы / PHP, Perl, Python Ответить