|
ru.perl
- RU.PERL ----------------------------------------------------------------------
From : Andrey Brindeew 2:5020/400 17 Dec 2002 18:59:26
To : All
Subject : Strong OO-programming & SQL databases
--------------------------------------------------------------------------------
Hi!
Мучает меня тут один вопрос мучает и причем довольно давно.
Как бы оптимально (и не криво с точки зрения авторов типа Гради Буча)
создавать объекты, сериализованные в базе данных?
Пример (слегка упрощенный) из жизни:
Есть список товаров (табл. goods) и привязка их к разделам магазина
(goods_cats). Hужно, допустим, при показе определенного раздела магазина
отобразить все товары из него.
Пусть товар отображается в класс Object::Good , еще есть класс
Object::Good::Category, который представляет запись из табл. goods_cats
(товар может находиться в нескольких категориях одновременно).
Как в конструкторе создать несколько экземпляров класса Object::Good
(соответственно и нужное кол-во инстансов Object::Good::Category)
оптимально с точки зрения базы? При создании объектов в цикле будет столько
SQL-запросов, сколько объектов создается, что не есть хорошо с точки зрения
производительности.
Можно передавать условия WHERE, ORDER BY и т.п., но их как-то нужно
автоматически обрабатывать при вызове конструкторов дочерних объектов -
Object::Good::Category в моем примере).
Если ограничиться только списком передаваемых Id объектов (суть primary
keys в таблицах), то приходим к изврату: сначала в скрипте нужно сделать
отбор этих самых Id, потом со списком Id нужно вызвать конструктор
Object::Good, который оттранслирует переданный список в WHERE id IN (".
join(",", @{ $id }) .")". И тут наступаем на большие грабли со стороны
многоуважаемой фирмы Sybase: WHERE может состоять максимум из 255 условий,
соединенных AND или OR (предложение IN оптимизируется внутри Sybase как id
= 1 OR ... OR id = k). Другие СУБД насчет этого специально не смотрел, но
на особые улучшения не надеюсь.
Есть какие-нибудь хорошо себя зарекомендовавшие проекты, в которых можно
посмотреть "правильную реализацию" того, что я описал выше?
--
WBR, Andrey Brindeew.
"No one person can understand Perl culture completely"
(C) Larry Wall.
--- ifmail v.2.15dev5
* Origin: MTU-Intel ISP (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
