Программирование, ведущееся вокруг базы данных
Первыми к созданию кода, ориентированного на реляционные базы данных, приступили
специалисты, программирующие на таких процедурных языках, как С
и Кобол. Обычно они встраивали SQL непосредственно в свой код, используя либо
программные строки, либо препроцессор, который конвертировал SQL в исходном
тексте программы в низкоуровневые вызовы машины управления базой
данных. Интеграция означала, что переплетение логики базы данных с общей логикой
приложения становилось вполне естественным явлением. Разработчик,
желающий перебрать все заказы и обновить в каждом из них сумму налога с продаж,
мог написать что-нибудь, имеющее весьма неприглядный вид:
E X E C SQL BEGIN DECLARE S E C T I O N ;
i n t i d ;
f l o a t amount;
E X E C SQL END DECLARE S E C T I O N ;
E X E C SQL D E C L A R E cl AS CURSOR FOR s e l e c t i d , amount f r om o r d e r s ;
w h i l e ( 1 ) {
f l o a t t a x ;
E X E C SQL WHENEVER NOT FOUND DO b r e a k ;
E X E C SQL F E T C H cl I N T O : 1 d , :amount;
t a x = c a l c _ s a l e s _ t a x ( a m o u n t )
E X E C SQL UPDATE o r d e r s set tax = : t a x where id = : i d ;
}
E X E C SQL CLOSE c l ;
E X E C SQL COMMIT WORK;
Ну что, жутковато выглядит? Не стоит зря переживать. Мы не станем делать
ничего подобного, хотя этот стиль программирования вполне обычен для таких
языков сценариев, как Perl и РНР.
Его также можно применить и в Ruby. Например, мы можем использовать
имеющуюся в Ruby библиотеку DBI для создания фрагмента кода, похожего на
предыдущий. (В данном примере, как и в предыдущем, отсутствует проверка на
ошибки.)
d e f u p d a t e _ s a l e s _ t a x
u p d a t e = @ d b . p r e p a r e ( " u p d a t e o r d e r s set t a x = ? where 1d=?" )
§ d b . s e l e c t _ a l l ( " s e l e c t i d , amount from orders" ) do |id, amount|
tax = calc_sales_tax(amount)
update.execute(tax, id)
end
end
Это краткий, прямолинейный и к тому же широко используемый подход. Для
эебольших приложений он представляется почти что идеальным. Тем не менее
он не лишен проблем. Подобное смешение бизнес-логики и доступа к базе данных
может затруднить последующую поддержку и расширение приложения. А чтобы
приступить к его созданию, вам все равно понадобится знание языка SQL.
Допустим, к примеру, наше просвещенное правительство штата принимает
эовый закон, согласно которому мы обязаны фиксировать дату и время расчета
залога с продаж. На первый взгляд — никаких проблем. Нам нужно поместить
текущее время в наш цикл, добавить столбец к SQL-оператору update и поместить
время в вызов метода execute.
А что, если столбец налога с продаж придется вставлять во многие места приложения?
Придется просматривать код, выискивая и обновляя все нужные фрагменты.
В результате мы получаем продублированный код, а если пропустим место
для вставки столбца, то и источник ошибок.
В обычном программировании объектная ориентация учит нас, что подобные
проблемы решаются путем инкапсуляции. Все, что нужно сделать с заказом, должно
быть оформлено в виде класса; тогда у нас было бы единственное место для
знесения периодических изменений.
Специалисты распространили эту идею на программирование баз данных. Основная
предпосылка тривиально проста. Мы оформляем доступ к базе данных
на уровне классов. Все остальное приложение использует эти классы и их объекты
и никогда не вступает во взаимодействие с базой данных напрямую. Таким образом,
мы закапсулируем все, что относится к логической структуре на единственном
уровне, и отделим код приложения от низкоуровневых деталей доступа
к базе данных. В случае с изменениями налога с продаж нам нужно лишь внести
изменения в класс, в котором представлена таблица заказов, и добавить в него отметку
о времени вычисления этого налога.
Реализовать эту концепцию на практике куда сложнее, чем это может показаться
на первый взгляд. Реальные таблицы базы данных связаны между собой
(к примеру, в заказе может содержаться несколько записей), и мы хотели бы отразить
это в наших объектах: объект заказа должен содержать коллекцию объектов
атементарных записей. Но тогда мы начинаем ввязываться в вопросы навигации
по объектам, производительности и связности данных. Столкнувшись с такими
трудностями, промышленность сделала то, что всегда делает в подобных случаях:
изобрела трехбуквенный акроним ORM, который означает object-relational mapping,
то есть объектно-реляционное отображение. Rails именно ORM и использует.