Чем плох язык mysql? Зачем вообще каждый фреймворк содержит обвязку, интерфейс доступа к данным?
cake.
findAll(«(`time`>».(time()-3600).»)AND(`status`=’0′)», array(«user»,»title»),»time», 10, 1, 0);
wordpress.
Залез в wordpress (конечно, не фреймфорк, но стало интересно, как там), наткнулся на функцию mysql2date, испугался, резко закрыл. Селекты в wp написаны непосредственно на sql, однако для update и insert сделаны тупые обвязки.
symfony
$c = new Criteria();
$c->add(tablePeer::TIME, time()-3600, Criteria::GREATER_THAN);
$c->add(tablePeer::STATUS, 0);
$c->addAscendingOrderByColumn(tablePeer::TIME);
$c->setLimit(10);
$c->setOffset(10);
$data = tablePeer::doSelect($c);
Zend Framework
$select = $db->select()
->from(«table»,array(‘user’, ‘title’))
->where(‘`time` > ?’, time()-3600)
->where(«`status` = ’0′»)
->order(«time»)
->limit(10, 10);
$t = $db->query($select);
$result = $t->fetchAll();
WACT
К сожалению, ничего интересного в стилях запросов нет. Запрос можно сделать через метод execute класса DBC.
Единственно, что примечательно, это документация и количество классов. Если б меня попросили сделать проект на WACT, используя его возможности и платили 100к баксов, я бы повесился. И делать бы не решился и отказаться нереально. 20 (?!?) классов для работы с бд, которые чёрт пойми что инкапсулируют, без какого-либо нормального описания.
То же самое на mysql
mysql_query(«SELECT `user`,`title` FROM `table` WHERE (`time`>».(time()-3600).») AND (`status`=’0′) ORDER BY `time` LIMIT 10,10″);
Риторический вопрос. Где код читабельнее и понятнее? Ну и стоило огород городить авторам фреймворков? Сначала ты думаешь, какой сделать запрос, потом переводишь его в значки для фреймворка. Никакой дополнительной логики они не превносят. Но делают несколько короче некоторые стандартные действия.
Зачем это делается, понятно. Структура базы никак не связана с логикой приложения. В попытке связать приложение с базой чем-то логичным и рождаются монстры, как у symfony (интересно, конечно, что они курили, когда это придумывали, но я бы это курить не рискнул, слишком сильное). Но потери при этом намного больше, чем выигрыш.
Sql выглядит практически текстом на английском языке. Вполне можно было сделать функцию с десятком параметров а-ля WindowsAPI, но люди напряглись, прикрутили неплохой синтаксический анализатор. А теперь куча народу старается, нивелирует всю пользу анализатора и опускает работу с базой обратно к куче функций с невменяемыми параметрами.
Однако развитие языков идёт по другому пути. По пути увеличения гибкости. Очевидно, что интерпретатор, понимающий человеческий язык гибче, чем тот, которому задачу нужно кодировать определёнными значками.
Поэтому хорошая обвязка для sql может быть та, которая повышает гибкость. Возможно, добавляет лишние умолчания (чем обьекты-обвязки и пытаются заниматься) и взаимосвязи между запросами (как $recursive в cakephp), но без потери гибкости языка.
Вот когда в тридцатый раз делаешь очередную админку для управления таблицей из бд, тогда и понимаешь зачем нужны фреймфорки. Ну да делать что-то нестандартное становится сложнее, зато вся рутина делается просто командой из шелла — одна строчка и готов просмотр таблицы, создание и редактирование элементов. То есть по факту, остается собственно то чем этот конкретный проект отличается от всех других, а все общие вещи генерятся вообще без кодинга. Так что до языка тут даже дело не доходит.
Админку для управления таблицей из бд?
А, ну может быть, я движки давно не писал, а под сеошные скрипты такие админки не требуются.
Но то, что ты сказал — это скаффолдинг. Штука очень удобная, согласен.
Вообще, фреймворки — это очень хорошо, особенно когда задача совпадает с той, для которой фреймворк написан. По сути — именно из-за скаффолдинга, а не из-за усложнённого интерфейса доступа к бд. Если задача выходит за рамки стандартной, от фреймворка имеет смысл отказаться.
Язык MySQL (а точнее диалект SQL) плох тем, что он не стандартен, то есть стандарт ANSI SQL есть, но все производители дружно на него забивают.
Все обвязки к БД (не только во фреймворках, но и, например, ODBC или JDBC) пишутся в том числе и для того, чтоб нивелировать различия в диалектах (и даже версиях), будь то MySQL 3/4/5, PostgreSQL, MS SQL, Oracle SQL, или даже SQLite или вообще текстовые файлы, чтобы безболезненно можно было перейти к другой БД. К тому же многие фреймворки сейчас готовы работать (по крайней мере теоретически, в рамках MVC), с XML, да и вообще любыми данными так же как с SQL. Просто в силу распространенности SQL и доступной наглядной модели реляционных БД даже не SQL БД (или вообще не БД) стараются приводить к синтаксису и/идеологии SQL БД именно с целью унификации кода. Например запрос «SELECT url FROM google WHERE locate(‘guestbook/add’, url)>0 LIMIT 1000″ может и не приводить к обращению к таблице с именем google, а к совсем другим действиям
А приложению будет все равно, будете вы брать урлы из БД или еще откуда-то 
Всегда можно правкой одной строки в параметрах или даже выбором радиобокса переключать между MySQL БД и другими источниками данных.
Обвязка — суть дополнительные тормоза. В большинстве случаев тормоза незначительные, но всё равно неприятно.
Переходить к другой СУБД… Такая возможность имеет смысл для крупных корпоративных приложений, где менеджеру дадут откат и он решит, что какая-то конкретная реализация sql лучше той, которую используют сейчас. Если у вас не такие приложения — то вам такая возможность к чёрту не нужна. В самом деле, когда вы последний раз меняли субд в своих прогах?
А работа с xml как с реляционной базой, возможна только на меленьких обьёмах данных, сами понимаете (несколько мегов). К xml даже индексы малореальны, это же не таблица, что б добраться до последнего элемента, нужно распарсить все предыдущие.
Да и пост не о том совсем. Пытаясь прикрутить посредственную универсальность, разработчики убивают хорошо понятный язык, основанный на английском. Превращают его чёрт знает во что.
По-моему далеко не всегда чистый SQL понятнее ОО кода с его умолчаниями и неявными связями. Преимущество SQL, наверное, заметно на средней сложности запросах, а в коротких и «многоэтажных» обвязки с умолчаниями и неявными связями способны многое взять на себя ускорив, прежде всего, разработку и упростив поддержку.
А еще вы в посте упустили еще такую «мелочь» как последующая работа с результатами того же селекта, а также динамическое формирование структуры (а не парметров) самого запроса.
И подход «Сначала ты думаешь, какой сделать запрос, потом переводишь его в значки для фреймворка» по моему неправилен при работе с фреймворками, думать нужно в терминах фреймворка(модели), а он пускай переводит, только если оптимизация нужна, тогда смотрим что он там напереводил
> думать нужно в терминах фреймворка
На простых преимущества фреймворка не будет. Т.к. и так запросы простые. На средних — будет выигрывать sql. На сложных фреймворк сможет выиграть, если модель построена удачно и вы действительно сможете думать в терминах фреймворка. Но думать так, это тоже, что думать на любом другом языке (фреймворк — диалект, конечно, но отличается немало от sql-а), хоть на английском. Можно, но только после значительной практики.