Kachalov
- каких ресурсов? сначала грузите СУБД выполнением ХП, потом мучительно пытаемся масштабировать БД?
Network, память, CPU, все это субд может использовать оптимальней за счет того что не нужно гонять копии данных на обработку, а машина хп интегрирована в SQL-машину и есть возможность совместного использования тех же переменных.

Kachalov
- видимо в этом месте необходим гипонз, а то что-то не верится
откройте для архитектуры субд чуть сложнее mysql и тут же обнаружатся плюсы в хп ;)

Kachalov
- меньше возможностей, язык оторван от ОО парадигмы, невозможность отладки, проблемы с обработкой ошибок, полноценная бизнес логика приводит к созданию процедур монстров, которые трудно читать и т. д. Противопоставлять язык ХП полноценному ЯП - какой-то бред.
по мне инструментарий для pl/sql так гораздо удобней особенно в плане обработки исключений и дебага. процедуры монстры получаются там где нет аналога pl/sql пакетов.
ну и главное комедия с натягиванием ООП на реляционные данные с шатанием в крайности от ОО-субд до недо-ОРМов - точно не вершина эволюции.

ЗЫ. ну и для совсем религиозных личностей есть элементы ООП в pl/sql, есть возможность писать хп на полноценном языке (java, .net), но они менее эффективны как в плане скорострельности так и в плане избыточности синтаксиса.

iscrafm
давно было написано . Я с тех пор взглядов не менял. Про гвозди и мясорубки думаю там достаточно однозначно сказано.
странно, я же из вашего поста понял, что вы домыслили за человека то что он будет из хп работать с оборудованием, почтой и файлами.

Kachalov- сколько стоит кластеризуемая СУБД и много ли их в принципе? в то время как OpenSource сервера приложений кластеризуются на ура, а платить приходится только за железо :)
а что толку от кластеризации апп-сервера ? основная нагрузка субд ложится на SQL движек и ио, процедурное расширения в учетных приложениях дает незначительную нагрузку на фоне SQL.

Yo.!
- перестаньте использовать термин СУБД, так как большинство СУБД явно не соответствует Вашим требованиям к СУБД и опубликуйте оставшийся список из 2-3 БД
я бы ограничил список одной субд - oracle, но к сожалению многие упомянутые вами вещи давно есть и в enterprisedb/postgres, db2 частично mssql ...

Yo.!
- пожалуйста не используйте термин СУБД вообще и смените свой логин на "Oracle DBA" - так будет честнее, по отношению к тем кто читает Ваш топик и думает что все что Вы пишите относится ко всем базам данных. По существу комментировать не буду, ибо у ДБА своя работа, у программиста своя, главное не забывайте делать ежедневные, недельные, месячные бэкапы и прочую хрень. Успехов.
мой логин слишком известен, чтоб его менять
ваши представление о работе дба на уровне ... на не адекватно низком уровне ...

Kachalov
- почитайте побольше о современных серверах приложений, практически все они имеют функционал объектного кэша и объектных транзакций, что позволяет существенно снизить нагрузку на СУБД
если бы у бабушки были бы яйца ... (С)
все что сейчас есть в плане интер-транзакционного кеша это или монстроидальная тупиковая ветвь аля ejb или хренотень которая даже acid не обеспечивает. единственно, что сегодня реально используется в индустрии это кеширование мелких справочников на уровне орм, что естественно особо нагрузку с субд не снимает.

Kachalov
- вот об этом я и говорил когда просил не злоупотреблять термином "СУБД" применительно к Вашим представлениям о ХП
простите, но то что вы наговорили о недостатках хп совершенная ерунда сказанная от незнания, в не зависимости от того, что я имел ввиду. тем более, что в отличие от вас именно в этой области у меня знания, а представления (причем ложные как у вас). если пожелаете я могу пройтись с примерами и показать и ООП-языки в хп и обработку исключений в процедурных языках хп, могу показать дебагеры и многое из того о чем вы и не подозревали. мне не лень

Kachalov
- жаль что мой намек остался непонятым, выражусь конкретней: рассуждения ДБА о программировании выглядят примерно также наивно, как рассуждения программиста о администрировании баз данных. Конечно Вы уверены что создаваемые Вами ХП решают все поставленные задачи, однако, поверьте, программирование это целый мир, о котором Вы многое не знаете (без обид, просто констатирую по Вашему посту о возможностях PL/SQL, недостатках ООП и т. д.)
лично я слабо себе представляю как дба может исполнять свои прямые обязанности не разбираясь в архитектуре ПО. выглядит, что у вас сложилось представление о дба как о мальчике который делает бэкапы. ладно, не страшно, с опытом представление изменится.

iscrafm
Есть два игрока: СУБД и Клиент. Нужно работать с вышеперечисленным. Домыслить не тяжело.
а, ну приношу глубочайшие извинения, я не угадал, что вы не только работу с железом из хп домыслили, но и "Есть два игрока"
к стате, откуда эта цифра "два" ?

iscrafm
возможно у Вас в двухзвенке есть еще какие-то игроки, но я замученных "гатальских" не рассматривал. Речь шла о классических вариантах. Да поддерживать бестолковый флуд "не в тему" не интересно
не пойму откуда вы это берете. где тут двузвенка, два игрока или что-то связанное с этой загадочной цифрой 2, ник что-ли ?

Alex S
Зачем класть яйца в одну корзину (ХП в СУБД)? Разве что для мелких устоявшихся программ. Но для крупных систем - это выращивание неповоротливого монстра с ограниченными возможностями.
ну если говорить о твоих яйцах то вообще-то вероятность того, что отвалится одна субд ровно в 2 раза ниже чем отвалиться или субд или апп-сервер