[quot anton.k]medoedВ чем вопрос? Я считаю, что если нет полного функционала (а не отдельной функции) по федеративным связям (на удаление или изменение данных на удаленном источнике) - то да? я считаю такую СУБД не полноценной (тем более что здесь один и тот же источник данных база DB2). Мне есть с чем сравнивать, я поработал с базами Sybase, MSSQL и Oracle.
Вижу, что ущербность данного критерия оценки вам не очевидна. Придется объяснить на пальцах. Вот допустим, в DB2 есть такая замечательная функция как multi-temperature data management, а в MSSQL - нет. В DB2 есть настоящий, без всяких оговорок, columnar store engine. А в MSSQL - нет (а как же columnar store index скажите на это вы, и я отвечу - это костыль, который решает весьма ограниченный круг задач, это близко не то же самое, что columnar store в традиционном понимании). Исходя из этого, будем ли мы считать MSSQL ущербной СУБД? Следуя вашей же логике - нам так и слудует поступить. [quot]
А давайте проведем опрос среди разработчиков MSSQL и спросим натыкался ли кто то или не хватало ли тех возможностей то что вы описали выше?!
Я вам про распространенные вещи, а вы какие то узкопрофильные фишки! Да есть плюшки и в DB2 мне функция
понравилась, в MSSQL это через xml проще сделать. Но вот то что распостраненные вещи, которые в современных СУБД работают на ура в DB2 не реализованы! Неполноценная работа с федеративными серверами тому подтверждение! Ну а про то как они думают о конечных пользователях - показывает отсутствия деактивирования/активирования триггеров.

anton.kmedoedЯ вам про распространенные вещи, а вы какие то узкопрофильные фишки!
Вы упорно не желаете видеть дальше написанного. Я бы мог заменить multi-temperature и BLU (кстати, на счет BLU - вот уж никогда бы не подумал, что самая раскручиваемая в последнее время функция DB2 на самом деле узкопрофильная, ну да ладно) на десяток других возможностей, аналогов которых нет в MSSQL, суть от этого бы не изменилась. Мысль, которую я пытаюсь до вас донести очень простая - нельзя просто так взять и назвать информационную (да и любую другую) систему неполноценной, ущербной или недостойной внимания только потому, что в ней не реализованны некоторые функции, которые поддерживаются другими системами, потому что очень легко вы можете попасть в обратную ситуацию, как я вам это только что наглядно продемонстировал. Надеюсь с этим мы разобрались.

medoedА давайте проведем опрос среди разработчиков MSSQL и спросим натыкался ли кто то или не хватало ли тех возможностей то что вы описали выше?!
Очень хорошо, что вы об этом заговорили, потому что я могу предложить вам провести аналогичный опрос среди разработчиков DB2 с целью выяснения как многим из них нехватает возможности выполнять модифицирующие операции на федеративных объектах в триггерах, функциях и compound statement'ах.

medoedНу а про то как они думают о конечных пользователях - показывает отсутствия деактивирования/активирования триггеров.
Про то, как они думают о пользователях, лучше всего говорит количество разрешенных PMR и исправленных дефектов.
Опять вы много буков написали. Не жалеете своего времени Хотите опросы, проводите - мне за это деньги не платят.
Для меня прямым и косвенным доказательством является распространенность СУБД на рынках. MSSQL у нас более распространено чем DB2 и думаю не просто так! Выбирают чаще не только, что дешевле - но и то что удобнее! Адьюс!

Евгений Хабаровmedoed,

Любую задачу можно, как правило, решить более чем одним способом.

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

Но, вы пробовали сформулировать для себя или здесь исходную задачу?
Возможно, для нее существует другой способ решения, который более подходит для СУБД DB2.
Возможно, для СУБД DB2 вообще нет принципиальной необходимости разносить данные по нескольким базам, либо можно применить другие техники для решения первоначальной задачи.

Т.е. возможно для Вашей задачи существует другое архитектурное решение (для СУБД DB2), возможно даже более простое и надежное, чем то, что вы пытаетесь реализовать.
Ну, или, как вариант, СУБД DB2 не подходит (в чем я сомневаюсь) для решения той задачи, которая вам нужна.

В любом случае, это не повод говорить про "ущербность" DB2.
С тем же успехом я могу сказать что MS SQL совершенно ущербная СУБД, т.к. не работает на платформах IBM Power(AIX), IBM System z (z/OS и z/Linux). Для Вас это не критично, а для меня - очень критично.

В мире IT нет "серебряной пули", поэтому решение нужно подбирать под конкретную задачу. И иногда задачу нужно переосмысливать исходя из преимуществ, которые предоставляет продукт, чтобы максимально эффективно его использовать.
Мы уже решили эту задачу на текущий момент через клиент и дополнительную таблицу на справочной базе.
Я тут думал, мозххххи, которые все говорят о неверном архитектурном подходе и о том что не надо было разносить по разным базам - скажут нужное решение, но нет, они тока критиками могут быть!
Озвучу сам разумное решение - верным был бы подход (7-мь лет назад) разнести данные не по базам, а по схемам в рамках одной базы для каждой логической сущности. Это бы дало и независимость данных (не было бы блокировок) и скорость запросов была бы громоздкой! Минусом была бы динамика в запросах, но наш (да и любой толковый) клиент это умеет.

Зы: Про то что MSSQL не работает, под другие платформы согласен - но и винда не самая плохая и редкая вещь!
Сорри, но нет времени на дальнейшую переписку! Я останусь при своем мнении, а вы и дальше молитесь на IBM, я не против

Евгений Хабаровboogimanпропущено...

Каждую схему в отдельное табличное пространство и усе. Не?
Можно и каждую таблицу в отдельное табличное пространство.
Схема - это способ логической организации объектов (таблиц, индексов, функций и т.п.). Позволяет, помимо прочего, создавать одноименные таблицы (в разных схемах).
Ну это уже перебор, как мне кажется... Схема была бы удобно для каждой сущности(для каждого логического объекта). Получается совокупность классов, одинаковой структуры. Весьма удобно имхо...

const64boogimanПро рынки распространенности. Давайте рассмотрим те, которые не подвластны американскому лоббированию: Китай и Россия например. Посмотрим уровень распространенности современных СУБД в этих странах. Думаю DB2 уступит MSSQL and Oracle. Догадываетесь почему?
А ссылки есть? А то я пока только от Oracle нашел...
Искать в лом. Но опять же косвенные подтверждения есть:
T-SQL - язык года (2013)

const64medoedпропущено...

Искать в лом. Но опять же косвенные подтверждения есть:
T-SQL - язык года (2013)
Ну, ну, ну... а если на PHP в основном под MySQL пишут, то что, он круче чем MSSQL? А на C вообще можно писать под любую СУБД...
Ну вы высокоуровневые ООП языки с языками баз данных не путайте! У базы MySql своя ниша, думаю он тоже пораспространенней в вышеуказанных странах, чем DB2

anton.kboogimanКаждую схему в отдельное табличное пространство и усе. Не?
Забыли перелогиниться? ;) Я не могу утверждать однозначно, что это бы помогло в вашем конекретном случае. Да, возможно блокировок стало бы меньше, так же как и возможно, что это вовсе не было узким местом в вашей системе, так что предложенный вами вариант выглядит как неплохая попытка решить проблему малой кровью, но он вовсе не является панацеей и ничего не гарантирует. Впрочем, я уверен вы и сами это прекрасно понимаете.
Ага писал со смартфона, а там по дефолту для данного сайта другой логин стоял)) Думаю бы помогло и значительно (а малую кровь - считай халяву любят многие ). У нас сейчас половина проблем в блокировках от MQT, они бы соответственно стали не нужны. Другую крупную проблему даже озвучивать боюсь (засмеете), она в коде. Надоть будет попробовать как нить переписать.
Я рад, что вы признаете хоть отчасти разумные доводы собеседника

anton.kboogimanИдея была моя, но я зараннее уверен в результате, поэтому практику по опросу оставляю Вам.
Ну, я вот как раз имел ввиду именно это - вы просто уверены заранее, вы для себя все уже решили, доказывать вам что-то бесполезно. Спорить с таким оппонентом - это все равно, что валяться с боровом в грязи, так что я, пожалуй, оставлю вас в окружении столь очаровательных в своей наивности заблуждений, которые, возможно, сами развеятся со временем и приобретенным опытом.

boogimanПро рынки распространенности. Давайте рассмотрим те, которые не подвластны американскому лоббированию: Китай и Россия например. Посмотрим уровень распространенности современных СУБД в этих странах. Думаю DB2 уступит MSSQL and Oracle. Догадываетесь почему?
DB2 действительно уступает по распространнености ряду других крупных вендоров, однако, говоря, о распространнености, рассматривать ее нужно в разрезе региональных рынков и сегментов области пременения. И тогда окажется что там, где DB2 прочно занимает свою нишу, MSSQL не маячит даже на горизонте, и о каком доминировании, или распростраенности в таком случае можно вести речь? В этом вопросе вы снова совершаете всю ту же ошибку, что и раньше - вы выбираете слишком упрощенный критерий для оценки сложных процессов, который идеально подходит под выстроенную вами картину мира, но к реальности имеет весьма опосредованное отношение.
Уфф. Ну возьмем финансовый сектор или страховой, пусть даже Российский. Крупняк из СУБД выбирает как правило Oracle , мелкий и средний MSSQL. Я сейчас говорю исключительно о количестве, вы с этим будете спорить?

Евгений Хабаровmedoedпропущено...

Ну это уже перебор, как мне кажется... Схема была бы удобно для каждой сущности(для каждого логического объекта). Получается совокупность классов, одинаковой структуры. Весьма удобно имхо...
Я к тому, что схема и табличное пространство, условно говоря, перпендикулярны.
Схема - это логическое разделение объектов базы. Табличное пространство - физическое расположение и организация.
Разнесение таблиц по разным табличным пространствам и буферным пулам дает дополнительные рычаги управления производительностью и напрямую со схемой не связано никак.
Тоесть вы утверждаете, что
, если все таблицы схем находятся в разных табличных пространствах, то запросы будут лочить друг друга? При изоляции на уровне строк?
Я думаю вы не правы!!!

anton.kЕвгений ХабаровЯ к тому, что схема и табличное пространство, условно говоря, перпендикулярны.
Схема - это логическое разделение объектов базы. Табличное пространство - физическое расположение и организация.
Разнесение таблиц по разным табличным пространствам и буферным пулам дает дополнительные рычаги управления производительностью и напрямую со схемой не связано никак.
Думаю, тут имело место продолжение изначальной идеи разнесения таблиц по схемам, с последующей корректировкой, что все объекты из одной схемы будут помещены в отдельное табличное пространство
Да я это имел в виду!