Не уверен, что вопрос относится к собственно "программированию", но, тем не менее... Необходимо оценить жизнеспособность описанной ниже идеи организации базы данных на MS SQL 2000 или MS SQL 2005.
Создается специальная база данных MS SQL в которой вместо всех, т.е. вообще ВСЕХ таблиц (ну, может за некоторым исключением) создаются VIEW с тем же именем и той же структурой вида
PHP код:
CREATE VIEW dbo.MyTable
AS
SELECT Field1,Field2,DataAreaId,RecId
FROM DataBase1.dbo.MyTable
UNION ALL
SELECT Field1,Field2,DataAreaId,RecId
FROM DataBase2.dbo.MyTable
Т.е. эта специальная база даных собирает информацию из нескольких баз данных MS SQL. Получаем
распределенную базу данных. Понятно, что можно указать в качестве источника и Linked-сервера. Т.е. вообще физически удаленные сервера.
Далее собствено AXAPTA подкладываем в качестве базы данных эту "сводную" базу данных. Т.е. AXAPTA "думает" что обращается к таблице MS SQL, но на физическом уровне обращение идет через View.
Эксперимент проводился на AXAPTA 2.5 SP3 + MS SQL 2005.
ЭТО РАБОТАЕТ! Как на чтение (что ожидаемо), так и на запись (нужны определенные настройки таблиц и дополнительный CONSTRAINT). Пока, разумеется, как тестовый пример на нескольких таблицах.
Также понятно, что при "падении" одной базы "упадет" и эта общая база. Просто View не сможет сделать выборку. Вопрос о другом.
Какие проблемы могут быть собственно в AXAPTA при работе с такой базой?
Конечная цель - получить хранение разных компаний физически в разных базах MS SQL. Но с общими справочниками и возможностью взаимодействия между базами (копирование некоторых данных)
Т.е. предполагается, что в разных базах MS SQL будут данные с разным (не пересекающимся) значением DataAreaId. Виртуализированные таблицы будут хранится в какой-то одной базе (отпадает проблема синхронизации справочников). А вопрос взаимодействия решается штатным ChangeCompany().