Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Romka-Fes
Member

Откуда: Kyiv
Сообщений: 456
Всем здравствуйте!

Есть некая проблема перемещения данных из одной системы в другую.
Данные предполагают под собой классическую древовидную структуру. Т.е. есть parent и child строки в исходной таблице, которые связаны по GUID.
Первоначальный импорт данных, как-бы, решаем малой кровью: берём исходные данные, пишем в tmp table, пробегаемся по всей этой лапаше, распихивая uptdae'ом GUID'ы парентов по всем строкам и пихаем результат в целевую таблицу (у кого-то есть лучший вариант?! - поделитесь).
Но когда в исходных данных что-то:
1. могло удалится и "сместился" предок.
2. могли добавится записи в какие-то узлы дерева.
Какую бы Вы архитектуру/систему/логику обновления исходных данных к конечным использовали-бы?

p.s. Полагаю что могут возникнуть обоснованные вопросы/претензии к этому: "распихивая uptdae'ом GUID'ы парентов по всем строкам и пихаем результат в целевую таблицу". Тут суть в чём: я из исходных данных беру то что нужно для записи изначально, а потом обновляю GUID's парентов следующим шагом, так как структура дерева находится в отдельной, от самих данных, таблице.
3 июл 17, 22:31    [20610719]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Akina
Member

Откуда: Зеленоград, Москва, Россия
Сообщений: 20538
Romka-Fes
Какую бы Вы архитектуру/систему/логику обновления исходных данных к конечным использовали-бы?
Если стоИт задача именно перемещения - то почему Вас волнуют несоответствия данных? перемещение - это копирование AS IS. Есть проблемы? исправьте их до перемещения - или смиритесь с тем, что они будут в копии (и их придётся исправлять уже там).
Romka-Fes
Первоначальный импорт данных, как-бы, решаем малой кровью: берём исходные данные, пишем в tmp table, пробегаемся по всей этой лапаше, распихивая uptdae'ом GUID'ы парентов по всем строкам и пихаем результат в целевую таблицу (у кого-то есть лучший вариант?! - поделитесь).
Если на целевой таблице имеется констрейнт на непустую зависимость, то в ходе вышеописанного ещё необходимо соблюдать порядок вставки, чтобы не возникло ситуации, когда дочка вставляется до мамки. Обычно для этого записи при выгрузке сортируются в порядке возрастания уровня. Ну а загрузка, само собой, идёт в порядке физического следования.
Что же до "распихивания GUID парентов" - то вот тут совсем не понял. В исходных данных это всё уже имеется. Ну а если Вы в процессе копирования ещё и GUID-ы меняете - то я вообще не знаю, как назвать этот процесс... но точно не копированием.
4 июл 17, 07:53    [20610938]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Romka-Fes
Member

Откуда: Kyiv
Сообщений: 456
Akina
Если стоИт задача именно перемещения - то почему Вас волнуют несоответствия данных?

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


Akina
Ну а если Вы в процессе копирования ещё и GUID-ы меняете - то я вообще не знаю, как назвать этот процесс... но точно не копированием.


Процесс я бы описал так: это первоначально - копирование, а затем уже обновление/синхронизация.
Но делать надо всё одной процедурой.
4 июл 17, 10:34    [20611349]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7780
Romka-Fes,

что не так с репликацией?
4 июл 17, 11:31    [20611556]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Romka-Fes
Member

Откуда: Kyiv
Сообщений: 456
А причём тут репликация?
Речь идёт о двух абсолютно разных системах, между которыми надо интеграцию реализовать.
Это разные таблицы, с различной структурой в разных СУБД.
Но данные я забираю таки из БД MS SQL, некой, промежуточной.
4 июл 17, 14:37    [20612355]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
LSV
Member [заблокирован]

Откуда: Киев
Сообщений: 30817
Какую бы Вы архитектуру/систему/логику обновления исходных данных к конечным использовали-бы?
Для случая, когда изменение структуры и логики сабжевых таблиц невозможно (н-р нельзя добавить поле с временем последней модификации), то подойдет только полное сравнение.
4 июл 17, 15:25    [20612542]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Romka-Fes
Member

Откуда: Kyiv
Сообщений: 456
LSV
Какую бы Вы архитектуру/систему/логику обновления исходных данных к конечным использовали-бы?
Для случая, когда изменение структуры и логики сабжевых таблиц невозможно (н-р нельзя добавить поле с временем последней модификации), то подойдет только полное сравнение.

А для случая, когда возможно? Я могу поменять структуру как в промежуточной БД, так и добавить поля в целевой.


p.s. кто-то пользуется MERGE для подобного рода задач?
4 июл 17, 17:21    [20613140]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7780
Romka-Fes,

непонятно, какую задачу Вы решаете. Вы описали способ решения, но из него задачу понять невозможно.
4 июл 17, 23:54    [20614069]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
в
Guest
https://www.mssqltips.com/sqlservertip/4545/synchronizing-sql-server-data-using-rowversion/
5 июл 17, 16:18    [20616395]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Romka-Fes
Member

Откуда: Kyiv
Сообщений: 456
в
https://www.mssqltips.com/sqlservertip/4545/synchronizing-sql-server-data-using-rowversion/

Спасибо, обязательно ознакомлюсь, а сейчас вот почти подготовил тестовый пример, скоро выложу...
5 июл 17, 17:15    [20616654]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
LSV
Member [заблокирован]

Откуда: Киев
Сообщений: 30817
Romka-Fes
LSV
пропущено...
Для случая, когда изменение структуры и логики сабжевых таблиц невозможно (н-р нельзя добавить поле с временем последней модификации), то подойдет только полное сравнение.

А для случая, когда возможно? Я могу поменять структуру как в промежуточной БД, так и добавить поля в целевой.
Надо не просто добавить поля, но еще и логику добавить. Тогда по дате обновления строки можно быстро обновить/создать только нужные записи. Удаление тоже нужно как-то "описать", чтобы знать что удалять на копии (н-р триггером наполнять ключами спец. табличку).

Если исходная таблица небольшая, то проще копировать ее целиком.
5 июл 17, 17:17    [20616660]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Romka-Fes
Member

Откуда: Kyiv
Сообщений: 456
Владислав Колосов,

Итак, есть 2 таблицы. Для простоты, будем полагать что они находятся на одном сервере и в одной БД.

Таблицы "источник":

CREATE TABLE [dbo].[source](
	[id] [int] IDENTITY(1,1) NOT NULL,
	[guid] [uniqueidentifier] NOT NULL,
	[parent_guid] [uniqueidentifier] NULL,
	[name] [nvarchar](100) NOT NULL,
	[value] [money] NOT NULL,
	[project_guid] [uniqueidentifier] NOT NULL,
 CONSTRAINT [PK_source] PRIMARY KEY CLUSTERED 
(
	[id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

ALTER TABLE [dbo].[source] ADD  CONSTRAINT [DF_source_value]  DEFAULT ((0)) FOR [value]
GO


И "приёмник":

CREATE TABLE [dbo].[dest](
	[id] [int] IDENTITY(1,1) NOT NULL,
	[guid] [uniqueidentifier] NOT NULL,
	[src_guid] [uniqueidentifier] NOT NULL,
	[src_parent_guid] [uniqueidentifier] NULL,
	[name] [nvarchar](100) NOT NULL,
	[value] [money] NOT NULL,
	[project_guid] [uniqueidentifier] NOT NULL,
 CONSTRAINT [PK_dest] PRIMARY KEY CLUSTERED 
(
	[id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

ALTER TABLE [dbo].[dest] ADD  CONSTRAINT [DF_dest_guid]  DEFAULT (newsequentialid()) FOR [guid]
GO

ALTER TABLE [dbo].[dest] ADD  CONSTRAINT [DF_dest_value]  DEFAULT ((0)) FOR [value]
GO


Ситуация такова что некая система пишет данные в таблицу источник. Все данные сгруппированы по некой сущности, назовём её проект, у каждого из которых есть свой GUID.

В некоторый момент времени надо данные из исходной системы (а именно из таблицы source, в которую она должна их записать) нужно "залить" в систему приёмник, в таблицу dest.

IF EXISTS (SELECT 1 FROM source)
BEGIN
	DELETE FROM source
END

declare @ProjectGUID uniqueidentifier
SELECT @ProjectGUID = NEWID()


BEGIN TRAN

INSERT INTO source (guid,name,value,parent_guid,project_guid) VALUES (newid(),'Super Parent','1000.0',NULL,@ProjectGUID)

COMMIT TRAN

declare @SuperParentGuid uniqueidentifier

SELECT @SuperParentGuid = [guid]  FROM Source WHERE name = 'Super Parent'

INSERT INTO source (guid,name,value,parent_guid,project_guid) VALUES (newid(),'1st child','500.0',@SuperParentGuid, @ProjectGUID)

INSERT INTO source (guid,name,value,parent_guid,project_guid) VALUES (newid(),'2nd child','300.0',@SuperParentGuid, @ProjectGUID)

INSERT INTO source (guid,name,value,parent_guid,project_guid) VALUES (newid(),'3d child','200.0',@SuperParentGuid, @ProjectGUID)

declare @2ndParentGuid uniqueidentifier
SELECT @2ndParentGuid = [guid]  FROM Source WHERE name = '2nd child'

INSERT INTO source (guid,name,value,parent_guid,project_guid) VALUES (newid(),'1st Child of 2nd','100.0',@2ndParentGuid, @ProjectGUID)
INSERT INTO source (guid,name,value,parent_guid,project_guid) VALUES (newid(),'2nd Child of 2nd','100.0',@2ndParentGuid, @ProjectGUID)
INSERT INTO source (guid,name,value,parent_guid,project_guid) VALUES (newid(),'3d  Child of 2nd','100.0',@2ndParentGuid, @ProjectGUID)

declare @3dParentGuid uniqueidentifier
SELECT @3dParentGuid = [guid]  FROM Source WHERE name = '3d child'

INSERT INTO source (guid,name,value,parent_guid,project_guid) VALUES (newid(),'1st Child of 3nd','100.0',@3dParentGuid, @ProjectGUID)
INSERT INTO source (guid,name,value,parent_guid,project_guid) VALUES (newid(),'2nd Child of 3nd','100.0',@3dParentGuid, @ProjectGUID)
INSERT INTO source (guid,name,value,parent_guid,project_guid) VALUES (newid(),'3d  Child of 3nd','100.0',@3dParentGuid, @ProjectGUID)

/* это INSERT  и есть "первоначальный" импорт данных */

INSERT INTO dest (src_guid, src_parent_guid, name, value, project_guid)
SELECT guid, parent_guid, name, value, project_guid
FROM source
WHERE project_guid = @ProjectGUID


SELECT * FROM source
order by id 

select * from dest 
ORDER by id 



Потом в какой-то момент времени данные в системе источнике изменились:
1. Могут быть удалены строки, т.е. поменяются GUID предков, у тех строк, что остались.
2. Одна строка может быть "разбита" на 2. Т.е. значение VALUE будет уменьшено и будет добавлена новая строка с таким же parent_guid с value равном разнице между начальным значением и новым. Т.е. в сумме 2 строки дадут прошлое значние value.
3. Может быть добавлена новая запись, в каком угодно узле дерева.
4. Может изменится название.
5. Записи могут "переехать" от одного предка к другому
6. etc...

Задача: как наиболее изящно, желательно одним запросом ( :) ) сделать обновление данных в рамках одного ProjectGUID?

Т.е. чтобы данные в таблице dest после обновления соответствовали данным в source

Есть условия касательно dest:

1. В неё могут быть добавлены строки, которых не было в Source, пусть , например, они будут без ProjectGUID (для того чтобы их отличать)
2. Удалять данные в dest нельзя, в силу п.1. Т.е. вариант - "удалить всё и записать заново" не подходит.
5 июл 17, 17:30    [20616701]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Romka-Fes
Member

Откуда: Kyiv
Сообщений: 456
LSV
Romka-Fes
пропущено...

А для случая, когда возможно? Я могу поменять структуру как в промежуточной БД, так и добавить поля в целевой.
Надо не просто добавить поля, но еще и логику добавить. Тогда по дате обновления строки можно быстро обновить/создать только нужные записи. Удаление тоже нужно как-то "описать", чтобы знать что удалять на копии (н-р триггером наполнять ключами спец. табличку).

Если исходная таблица небольшая, то проще копировать ее целиком.


"Надо не просто добавить поля, но еще и логику добавить." - есс-но, что это очевидно :).
В этом-то и суть вопроса, как покрасивше это сделать.
Здесь есть 1 нюанс: есть исходная система, есть промежуточная, и есть целевая.
И в обоих крайних могут происходить любые изменения данных.
Какую-то валидацию/запреты разве что на триггерах можно наваять.


"Тогда по дате обновления строки можно быстро обновить/создать только нужные записи" - что такое "быстро" ? И что такое "нужные"? О какой быстроте/скорости может идти речь в конкурентной транзакционной среде? Говоря о дате, Вы имели в виду timestemp? - это как раз вариант из ссылке выше, курю его, как альтернативный.

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

Но кто сможет таки внятно пояснить - нахрена таки нужен MERGE и применим ли он в этом контексте?

" чтобы знать что удалять на копии (н-р триггером наполнять ключами спец. табличку)" - вот как раз не хочется хранить на целевой системе всю историю. Хочется сделать систему (в терминах сетевых приложений) без "поддержки состояния клиента".
Т.е. чтобы там ни было "на входе" - на выходе получаем аналогичный результат, не затрагивая данные, которые были сделаны в самой целевой системе.
5 июл 17, 22:29    [20617364]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Romka-Fes
Member

Откуда: Kyiv
Сообщений: 456
LSV
Если исходная таблица небольшая, то проще копировать ее целиком.

Копировать куда? Затирать существующий набор данных полностью? Вопрос не в копировании/замене, а в корректном обновлении целевой таблицы на основании имеющихся данных в исходной.
Критерии корректности я вроде-бы описал. Если невнятно/неверно/непонятно, буду пробовать себя исправить в этом контексте.
Но таки ткните, пожалуйста, пальцем в мою апшибку описания этих критериев.

Я говорю об обновлении данных в контексте некоего набора строк (Project_Guid).
+ в целевой таблице могут появится новые строки с этим Project_Guid, которые нельзя потерять при обновлении.
5 июл 17, 22:35    [20617376]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
HandKot
Member

Откуда: Sergiev Posad
Сообщений: 2979
Romka-Fes
p.s. кто-то пользуется MERGE для подобного рода задач?

Есть желание - применяйте.
Примерно так
;
Merge dest as Trg
Using (выборка из источника) as Src
On Src.[src_guid] = Trg.[src_guid] And Src.[src_parent_guid] = Trg.[src_parent_guid]
When Matched Then 
	Update --а может и не надо
When Not Matched Then
	Insert
When Not Matched By source And Not (тут условия касательно dest пункт 1) Then Delete
	
6 июл 17, 07:15    [20617627]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
LSV
Member [заблокирован]

Откуда: Киев
Сообщений: 30817
Копировать куда? Затирать существующий набор данных полностью?
Именно так. Если в таблице 10000 строк, то намного проще ее очистить и полностью перезалить. Время нецелостности/простоя будет пару секунд.
Если не делать это каждых 5 минут, то может быть вполне себе ОК.
6 июл 17, 09:59    [20617880]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Romka-Fes
Member

Откуда: Kyiv
Сообщений: 456
LSV
Копировать куда? Затирать существующий набор данных полностью?
Именно так. Если в таблице 10000 строк, то намного проще ее очистить и полностью перезалить. Время нецелостности/простоя будет пару секунд.
Если не делать это каждых 5 минут, то может быть вполне себе ОК.


Если бы можно было бы так делать, я бы так и делал. Но, увы ...

"Есть условия касательно dest:

1. В неё могут быть добавлены строки, которых не было в Source, пусть , например, они будут без ProjectGUID (для того чтобы их отличать)
2. Удалять данные в dest нельзя, в силу п.1. Т.е. вариант - "удалить всё и записать заново" не подходит. "
6 июл 17, 14:07    [20619094]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7780
Romka-Fes,

это как раз задача для репликации таблицы.
6 июл 17, 14:14    [20619119]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Romka-Fes
Member

Откуда: Kyiv
Сообщений: 456
Владислав Колосов,

Эти 2 таблицы в одной БД я привёл для упрощения примера.

Только эту репликацию надо вручную написать...
В чём-то же и заключается вопрос...

Системы на разных серверах и разных БД.

источник пишет в таблицы промежуточной БД и запускает хранимые процедуры, которые записывают данные в целевую систему.
Структура таблиц на самом деле весьма различается, там ещё много всякого рода вычислений и преобразований и доп. действий происходит.
6 июл 17, 16:06    [20619689]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Гулин Федор
Member

Откуда: МИНСК
Сообщений: 1240
LSV
Копировать куда? Затирать существующий набор данных полностью?
Именно так. Если в таблице 10000 строк, то намного проще ее очистить и полностью перезалить. Время нецелостности/простоя будет пару секунд.
Если не делать это каждых 5 минут, то может быть вполне себе ОК.


Не уверен что прокатит но напишу
есть фокус с switch partition
вообще он для других целей
но мне сдается может прокатить если писать с другую
целиком подменять - будет быстро

https://technet.microsoft.com/en-us/library/ms191160(v=sql.105).aspx?f=255&MSPPError=-2147217396

зы а станд. да - Merge
6 июл 17, 16:08    [20619705]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Гулин Федор
Member

Откуда: МИНСК
Сообщений: 1240
Romka-Fes
Владислав Колосов,

Эти 2 таблицы в одной БД я привёл для упрощения примера.

Только эту репликацию надо вручную написать...
В чём-то же и заключается вопрос...

Системы на разных серверах и разных БД.

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


я надеюсь что все хоть на MS-SQL ?
6 июл 17, 16:13    [20619733]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Romka-Fes
Member

Откуда: Kyiv
Сообщений: 456
Гулин Федор,

В некотором, частном случае, да, промежуточная (интеграционная) БД и целевая - на MS SQL. В общем - ещё может быть Oracle, но это оффтоп. Но раз уже прозвучал такой вопрос, буду пробовать играться с MERGE, так как его же, наверное, нужно будет и для Oracle (но он там несколько иной чем в MS SQL) использовать.
6 июл 17, 16:18    [20619755]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Гулин Федор
Member

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


ну или модификацию
для того чтобы не переписывать все таблицы с исх. сервера на целевой (минимизаци трафика)
делал так
есть таблица
problem с PK : id

сделал отдельную бд (можно схему в БД - но я там не мог менять исходную БД )
dlt_problem : id
и cheksum нужных мне полей (мне не все нужны) + (пара служебных полей - типы даты посл. забора даннных )
вытянуть их всех в строку
учитывая конечно null --> т.е для каждого null поля : isnull( fild1 , ''@")

делал процедурку для каждой таблицы к-ю надо было тянуть

1 возвращающую дельту с полем Falg_IUD (insert/update/delete)
2 обновлюящую поле чек-суммы (после забора данных)


но даже вытянув дельту - в целевую таблицу только мерж
6 июл 17, 16:21    [20619776]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Гулин Федор
Member

Откуда: МИНСК
Сообщений: 1240
Romka-Fes
Гулин Федор,

В некотором, частном случае, да, промежуточная (интеграционная) БД и целевая - на MS SQL. В общем - ещё может быть Oracle, но это оффтоп. Но раз уже прозвучал такой вопрос, буду пробовать играться с MERGE, так как его же, наверное, нужно будет и для Oracle (но он там несколько иной чем в MS SQL) использовать.


Если там будут разные БД
то имхо скорей всего понадобтися ETL тул
скорей всего SSIS (если ЦЕЛЕВАЯ БД MS-SQL)
+ там Attunity driver для Оракла

merge в оракле давно есть - в мс-скл он по моему с 2008 появился
но я как то слабо понимаю почему ЦЕЛЕВАЯ БД - можте быть РАЗНОЙ
т.е я бы понял что разные источники - разные БД


зы если мс-скл - линк-сервер создать и вперед пробовать
елси стандарт. репликация не прокатыает - (я тут НЕ спец - но со знающими людьми стоит проконультироваться
вдруг то что ты хочешь сделать делается какими то стандарнытми средствами )
6 июл 17, 16:27    [20619816]     Ответить | Цитировать Сообщить модератору
 Re: Абстрактно/Конкретный вопрос о данных, деревьях и их обновлении...  [new]
Romka-Fes
Member

Откуда: Kyiv
Сообщений: 456
но я как то слабо понимаю почему ЦЕЛЕВАЯ БД - можте быть РАЗНОЙ
т.е я бы понял что разные источники - разные БД


С одной стороны программный продукт может работать как на MS SQL , так и на Oracle.
А я делаю интеграцию, которая должна работать в обоих случаях.
6 июл 17, 16:53    [20619954]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить