Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 CDC решение  [new]
akaipbay
Member

Откуда:
Сообщений: 109
Добрый день,

Подскажите есть ли у кого нибудь готовый механизм для CDC (пакеты, процедуры)?

Задача такая:

Есть таблица Source_Table (операционная) есть копия этой таблицы с доп инфой Interface_Table (для ETL) на которую смотрит ХД и забирает данные с некоторой периодичностью.

Как без тригеров, без специфичных CDC для БД, реализовать такой механизм загрузки между таблицами?
1 июн 18, 10:55    [21460135]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 30514
Блог
у Информатики, у Golden Gate есть - они читают лог и транслируют изменения
1 июн 18, 11:01    [21460178]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
George Nordic
Member

Откуда: Moscow
Сообщений: 1042
Oracle Streams еще живы? GG специалисты знакомые хвалили. Но что они, что informatica - не очень дешевые решения, так скажем.

С Уважением,
Георгий
1 июн 18, 11:10    [21460231]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
akaipbay
Member

Откуда:
Сообщений: 109
Критик,

ETL инструмента нету
1 июн 18, 11:47    [21460457]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5112
akaipbay
Подскажите есть ли у кого нибудь готовый механизм для CDC (пакеты, процедуры)?
...
без специфичных CDC для БД
у вас СУБД то какая?
опять же что конкретно хотите, внешний ETL тулл или "на уровне процедур в БД"?
1 июн 18, 11:48    [21460466]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
alexdr
Member

Откуда:
Сообщений: 215
Стесняюсь спросить, а что в Microsoft SSIS механизмы CDC изъяли? И вроде нормальное описалово как все это правильно готовить у майкрософта имелось. Оно вроде с дистрибутива сиквел-сервера ставилось, но отдельно... нет? Да, нет, вроде в моей Visual Studio присутствует такой CDC Control Task. Похоже, все-таки не изъяли.
1 июн 18, 12:18    [21460674]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
ShIgor
Member

Откуда: Нижний Новгород
Сообщений: 2114
akaipbay,

как вообще такое возможно без специфичных вещей для БД?
тупо: поле last_update и забирай сам когда посчитаешь нужным.

хотя по мне такое без триггера тоже как-то не по-себе, вдруг учетная система забудет в каком-то месте last_updat-нуть.
1 июн 18, 12:38    [21460793]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
akaipbay
Member

Откуда:
Сообщений: 109
Дедушка,

Да на уровне процедур и джобов, без ETL туллов

БД - Оракл но хотелось бы механизм универсальный который легко переделать и для других СУБД потому что источники разные.
1 июн 18, 13:29    [21461102]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
akaipbay
Member

Откуда:
Сообщений: 109
ShIgor,

А если last_update нет?) и тригеры нельзя использовать потому что все загнется

Есть таблицы которые имеют ласт_апдейт но есть и которые емют просто ключи и писать для каждой таблицы свой ЕТЛ не вариант так как таблиц хер его туча.

Пока в голову приходит мысль что нужно создать таблицу где хранится

Таблица_Откуда, Таблица_Куда, Колонка_для_CDC, Последнее_Значение

И написать одну процедуру которая берет и ложит.

Хер его знает, правильно не правильно, поэтому и спрашиваю
1 июн 18, 13:37    [21461147]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4833
Блог
akaipbay
Дедушка,

Да на уровне процедур и джобов, без ETL туллов

БД - Оракл но хотелось бы механизм универсальный который легко переделать и для других СУБД потому что источники разные.
Если нужен универсальный механизм без триггеров, то это нужно брать промышленный CDC. Например, GoldenGate (поддерживает Oracle, MySQL, MSSQL, DB2, Sybase, Cassandra)
1 июн 18, 14:42    [21461469]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
ShIgor
Member

Откуда: Нижний Новгород
Сообщений: 2114
akaipbay,

одной колонкой не обойдется.
надо знать: "где" изменилось и "что" изменилось (или просто что-то изменилось) + в идеале причина изменений (Ins/Upd/Del), ну и без "когда" тоже мало толку
теперь попробуйте написать свой собственный фреймворк для этого..

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

и еще раз повторю, без специфичных для БД вещей, шерстить источники и цели будете постоянно
1 июн 18, 15:32    [21461708]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
Sintetik
Member

Откуда: SpB->Msk->...
Сообщений: 9229
akaipbay
ShIgor,

А если last_update нет?) и тригеры нельзя использовать потому что все загнется

Есть таблицы которые имеют ласт_апдейт но есть и которые емют просто ключи и писать для каждой таблицы свой ЕТЛ не вариант так как таблиц хер его туча.

Пока в голову приходит мысль что нужно создать таблицу где хранится

Таблица_Откуда, Таблица_Куда, Колонка_для_CDC, Последнее_Значение

И написать одну процедуру которая берет и ложит.

Хер его знает, правильно не правильно, поэтому и спрашиваю

если будете хранить всю историю изменений, то нужно просто всасывать на ХД эту таблицу, применять изменения, в исходной ставить флаг, что забрали успешно
если истории нет, то попадалово, нужно тащить всю исходную таблицу на ХД и full outer, я встречал такие решения, причем на приличных объемах 500гиг в день, но тащили в ХД не с боя, а со стенбая. Ограничения те же, проприетарная система, менять ничего нельзя, журналирование включать нельзя, а без него CDC не работают.
1 июн 18, 16:29    [21461982]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
Гулин Федор
Member

Откуда: МИНСК
Сообщений: 960
akaipbay
ShIgor,

А если last_update нет?) и тригеры нельзя использовать потому что все загнется

Есть таблицы которые имеют ласт_апдейт но есть и которые емют просто ключи и писать для каждой таблицы свой ЕТЛ не вариант так как таблиц хер его туча.

Пока в голову приходит мысль что нужно создать таблицу где хранится

Таблица_Откуда, Таблица_Куда, Колонка_для_CDC, Последнее_Значение

И написать одну процедуру которая берет и ложит.

Хер его знает, правильно не правильно, поэтому и спрашиваю


делал чего-то похоже для Частного случая мс-скл - но таблиц там было 5-6
(и они были по 5-10 миллионов - не такие большие )

создал отдельную БД - в ут писать нелья было
в той БД создал синонимы

CREATE TABLE dlt_Problem (
    id              BIGINT        NOT NULL
	, [b]hash_record[/b] bigint  
	, dt_insert datetime default getdate() 
	, dt_lastupdate datetime 
	, dt_delete datetime 
	, flag_delete bit default 0
	CONSTRAINT PK_dlt_Problem PRIMARY KEY  ( id  )
);

CREATE PROCEDURE usp_dlt_Problem_LoadMark
		@What_do  int  = 1 -- @What_do = 1 Return Delta 
, @What_do = 2 Update Deleta file (Merge )


создал по процедуре для каждой таблицы -

hash_record через CHECKSUM всех (ну или набора ) полей в строку через CAST

геморно - но др.выбора не было

зы там есть ид инкрементное - если бы не было апдейтов - было бы проще - хватило бы одной спец. таблицы
но апдейты И делете есть и а даты посл. изменний увы нет


и вызывал их в пакете SSIS - 1 пакет для 1 таблицы

зы если бы была куча таблиц - не знаю стал бы юзать сей подход
4 июн 18, 13:18    [21466294]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
akaipbay
Member

Откуда:
Сообщений: 109
Alexander Ryndin,

Конечно это в идеале, но руководство бичует и загрызет за каждую копейку)
6 июн 18, 06:48    [21471488]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
akaipbay
Member

Откуда:
Сообщений: 109
ShIgor,

Да согласен, тут один мужик посоветовал включить матвью логи на таблицу источник а потом копаться в этих логах и фиксировать изменения, но боюсь что на нон-оракл базы это не прокатит
6 июн 18, 06:52    [21471489]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
akaipbay
Member

Откуда:
Сообщений: 109
Sintetik,

как раз истории и нету) а можете привести пример с этим full outer, а то уж совсем время поджимает?
6 июн 18, 06:56    [21471493]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
akaipbay
Member

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

Блин чето геморно, у меня таблиц хер его туча(
6 июн 18, 06:57    [21471494]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
Полковник.
Member

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

Блин чето геморно, у меня таблиц хер его туча(


Пиши робота, который на основе метаданных, таблицы метаданных я надеюсь у тебя есть в ХД, будет генерить тебе динамический код, запусти в цикле в будет тебе счастье.
6 июн 18, 09:45    [21471724]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 2533
Полковник.
akaipbay
Гулин Федор,

Блин чето геморно, у меня таблиц хер его туча(


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

Вот эта вся автоматизация приведет к тому, что потом программистов, которые ETL делают вручную, смотрят таблицы, отбирают нужные столбцы и пишут код, сократят, наберут студентов, потом что-нибудь сломается, никто не будет понимать, как этот динамический код починить, а сроки внедрения будут поджимать, а клиенты таки очень переживать и грозить штрафами.

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

В общем, коллеги, вы сами себе пилите сук, на котором сидите. Когда вы говорите заказчикам ХД - "сейчас робот пробежит и все сам сделает", возникает вопрос - а зачем вам столько денег платить, когда достаточно взять студента, умеющего запускать такого робота.
6 июн 18, 12:20    [21472253]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 2533
akaipbay
Подскажите есть ли у кого нибудь готовый механизм для CDC (пакеты, процедуры)?

Наверняка у кого-то есть. Наверняка у многих. И наверняка эти люди - высококвалифицированные - не очень хотят, чтобы заготовки, которые ИМ облегчают жизнь, попали в руки людей, которые мечтают сократить им зарплату и премии и повысить конкуренцию в их среде. Все в этом мире IT в конечном итоге упирается в деньги. Вот такой циничный расклад.
6 июн 18, 12:22    [21472257]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
kaldorey
Member

Откуда:
Сообщений: 567
Andy_OLAP,

Самое интересное, что при реализации такого механизма можно начинать решать более интересные задачи. На прошлой работе такой механизм делали на пентахе - там надо было только понимать, каким способом таблицу забирать, full, increment - могут ли быть удаления строк, указываешь все это - и автоматом создавалось, грузилось и обновлялось. С удалением строк все похуже, приходилось выяснять, какой давности строки могут быть удалены, и перезагружать раз в период данные.
А прикол в том, что даже для внедрения GG придется кучу работы проводить, кроме интеграции надо каждую таблицу под требования подводить. Для немасштабных задач проще согласовать, чтобы поле для инкремента появилось, раз так и так работы проводить
27 июл 18, 12:01    [21607591]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4833
Блог
kaldorey
Andy_OLAP,

Самое интересное, что при реализации такого механизма можно начинать решать более интересные задачи. На прошлой работе такой механизм делали на пентахе - там надо было только понимать, каким способом таблицу забирать, full, increment - могут ли быть удаления строк, указываешь все это - и автоматом создавалось, грузилось и обновлялось. С удалением строк все похуже, приходилось выяснять, какой давности строки могут быть удалены, и перезагружать раз в период данные.
А прикол в том, что даже для внедрения GG придется кучу работы проводить, кроме интеграции надо каждую таблицу под требования подводить. Для немасштабных задач проще согласовать, чтобы поле для инкремента появилось, раз так и так работы проводить
Эм... А что для GG делать то надо?
27 июл 18, 13:01    [21607973]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
kaldorey
Member

Откуда:
Сообщений: 567
Alexander Ryndin,

Например, чтобы на каждой реплицируемой таблице был PK - это конечно и так желательно, но часто бывает, что и не подозреваешь, на скольки таблицах этого таки нет. Почему бы заодно и инкрементное поле не навесить?
Также при установке на продуктив надо быть уверенными, что места для хранения файлов хватит и они правильно удаляются по завершении timelive и сервер не навернется в один момент.
А еще, если вдруг захочешь таблицу с историчностью сохранять, а не полную реплику делать, то надо будет думать над схлопыванием изменений строки в рамках одной транзакции, когда несколько изменений под одним scn проходят.
Но опыт был единичный, не исключено, что все гораздо легче, или после пары лет порог вхождения снизился.
Резюмируя, делаю вывод, что копирнуть и обновлять табличку, используя простые запросы, что важно при большом разнообразии источников, гораздо быстрее и легче, GG же стоит юзать, когда есть критичность в производительности системы источника, пропускной способности и необходимости realtime
27 июл 18, 13:37    [21608212]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4833
Блог
kaldorey
Alexander Ryndin,

Например, чтобы на каждой реплицируемой таблице был PK - это конечно и так желательно, но часто бывает, что и не подозреваешь, на скольки таблицах этого таки нет. Почему бы заодно и инкрементное поле не навесить?
Также при установке на продуктив надо быть уверенными, что места для хранения файлов хватит и они правильно удаляются по завершении timelive и сервер не навернется в один момент.
А еще, если вдруг захочешь таблицу с историчностью сохранять, а не полную реплику делать, то надо будет думать над схлопыванием изменений строки в рамках одной транзакции, когда несколько изменений под одним scn проходят.
Но опыт был единичный, не исключено, что все гораздо легче, или после пары лет порог вхождения снизился.
Резюмируя, делаю вывод, что копирнуть и обновлять табличку, используя простые запросы, что важно при большом разнообразии источников, гораздо быстрее и легче, GG же стоит юзать, когда есть критичность в производительности системы источника, пропускной способности и необходимости realtime
1) Можно и без PK. Особенно, если вам нужна просто история.
2) Файлы можно не приземлять на проде. Сразу настраиваете передачу в RMTTRAIL. Следить за их удалением может сам GG
3) Изменения схлопывать в рамках одной транзакции... Да, наверное. Но зато вы получаете полную историю. А как сделать полную историю (да и вообще историю) без парсинга логов? Триггеры вешать, которые всю строку откладывают в соседнюю таблицу? Это жестко.

По поводу того, где использовать GG... ну да, его нужно использовать в этих кейсах
27 июл 18, 15:30    [21608803]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
Полковник.
Member

Откуда:
Сообщений: 1742
Andy_OLAP
Полковник.
пропущено...


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

Вот эта вся автоматизация приведет к тому, что потом программистов, которые ETL делают вручную, смотрят таблицы, отбирают нужные столбцы и пишут код, сократят, наберут студентов, потом что-нибудь сломается, никто не будет понимать, как этот динамический код починить, а сроки внедрения будут поджимать, а клиенты таки очень переживать и грозить штрафами.

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

В общем, коллеги, вы сами себе пилите сук, на котором сидите. Когда вы говорите заказчикам ХД - "сейчас робот пробежит и все сам сделает", возникает вопрос - а зачем вам столько денег платить, когда достаточно взять студента, умеющего запускать такого робота.


Знаешь чем отличается инженер от работяги? Инженер сначала строит экскаватор а потом копает им яму за час, а работяга берет лопату и сразу начинает копать и копает ее два месяца. Что лучше?

Когда в ХД пара тысяч таблиц а не пара таблиц, то только робот спасет положение, если ты будешь лепить пару тысяч трансформаций то сколько же в них будет человеческого фактора, сколько это отлаживать нужно?
28 июл 18, 09:22    [21610052]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 2533
Полковник.
Andy_OLAP
пропущено...

Вот эта вся автоматизация приведет к тому, что потом программистов, которые ETL делают вручную, смотрят таблицы, отбирают нужные столбцы и пишут код, сократят, наберут студентов, потом что-нибудь сломается, никто не будет понимать, как этот динамический код починить, а сроки внедрения будут поджимать, а клиенты таки очень переживать и грозить штрафами.

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

В общем, коллеги, вы сами себе пилите сук, на котором сидите. Когда вы говорите заказчикам ХД - "сейчас робот пробежит и все сам сделает", возникает вопрос - а зачем вам столько денег платить, когда достаточно взять студента, умеющего запускать такого робота.


Знаешь чем отличается инженер от работяги? Инженер сначала строит экскаватор а потом копает им яму за час, а работяга берет лопату и сразу начинает копать и копает ее два месяца. Что лучше?

Когда в ХД пара тысяч таблиц а не пара таблиц, то только робот спасет положение, если ты будешь лепить пару тысяч трансформаций то сколько же в них будет человеческого фактора, сколько это отлаживать нужно?

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

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

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

И вот инженер получает немножко денег и создает экскватор. Его можно потрогать, он стоит на краю траншеи, выглядит грозно. Одним словом, ВЕЩЬ. Сразу видно, что стоит недешево и полезная в хозяйстве.


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

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

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

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

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

И вот получается, что такие майоры из самых лучших побуждений наносят моральный ущерб своим собратьям по цеху. Ну это так, просто мысли вслух, без обид и перехода на личности....
29 июл 18, 23:41    [21612756]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
kaldorey
Member

Откуда:
Сообщений: 567
Andy_OLAP,

Пример с проводами нисколько не противоречит сказанному Полковником.
К тому же все мы знаем, как умеют наматывать на ковш уже проведенные под землей провода :)
Если бы все держались за хлебное место и не пытались ускорить, автоматизировать и удешевить работу, люди до сих пор ездили бы проведать дочку в соседнее королевство примерно по два года туда-обратно.
30 июл 18, 12:32    [21614139]     Ответить | Цитировать Сообщить модератору
 Re: CDC решение  [new]
.Евгений
Member

Откуда:
Сообщений: 366
Роботы-экскаваторы, разработка через документирование и т.п. подходы к ETL имеют, наряду с очевидными плюсами, и недостатки.
Во-первых, это усилия на освоение экскаватора. Они привязывают к местам использования экскаватора, а после перехода на бульдозер забываются и пропадают. Мне кажется, что специализация на каком-то средстве ETL (SSIS, IPC, TOS и т.п.) может себя оправдывать, а на конкретном роботе-экскаваторе - слишком узка.
Во-вторых, это неизбежная потери в эффективности. Любой робот заведомо более ограничен в средствах и методах, чем продукт, на котором он реализован. Когда в руках молоток, любую проблему поневоле видят гвоздем. Несколько нестандартных проблем - и вот экскаваторщик вынужден стать слаломистом.
30 июл 18, 15:08    [21615109]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / OLAP и DWH Ответить