Библиотека для чтения данных Rocket U2
Мы пытаемся перенести данные из базы данных Rocket U2 на сервер SQL. Согласно тому, что я читал в Википедии, данные хранятся в виде текстовых файлов с разделителями.
Мы рассматриваем следующие альтернативы:
- Приобретите инструментарий Rocket U2
- Разбираем текстовые файлы сами
- Импортируйте текстовые файлы в Excel
- Положитесь на библиотеки 3-й части
Насколько осуществим каждый из перечисленных вариантов? Есть ли другие альтернативы, которые мы могли бы рассмотреть?
3 ответа
Файлы представляют собой хешированные таблицы, а не текстовые файлы с разделителями. У вас установлена база данных Rocket или только сами файлы данных? Существует множество способов извлечения данных из файлов Rocket U2, но вам необходимо понимать структуру данных, которая является многозначной. Вы можете получить их быстрее, наняв кого-то, кто знаком с окружающей средой. В LinkedIn есть группа пользователей MultiValue и группа пользователей U2.
Помимо этого, я бы предложил использовать инструмент Rocket U2 Toolkit for .NET как способ доступа к данным с точки зрения Microsoft. Вот ссылка на общую информацию: http://www.rocketsoftware.com/products/rocket-u2-toolkit-net
Также поищите здесь в Stackru тег u2netdk.
Наша команда создала процесс, который выполняет следующие действия из приложения.net:
Создание моделей (структур данных) из схем unidata, включая моделирование многозначных и подчиненных многозначных значений из ассоциаций.
Используйте эти модели для создания базы данных sql server.
Используйте эти модели для создания HTML-документации.
Используйте команду LIST для извлечения данных в файлы из нашей базы данных unidata.
Выполните Rsync, чтобы переместить файлы данных с сервера Unix на наш сервер Windows.
Чтение из файлов, усечение любых существующих данных SQL и использование моделей для выполнения массовых вставок SQL.
Мы используем этот процесс для ежедневных миграций, поэтому шаги 2 и 3 действительно выполняются только один раз (или всякий раз, когда мы добавляем новый файл).
Нашей команде понадобилось несколько месяцев, чтобы полностью автоматизировать и сделать все правильно. Наши основные проблемы были связаны с тем, что у нас не было знаний об униданных или многозначных базах данных. Большая часть сложности заключалась в анализе многозначных и вложенных многозначностей файла данных. Понимание ассоциаций и правильное их устранение заняли у нас много времени.
Наше окончательное решение получилось довольно приятным и чрезвычайно быстрым. В настоящее время мы переносим более двух с половиной гигабайт данных каждый день из более чем 57 файлов unidata менее чем за 2 часа.
Так что я говорю, что это возможно, но это довольно большие инвестиции, если вы, ребята, не обладаете большим знанием, чем мы (что было бы очень возможно). Похоже, вы ищете одноразовый порт, а не ночные миграции, поэтому я, вероятно, рекомендую то же самое, что и @jbmonco, и просто использую набор инструментов.net, который предлагает Rocket.
Мы подключаем UniVerse как связанный сервер на SQL Server с помощью UniVerse ODBC, который включен в лицензию UniVerse. Для получения всех данных в каждой таблице требуется довольно значительная настройка словарей UniVerse.
Общие записи DICT UniVerse (F1, F2, F3 и т. д.) недоступны для UniVerseSQL. Любые данные, подлежащие чтению, должны иметь запись в DICT файла. Для ODBC важно иметь запись @SELECT для перечисления элементов DICT, которые будут доступны в ODBC, поскольку он использует команду SELECT * «за кулисами».
Таблицы не видны напрямую через ODBC, а доступ к данным осуществляется из SQL Server. Лучше всего обращаться к ним, создавая представления с помощью OPENQUERY. Соединение ODBC может обрабатывать таблицы только последовательно, по одной таблице за раз. Это ограничение несущественно для пары таблиц в запросе, но теряет силу, если объединено несколько таблиц. В этих случаях лучше всего записать данные во временные таблицы на SQL Server и запросить их.
Объединения на уровне ODBC с помощью команды OPENQUERY выполняются безнадежно медленно. Просто используйте OPENQUERY в запросе к отдельным таблицам (или используйте созданные вами табличные представления) и выполните соединения в SQL Server.
Самым большим ограничением является ограничение ODBC в 255 символов для всех полей, но это часто можно обойти с помощью I-дескрипторов, чтобы объединить несколько блоков по 255 символов в виде отдельных элементов словаря и снова объединить их в SQL Server.
UniVerseSQL поддерживает концепцию динамической нормализации, при которой многозначные значения прозрачно представляются в виде виртуальных связанных таблиц. Эти виртуальные таблицы доступны через ODBC. Очень удобно иметь многозначную базу данных UniVerse, представленную в SQL Server в нормализованной форме.
Подзначения могут поддерживаться с помощью I-дескрипторов, чтобы вывести каждое отдельное значение с помощью EXTRACT(). В качестве альтернативы можно перенести все многозначное значение со всеми разделенными подзначениями, а затем проанализировать его на SQL Server.
UniVerseSQL предназначен для работы с атрибутами значений в виде столбцов. Он не подходит для структур, в которых в записи имеется произвольное количество атрибутов. (Например, список выбора).
Я использовал LOWER() в I-дескрипторах для преобразования таких структур в один атрибут с несколькими значениями, но получил неоднозначные результаты. Прекрасно работает в UniVerseSQL, но не транслируется через ODBC, по-видимому, также каким-то образом из-за ограничения ODBC в 255 символов.
Собственный UniVerseSQL можно отправить на сервер UniVerse через ODBC. Это устраняет необходимость в записи @SELECT в DICT и позволяет использовать EVAL() для создания I-дескрипторов «на лету» без необходимости настройки словаря файла. Это особенно полезно для специального исследования данных в UniVerse из SQL Server. Это может быть полезно для пользователей, у которых нет терминального доступа к Universe, хотя им необходимо понимать синтаксис функций UniVerse, поддерживаемых в I-дескрипторах.
Собственные запросы также позволяют представлять таблицы, объединенные в UniVerse, в ODBC. Это работает намного лучше, чем объединения на уровне ODBC. Однако наилучшей производительности можно добиться, используя TRANS() в I-дескрипторах для манифестирования полей из связанной таблицы в основной таблице.
Важно понимать, что собственные запросы также позволяют выполнять UPDATE и INSERT в UniVerse, даже если связанный сервер настроен только для чтения. Убедитесь, что разрешения для файлов Universe настроены правильно, при необходимости используя расширенные ACL.
Обратите внимание, что UniVerseSQL не поддерживает команду DELETE для файловых таблиц.
При использовании UniverseSQL важно понимать, что синтаксис имеет некоторые существенные отличия от синтаксиса T-SQL. Абсолютно важно понимать разницу между ключевыми словами WHERE и WHEN, особенно перед попыткой ОБНОВЛЕНИЯ.
Функциональность будет весьма ограничена, пока разработчик не поймет синтаксис динамической нормализации.