[Moscow.pm] Размышления на тему HTML и вообще

[Oleg Kostyuk]

А поделитесь, пожалуйста, практическим примером.

У меня буквально на днях возник проект в двумя схемами (Pg). Начал
думать как сделать - две dbic-шных схемы или одну? Мэтт на irc говорит
делай одну. Ну, в результате сделал примерно так:

lib/....../Schema/DB.pm
.......
__PACKAGE__->load_namespaces(
    result_namespace    => 'Class',
    resultset_namespace => 'ResultSet',
);
.......

Ну и далее всё в файлах lib/....../Schema/DB/Class/Data/*.pm и
lib/....../Schema/DB/Class/Public/*.pm - для схем data и public
соответственно. Чтоб не писать в table() имена таблиц с именем схемы
(а то мало ли - сегодня таблица в одной схеме, завтра в другой) -
использовал on_connect_do как описано в DBIx::Class::Storage::DBI::Pg.
К сожалению, проект свернули, практически сразу, потому я не знаю, что
из этого получилось бы в дальнейшем, и на сколько это вообще было бы
удобно на практике.

Потому собственно и вопрос - а как было у вас? Поделитесь.



28 октября 2011 г. 15:27 пользователь Andrei
<andrei.protasovitski на gmail.com> написал:
> 28 октября 2011 г. 14:21 пользователь Евгений Торопов <jt на aaanet.ru>
> написал:
>>
>>> Вы бы разделяли факты и суждения. Факт в том, что на его же тестах DBIC в
>>> 7 раз медленнее чистого DBI, а сколько там памяти дополнительной жрется -
>>> скромно умалчивается. И это все для того, чтобы автоматизировать простейшие
>>> задачи? Если для вас это приемлемо - тогда спорить бессмысленно :)
>>> Про поддержку разных СУБД - это вообще нахер никому ненужный миф. Вы на
>>> больших проектах ее хоть раз меняли?
>>
>> Вообще-то, тут имеется в виду "несколько БД", а не "разные СУБД". СУБД мы
>> не меняли, а вот БД разделяли, и именно использование ORM в этом случае
>> сильно помогает.
>>
>> Хм, а как связаны между собой задачи БД-балансировки  и ORM? Или имеется
>> ввиду что-то другое?
>
> Это не балансировка. Это когда раньше все данные лежали в одной схеме, а
> потом оказалось, что их чересчур много и имеет смыл некоторые положить в
> другую схему. В этом случае то, что раньше делалось со всякими JOIN'ами, в
> новой реальности работать не будет, потому что схемы лежат в разных
> коробках. И вот здесь наличие абстракции в виде ORM сильно помогает.
>
> --
> Andrei Protasovitski
> < andrei[dot]protasovitski[at]gmail[dot]com >
> Diemen, Netherlands
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>



-- 
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)