Интеграция в ИТ на практике

Как ни ругают 1С77, но она все-таки работает во многих местах. Мне удалось убедить заказчика скрестить ядро nexus с сиквельным вариантом 1С77. Тем самым я получил второй пользовательский интерфейс дополнительно к существующему стандартному 1С77. Не надо говорить, что все преимущества nexus технологии спокойно можно заточить под 1С77 таблицы.

Такой подход "взятия на буксир" уже был отлажен на биллинговой системе BillOnLine несколько лет назад и позволил реанимировать ее. Она еще работала в течении трех лет пока само предприятие не умерло.

На очереди 1С8.
А также все остальные системы, которые просто неспособны к интеграции в гетерогенной среде. Я уже пробовал DocsVision, MS Project, CA TNG Unicenter:)

Комментарии

Изображение пользователя st.

У меня

У меня давно уже была мысля тебе предложить немного модифицировать нехус, чтобы он использовал не dbo-схему, а, например nexus. Тогда он практически гарантированно встанет в любую базу.

Изображение пользователя ipanshin.

Я пока не вижу

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

Кстати , также как и ты играешь в настольный теннис, я побывал на Эльбрусе, взобрался на 5000 метров. Правда до вершины не дошел. Возможность посетить вершину впервые у меня еще впереди. А пока испытал силы и проучаствовал в забеге "вертикальный километр". Был 39-м из 58 человек.

Изображение пользователя st.

Схема

Схема, начиная с 2005 версии отвязана от пользователя и представляет собой пространство имен верхнего уровня, например, предметной области в сложной БД (продажи, производство,финансы и т.п.).

А я вот был в Кисловодске в 1981 году, но на Эльбрус не попал. Экскурсия стоила 6 рублей с полтиной на физлицо, маман решила не растрачиваться. Только в Пятигорск и Ессентуки катались. До сих пор жалею. Кстати, на Эльбрусе, на высоте 5585 метров в прошлом году проходил матч по настольному теннису.

Изображение пользователя ipanshin.

Не скажу, что

Не скажу, что отвязка схемы от пользователя правомерна. Ведь тогда теряется собственник и остается просто множество. Кстати, требования к коду на порядок в этом случае возрастают. Старый код можно просто выкидывать.
Вместо select * from table надо писать select * from [db].[schema].[table]
Без кодогенерации не обойтись всяко. В динамическом сиквеле теряется эффективность кода и его экономность.

Твоя мама была права. Человек в зрелом возрасте это должен решать сам. Давай на следующий год запланируем восхождение. Я буду гидом.:)

Изображение пользователя st.

Схемы

Ну, схему-то рекомендуется писать всегда еще с версии MS SQL 7, даже dbo, потому что иначе тратится время на разрешение пространства имен и возможную последующую перекомпиляцию. Массовая переделка кода не нужна, т.к. если ты добавишь схему только в CREATE TABLE и CREATE PROC код внутри процедур будет использовать по умолчанию схему процедуры для разрешения имен.

Изображение пользователя ipanshin.

"код внутри

"код внутри процедур будет использовать по умолчанию схему процедуры для разрешения имен" - в этом и есть абсурд. на самом деле хп необходимо рассматривать как связку между пространствами имен, а не как внутренний объект. И как внутренний тоже, конечно.

Динамизм еще более усилится, если в ХП будет присутствовать динамический sql для подстановки пространства имен в зависимости от контекста процедуры.

Очень интересно. Надо реализовать.

схема vs другая БД

Чем лучше использование схемы по сравнению с отдельной БД на том же сервере?
Применительно к MS SQL Server мне эти варианты представляются почти одинаковыми.
Наверное правильно, создавать объекты одной предетной области в специально заведенной для этого схеме. Но если это не было сделано изначально, то переделка - просто трата ресурсов. Т.к. с точки зрения написания прикладных методов расположение объектов в отдельной схеме или отдельной базе существенной роли не играет.

Изображение пользователя st.

Основная причина

Основная причина для разработчиков - поддержка ссылочной целостности. Менее значимые: более короткая нотация имен, меньше накладных расходов на поддержку скриптов создания баз, нет необходимости следить за параметрами уровня разных БД, например, collation.

На административном уровне: меньше баз - меньше обслуживания, нет необходимости дублирования пользователей.

Основная причина выделения отдельной БД - ее разделение между многими приложениями, но с политкой безопасности, отличной от других БД. Чаще всего такой БД является БД прикладных пользователей, их ролей и прав доступа уровня приложения.

Изображение пользователя ipanshin.

Как раз сейчас

Как раз сейчас раздумываю куда реплицировать таблицу в отдельную схему или отдельную базу? И прихожу в выводу, что в отдельную базу лучше так как база с заточенной репликацией плохо сохраняется. А джоб в рамках одного сервера может работать с разными базами.
Таким образом все-таки есть существенное отличие базы от схемы при использовании репликации.