Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Генерализация SQL-диалектов
|
|||
|---|---|---|---|
|
#18+
моя работа теперь станет состоять в построении хранилищ на данных разных заказчиков. специфика такая - во-первых, обычно у крупных заказчиков сами данные лежат в разных СУБД, во-вторых, на разных проектах - разные СУБД всегда. то есть нужно некое общее знание, как извлекать данные из самых распространенных СУБД, без погружения в специфику - т.к. одному человеку глубоко и быстро изучить каждую СУБД на проекте нереально. что посоветуете? книги, теория? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2004, 21:18 |
|
||
|
Генерализация SQL-диалектов
|
|||
|---|---|---|---|
|
#18+
Грамматика. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2004, 22:43 |
|
||
|
Генерализация SQL-диалектов
|
|||
|---|---|---|---|
|
#18+
ADO + ANSI SQL но заплатишь перфомансем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.02.2004, 00:35 |
|
||
|
Генерализация SQL-диалектов
|
|||
|---|---|---|---|
|
#18+
To Умные Мысли: попробуй пообщаться с ASCRUSом насчёт его конвертера. Писал он софтину для перевода БД с MSSQL'я на Sybase ASA. Получилось, я скажу, весьма не слабо, видел собственными глазами. Может он тебе чего дельного и подскажет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2004, 20:56 |
|
||
|
Генерализация SQL-диалектов
|
|||
|---|---|---|---|
|
#18+
Redbor У человека не стоит задача миграции проекта с одной СУБД на другую, так что мой опыт в этом деле ему ничем не поможет :) Умные Мысли Получить любые данные легко с любой СУБД посредством SQL, но .... если Вы знаете, где они лежат и как их правильно брать. Лично я могу порекомендовать начать копать не только в сторону книг и теорий по принципам построения хранилищ данных (рекомедую кстати обратить внимание на OLAP-технологии), но и в сторону изучения самих БД, с которыми Вы будете работать и, если это возможно, желательно пообщаться с их создателями. В общем систематизируйте все БД и используемые СУБД, а потом уже можно будет думать, как элегантно и красиво с них тащить данные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2004, 07:54 |
|
||
|
Генерализация SQL-диалектов
|
|||
|---|---|---|---|
|
#18+
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 килотонн зелени). ЗЫ А в общем - все равно под каждого заказчика (проект) придется "прогибаться", вопрос только в том, насколько легко это можно сделать. --------------- Данное сообщение содержит вирус! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2004, 17:06 |
|
||
|
Генерализация SQL-диалектов
|
|||
|---|---|---|---|
|
#18+
А этих самых СУБД не так уж и много. И отклонений от стандарта ANSI SQL конечное количество. Т.е. ничего сложного нет покопаться немного в справочной системе конкретного сервера и всё выяснить. Есть непреодолимые выверты вроде отсутствия drop column, это по ходу дела можно выяснить. Главная проблема вероятно не в диалекте сервера а в самих используемых системах. Как правило это нечто написанное чудо-разработчиками без всякой документации и через одно место. Вот в них разобраться обычно трудно. И никакие средства кроме тупого копания в чужом коде тут скорей всего не помогут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2004, 17:23 |
|
||
|
Генерализация SQL-диалектов
|
|||
|---|---|---|---|
|
#18+
2 Умные Мысли: то есть нужно некое общее знание, как извлекать данные из самых распространенных СУБД, без погружения в специфику - т.к. одному человеку глубоко и быстро изучить каждую СУБД на проекте нереально что посоветуете? книги, теория? Посоветую расширить команду, так как такие вещи в одиночку не делаются. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2004, 23:14 |
|
||
|
Генерализация SQL-диалектов
|
|||
|---|---|---|---|
|
#18+
Хотите сказать, в штате держать по спецу на каждый SQL-диалект и каждую учетную систему? :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2004, 13:17 |
|
||
|
Генерализация SQL-диалектов
|
|||
|---|---|---|---|
|
#18+
Я сказал всё, что хотел. Готов повториться - такие вещи в одиночку не делаются. А если делаются, то живут не долго и имеют низкое качество и примитивный функционал. Что касается специалистов по диалектам - возможно, спасут инструменты, которые имеют коннекты к разным СУБД и умеют с ними общаться. Если вы для хранилища выберете одну платформу, то спецы понадобятся под неё, если хотите уметь на разных платформах работать, то нужны будут очень квалифицированные спецы, поскольку хранилища данных характеризуются большими объёмами, а борьба с ними у разных СУБД ведётся по-своему. Что касается разных учётных систем, то без специалистов по ним вам не обойтись, надо будет либо использовать специалистов заказчика (которые всегда сильно загружены текучкой), либо специалистами, которые эти учётные системы разрабатывают или внедряют, либо изучать эти системы (что, всё равно без помощи разработчиков очень трудно делать). Кстати, кроме извлечения данных из учётных систем и других источников, существуют такие работы, как проведение предпроектного обследования, управление проектом, проектирование структур данных, проектирование архитектуры системы, разработка аналитических приложений, обучение конечных пользователей, техническая поддержка. Вы всё это тоже в одиночку собираетесь делать? Мой совет остаётся в силе :) С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2004, 16:04 |
|
||
|
|
start [/forum/topic.php?fid=35&fpage=51&tid=1554160]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
38ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 208ms |
| total: | 344ms |
| 0 / 0 |
