28 октября 2011 г. 14:21 пользователь Евгений Торопов <span dir="ltr"><<a href="mailto:jt@aaanet.ru">jt@aaanet.ru</a>></span> написал:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><br><div><div><div class="h5"><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">
<div>Вы бы разделяли факты и суждения. Факт в том, что на его же тестах DBIC в 7 раз медленнее чистого DBI, а сколько там памяти дополнительной жрется - скромно умалчивается. И это все для того, чтобы автоматизировать простейшие задачи? Если для вас это приемлемо - тогда спорить бессмысленно :)</div>

<div><br></div><div>Про поддержку разных СУБД - это вообще нахер никому ненужный миф. Вы на больших проектах ее хоть раз меняли?</div></div></blockquote><div><br><br>Вообще-то, тут имеется в виду "несколько БД", а не "разные СУБД". СУБД мы не меняли, а вот БД разделяли, и именно использование ORM в этом случае сильно помогает.<br>
</div></div></blockquote><div><br></div></div></div>Хм, а как связаны между собой задачи БД-балансировки  и ORM? Или имеется ввиду что-то другое?</div></div></blockquote><div><br>Это не балансировка. Это когда раньше все данные лежали в одной схеме, а потом оказалось, что их чересчур много и имеет смыл некоторые положить в другую схему. В этом случае то, что раньше делалось со всякими JOIN'ами, в новой реальности работать не будет, потому что схемы лежат в разных коробках. И вот здесь наличие абстракции в виде ORM сильно помогает.<br>
<br></div></div>-- <br>Andrei Protasovitski<br>< andrei[dot]protasovitski[at]gmail[dot]com ><br>Diemen, Netherlands<br>