[Moscow.pm] v2 просьба о ревью модуля DBIx::Struct

[Alex Chistyakov]

2015-01-16 4:30 GMT+03:00 Warstone на list.ru <warstone на list.ru>:
> Fri, 16 Jan 2015 05:09:45 +0400 от Alex Chistyakov <alexclear на gmail.com>:
>
> 2015-01-16 3:47 GMT+03:00 Warstone на list.ru <warstone на list.ru>:
>>
>> Огласите весь список тех реляционных СУБД, которые могут.
>>
>> Здравствуй добрый тролль
>
> Вечер в хату!
>
>>
>> MySQL Cluster - это средство горизонтального масштабирования? Ооооокей.
>>
>> Могу ошибаться. Для меня MySQL синоним каки.
>
> Ну а я больше люблю зеленый чай, чем черный.
> Такая у нас примерно будет техническая беседа.
>
> Вы модуль читали? (Из-за чего весь сыр-бор) Вы почитайте... А то вдруг я тут
> дурак полностью и он гениален.

Похоже на то, что он и правда гениален. Я почитал синопсис и тест и
остался в тяжком недоумении.
Как мне вытащить структуру объектов (то, что в старом добром SQL
называется JOIN)? Где lazy loading? Где двухуровневый кэш?
Где генерация структуры таблиц по метаописанию на XML?
Нет, это не тот ORM, к которому я привык. Фиг бы с ним, с XML - но
зачем нужен конструктор запросов к единственной таблице?
Идти читать сам код я теперь немного боюсь - при таком радикальном
подходе к постановке задачи, кто его знает, что ждет в реализации...

--
SY,
Alex


>
>> Исторически. Его можно
>> использовать, но ты кровью расписываешься что ты понимаешь что делаешь.
>
> А PostgreSQL, стало быть, можно использовать, не понимая? Ну да,
> многие так и поступают.
>
>>
>>> Для PostgreSQL - это PostgreSQL-XC,
>>> который появился очень недавно и пока страшновато его использовать. Для
>>> платных СУБД - это "много денег за то что вы это будете использовать".
>>> Отсюда - перенос бизнес логики в приложение разгружает СУБД
>>
>> То есть, если мы перенесем в приложение ВСЮ бизнес-логику, СУБД работы
>> не останется?
>> O_O
>>
>> Как из моего текста можно было сделать этот вывод, я не знаю. Или разницы
>> между "разгружает" и "не останется" нету?
>
> Мне, собственно, интересно, как можно вынести CPU-bound задачи с СУБД
> (которая у всех нормальных людей обычно IO-bound) и что-то на ней
> разгрузить. Я, правда, достаточно повидал CPU-bound архитектурных
> решений на реляционных СУБД, но там вынос логики в приложение ничего
> не изменил бы - там надо линейкой по рукам фигачить.
>
> Есть еще вариант с wait-bound... Я такое тоже видал. Это когда в PL/Perlu
> удаленный хост через LWP дергают.
> Оно еще бывает Lock-Bound. Когда вы вроде-бы считаете не много, но за счет
> того, что в это время транзакция открыта - локи на таблицы висят красиво...
> Похлеще чем IDLE IN TRANSACTION, если вы понимаете...
> Причем зачастую, это рождается так: Была хранимка, а вот тут кровь из носу
> нужны вон те данные. А переделывает не автор. И все... Пипец.
>
> Хотел бы я это увидеть!
> Впрочем, в MySQL - запросто, но мы договорились уже, что он кака (в
> том числе - потому что у него репликация CPU-bound при определенных
> условиях).
> Вообще, конечно, не имея синхронной репликации в кластере СУБД
> разносить хранимки по разным нодам - это чисто теоретическая идея. Я
> бы так делать не стал. С другой стороны - что такое можно делать в
> хранимках, чтобы задолбать ими весь процессор, я тоже не очень знаю.
> Конвертировать видео? Биткойны майнить?
>
> Выше частичный ответ. И да, давайте не о MySQL.
>
>> У него
>> это написано вот тут:
>>
>> https://github.com/pef-secure/dbix-struct/blob/master/lib/DBIx/Struct.pm#L207
>> хотя у MySQL известно). При всем при этом стоимость масштабирования
>> приложения - +1 сервер. Посчитать можно спокойно... У вас было 3 сервера
>> (1
>> под Приложение, 2 под СУБД (реплика)), стало 5, а вообще-то 6. А так стало
>> 4
>> (2 под приложение, 2 под СУБД).
>> 2) Из здравого смысла. Если мы сместили боттлнек на приложение, то можно
>> спокойно добавить +1 сервер, а не +2,5 из текста выше.
>
> Боюсь, в тексте выше не использовалась строгая типизация - это вы там
> яблоки с совами сравнили.
>
> Это больше манагерский подход использовался "Сколько мне это будет в баксах
> / количествах серверов". Естественно дьявол - в деталях.
>
>> Причем в случае с
>> СУБД масштабированием у вас время нулевой транзакции увеличивается, то
>> есть
>> сервер начинает отвечать чуть медленнее.
>>
>> Было бы неплохо, если бы кто-нибудь внятно объяснил, наконец, почему.
>> Два утверждения "ORM - зло" и "мы не умеем им пользоваться" имеют
>> совершенно разный смысл, но часто - одинаковые последствия. Есть
>> случаи, когда ORM - безусловное зло, но это граничные случаи.
>> И, конечно, ORM большое зло, когда разработчики из-за предоставляемых
>> абстракций утрачивают связь с реальностью - ну да мы ж ведь с вами
>> профессионалы.
>>
>> Потому что из 2го часто следует 1е.
>
> Если люди не умеют использовать ORM, они себе чем угодно башку отстрелят.
> Что и происходит сплошь и рядом.
> Утверждение "мы откажемся от ORM прямо на этапе проектирования и
> поэтому заживем" - лютая чушь.
> Некоторые ORM отлично заменяют горе-рукоделов, для того и придуманы.
> Впрочем, некоторых авторов ORM я бы тоже в печи сжигал (оценочное суждение).
>
> Вот тут я не могу не согласиться. ORM - зло, отсутствие ORM - тоже. Жизнь -
> боль. Голактека жестока... Впрочем это уже из другой оперы.
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>