«Чистый» SQL в веб-проектах

Question

[Rivethead]

Давно интересует вопрос, что чаще используется в веб-проектах? SQL в чистом виде, или же чаще встречается ORM? Предлагаю исключить из рассматриваемых вариантов сайты-визитки, хомпаги и т.п.
Если кто может поделиться историей почему он использовал одно и перешел к другому — еще лучше.

Comments

[Rivethead]

Немного уточню, хотелось бы узнать ведется ли при этом разработка в команде или в одиночку?

Answer 1

[betal]

Использую в зависимости от ситуации, когда работа с одним объектом ORM, удобно и наглядно. Сложные запросы или запросы ORM съедающие много оперативной памяти или иных ресурсов в чистом виде.

Comments

[Rivethead]

Командная разработка? Или вы один ведете весь проект?

[betal]

3 программиста, порядка 100 тысяч строк.

Answer 2

[rozhik]

Часто встречаются оба подхода. Не редко оба в одном проекте.

Использовали оба подхода. Для простых вещей без акцента на производительности — ORM, но не редко ORM делает не эффективные SQL запросы.
Сейчас практически только ORM, требовательное к производительнности на PHP уже не пишем.

Answer 3

[Александр Кит]

Тяжелые выборки — в хранимых процедурах (MSSQL), а для вещей попроще — хороший QueryBuilder с оберткой для db драйвера. Чистый SQL в коде я давно уже не видел. Правильное форматирования запроса, параметры, соединения и прочее должны перекладываться на плечи других библиотек. И ещё, хороший QueryBuilder создает дополнительный уровень абстракции между запросом и драйвером базы, таким образом мы от него отвязываемся, и поэтому возможно будет даже другую базу использовать, например SQLite вместо mssql

Answer 4

[Masterme]

Чистый SQL с многоэтажными запросами используется там, где значительная часть логики приложения сосредоточена в БД. Такое приложение может иметь веб-морду, но это не то же самое что веб-ориентированное приложение. Приложения с логикой в БД (т.е. манипулирующие именно данными в пределах реляционной схемы, а не I/O, периферией, хранением кэша и т.д.) — это приложения интрасетей, которые плохо масштабируются между серверами: бухгалтерия, билинг, базы клиентов, инвентаря и т.д.

Comments

[Masterme]

Кроме того, приложения на SQL нужно тестировать по иному методу, чем приложения на функциональном или объектном языке. Так что, ORM в веб-проектах вполне оправданы.

Answer 5

[svd71]

Если создавать структуры, подобные «объект-ориентированным», с хранением данных в базе, то для работы таких объектов логичнее использовать простые запросы. Запросы начинают усложняться при сложности объектов: объект включает в себя много других объектов и что бы съэкономить время на обращении к БД использует сложный запрос.

Так же сложные запросы могут отребоваться при составлении отчетов и других человекопонятных вещей.

Просто старайтесь при таких подходах исходить из простоты. Чем проще написано, тем проще настраивать и проще контролировать. Да и скорость выигрывает.