Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 Генерализация SQL-диалектов  [new]
Умные Мысли
Guest
моя работа теперь станет состоять в построении хранилищ на данных разных заказчиков. специфика такая - во-первых, обычно у крупных заказчиков сами данные лежат в разных СУБД, во-вторых, на разных проектах - разные СУБД всегда.
то есть нужно некое общее знание, как извлекать данные из самых распространенных СУБД, без погружения в специфику - т.к. одному человеку глубоко и быстро изучить каждую СУБД на проекте нереально.

что посоветуете? книги, теория?
21 фев 04, 21:18    [546653]     Ответить | Цитировать Сообщить модератору
 Re: Генерализация SQL-диалектов  [new]
Odess
Member

Откуда: Одесса, Украина
Сообщений: 6091
Грамматика.
21 фев 04, 22:43    [546696]     Ответить | Цитировать Сообщить модератору
 Re: Генерализация SQL-диалектов  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
ADO + ANSI SQL

но заплатишь перфомансем
24 фев 04, 00:35    [547882]     Ответить | Цитировать Сообщить модератору
 Re: Генерализация SQL-диалектов  [new]
Redbor
Member

Откуда: Москва
Сообщений: 289
To Умные Мысли: попробуй пообщаться с ASCRUSом насчёт его конвертера. Писал он софтину для перевода БД с MSSQL'я на Sybase ASA. Получилось, я скажу, весьма не слабо, видел собственными глазами. Может он тебе чего дельного и подскажет.
26 фев 04, 20:56    [553581]     Ответить | Цитировать Сообщить модератору
 Re: Генерализация SQL-диалектов  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Redbor
У человека не стоит задача миграции проекта с одной СУБД на другую, так что мой опыт в этом деле ему ничем не поможет :)

Умные Мысли
Получить любые данные легко с любой СУБД посредством SQL, но .... если Вы знаете, где они лежат и как их правильно брать. Лично я могу порекомендовать начать копать не только в сторону книг и теорий по принципам построения хранилищ данных (рекомедую кстати обратить внимание на OLAP-технологии), но и в сторону изучения самих БД, с которыми Вы будете работать и, если это возможно, желательно пообщаться с их создателями. В общем систематизируйте все БД и используемые СУБД, а потом уже можно будет думать, как элегантно и красиво с них тащить данные.
27 фев 04, 07:54    [553767]     Ответить | Цитировать Сообщить модератору
 Re: Генерализация SQL-диалектов  [new]
Jimmy
Member

Откуда: г.Москва
Сообщений: 3136
2 ASCRUS

OLAP не имет ничего общего с вопросами миграции/трансформации данных. Если говорить просто, то OLAP - продвинутый построитель отчетов с поддержкой нерегламентированных запросов. Работает с теми структурами, которые ей подготовили проектировщики системы.

2 Умные Мысли
Я работаю в ПЦ Datagy компании Диасофт, который занимается именно построением ХД. Так вот, у нас есть технология создания ETL процессов, которая основана на поддержке стандартов SQL92. Поэтому, скажу исходя из реального опыта:

Почти все основные СУБД поддерживают (в той или иной мере) этот стандарт, так что 80% задач можно решить используя только SQL92.
Исключение - Oracle, который имеет свой собственный синтаксис для описания внешних соединений (OUTER JOIN).

Кроме того, массу вопросов, связанных с ETL процессами (загрузкой ХД), можно решить с помощью специальных программных средств:
-- DataStage от Asсencial Software
-- DT\Studio от Embarcadero
-- так же MS обещает, что DTS в Yukon (новая версия MS SQL Server) будет так же доведен до уровня ETL инструмента.
Все вышеперечисленное - достаточно мощный визуальный инструментарий, но и дорогой тоже (первые два зашкаливают за 50 килотонн зелени).

ЗЫ А в общем - все равно под каждого заказчика (проект) придется "прогибаться", вопрос только в том, насколько легко это можно сделать.

---------------
Данное сообщение содержит вирус!
1 мар 04, 17:06    [557905]     Ответить | Цитировать Сообщить модератору
 Re: Генерализация SQL-диалектов  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
А этих самых СУБД не так уж и много. И отклонений от стандарта ANSI SQL конечное количество. Т.е. ничего сложного нет покопаться немного в справочной системе конкретного сервера и всё выяснить. Есть непреодолимые выверты вроде отсутствия drop column, это по ходу дела можно выяснить.

Главная проблема вероятно не в диалекте сервера а в самих используемых системах. Как правило это нечто написанное чудо-разработчиками без всякой документации и через одно место. Вот в них разобраться обычно трудно. И никакие средства кроме тупого копания в чужом коде тут скорей всего не помогут.
1 мар 04, 17:23    [557962]     Ответить | Цитировать Сообщить модератору
 Re: Генерализация SQL-диалектов  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
2 Умные Мысли:

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

что посоветуете? книги, теория?


Посоветую расширить команду, так как такие вещи в одиночку не делаются.



С уважением,
Константин Лисянский
http://lissianski.narod.ru
28 мар 04, 23:14    [601065]     Ответить | Цитировать Сообщить модератору
 Re: Генерализация SQL-диалектов  [new]
Умные Мысли
Guest
Хотите сказать, в штате держать по спецу на каждый SQL-диалект и каждую учетную систему? :))
29 мар 04, 13:17    [601763]     Ответить | Цитировать Сообщить модератору
 Re: Генерализация SQL-диалектов  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Я сказал всё, что хотел. Готов повториться - такие вещи в одиночку не делаются. А если делаются, то живут не долго и имеют низкое качество и примитивный функционал.
Что касается специалистов по диалектам - возможно, спасут инструменты, которые имеют коннекты к разным СУБД и умеют с ними общаться. Если вы для хранилища выберете одну платформу, то спецы понадобятся под неё, если хотите уметь на разных платформах работать, то нужны будут очень квалифицированные спецы, поскольку хранилища данных характеризуются большими объёмами, а борьба с ними у разных СУБД ведётся по-своему.
Что касается разных учётных систем, то без специалистов по ним вам не обойтись, надо будет либо использовать специалистов заказчика (которые всегда сильно загружены текучкой), либо специалистами, которые эти учётные системы разрабатывают или внедряют, либо изучать эти системы (что, всё равно без помощи разработчиков очень трудно делать).
Кстати, кроме извлечения данных из учётных систем и других источников, существуют такие работы, как проведение предпроектного обследования, управление проектом, проектирование структур данных, проектирование архитектуры системы, разработка аналитических приложений, обучение конечных пользователей, техническая поддержка. Вы всё это тоже в одиночку собираетесь делать?

Мой совет остаётся в силе :)


С уважением,
Константин Лисянский
http://lissianski.narod.ru
29 мар 04, 16:04    [602262]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить