Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Генерализация SQL-диалектов / 10 сообщений из 10, страница 1 из 1
21.02.2004, 21:18
    #32417880
Генерализация SQL-диалектов
моя работа теперь станет состоять в построении хранилищ на данных разных заказчиков. специфика такая - во-первых, обычно у крупных заказчиков сами данные лежат в разных СУБД, во-вторых, на разных проектах - разные СУБД всегда.
то есть нужно некое общее знание, как извлекать данные из самых распространенных СУБД, без погружения в специфику - т.к. одному человеку глубоко и быстро изучить каждую СУБД на проекте нереально.

что посоветуете? книги, теория?
...
Рейтинг: 0 / 0
21.02.2004, 22:43
    #32417916
Odess
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Генерализация SQL-диалектов
Грамматика.
...
Рейтинг: 0 / 0
24.02.2004, 00:35
    #32418734
Lepsik
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Генерализация SQL-диалектов
ADO + ANSI SQL

но заплатишь перфомансем
...
Рейтинг: 0 / 0
26.02.2004, 20:56
    #32423405
Redbor
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Генерализация SQL-диалектов
To Умные Мысли: попробуй пообщаться с ASCRUSом насчёт его конвертера. Писал он софтину для перевода БД с MSSQL'я на Sybase ASA. Получилось, я скажу, весьма не слабо, видел собственными глазами. Может он тебе чего дельного и подскажет.
...
Рейтинг: 0 / 0
27.02.2004, 07:54
    #32423556
ASCRUS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Генерализация SQL-диалектов
Redbor
У человека не стоит задача миграции проекта с одной СУБД на другую, так что мой опыт в этом деле ему ничем не поможет :)

Умные Мысли
Получить любые данные легко с любой СУБД посредством SQL, но .... если Вы знаете, где они лежат и как их правильно брать. Лично я могу порекомендовать начать копать не только в сторону книг и теорий по принципам построения хранилищ данных (рекомедую кстати обратить внимание на OLAP-технологии), но и в сторону изучения самих БД, с которыми Вы будете работать и, если это возможно, желательно пообщаться с их создателями. В общем систематизируйте все БД и используемые СУБД, а потом уже можно будет думать, как элегантно и красиво с них тащить данные.
...
Рейтинг: 0 / 0
01.03.2004, 17:06
    #32426783
Jimmy
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Генерализация SQL-диалектов
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 килотонн зелени).

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

---------------
Данное сообщение содержит вирус!
...
Рейтинг: 0 / 0
01.03.2004, 17:23
    #32426831
1024
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Генерализация SQL-диалектов
А этих самых СУБД не так уж и много. И отклонений от стандарта ANSI SQL конечное количество. Т.е. ничего сложного нет покопаться немного в справочной системе конкретного сервера и всё выяснить. Есть непреодолимые выверты вроде отсутствия drop column, это по ходу дела можно выяснить.

Главная проблема вероятно не в диалекте сервера а в самих используемых системах. Как правило это нечто написанное чудо-разработчиками без всякой документации и через одно место. Вот в них разобраться обычно трудно. И никакие средства кроме тупого копания в чужом коде тут скорей всего не помогут.
...
Рейтинг: 0 / 0
28.03.2004, 23:14
    #32459943
Константин Лисянский
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Генерализация SQL-диалектов
2 Умные Мысли:

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

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


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



С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
29.03.2004, 13:17
    #32460554
Генерализация SQL-диалектов
Хотите сказать, в штате держать по спецу на каждый SQL-диалект и каждую учетную систему? :))
...
Рейтинг: 0 / 0
29.03.2004, 16:04
    #32460986
Константин Лисянский
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Генерализация SQL-диалектов
Я сказал всё, что хотел. Готов повториться - такие вещи в одиночку не делаются. А если делаются, то живут не долго и имеют низкое качество и примитивный функционал.
Что касается специалистов по диалектам - возможно, спасут инструменты, которые имеют коннекты к разным СУБД и умеют с ними общаться. Если вы для хранилища выберете одну платформу, то спецы понадобятся под неё, если хотите уметь на разных платформах работать, то нужны будут очень квалифицированные спецы, поскольку хранилища данных характеризуются большими объёмами, а борьба с ними у разных СУБД ведётся по-своему.
Что касается разных учётных систем, то без специалистов по ним вам не обойтись, надо будет либо использовать специалистов заказчика (которые всегда сильно загружены текучкой), либо специалистами, которые эти учётные системы разрабатывают или внедряют, либо изучать эти системы (что, всё равно без помощи разработчиков очень трудно делать).
Кстати, кроме извлечения данных из учётных систем и других источников, существуют такие работы, как проведение предпроектного обследования, управление проектом, проектирование структур данных, проектирование архитектуры системы, разработка аналитических приложений, обучение конечных пользователей, техническая поддержка. Вы всё это тоже в одиночку собираетесь делать?

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


С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Генерализация SQL-диалектов / 10 сообщений из 10, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]