Создание альтернативных структур данных с помощью многозначных массивов
Я программирую с PICK уже несколько месяцев и все еще приспосабливаюсь к размышлениям о программных решениях, которые используют исключительно многозначные массивы. PICK изначально не предлагает никаких других структур данных ни для операций с базой данных, ни для операций в памяти * (игнорируя размерные массивы ради аргумента, поскольку они все еще являются типом "массива")
Какие творческие способы имитировать другие структуры данных? Я могу представить способы реализации хэша / словаря или связанного списка с использованием массивов и подпрограмм для управления ими. Проблема здесь заключается в том, что это очень быстро усложняется, поскольку интерфейс для структуры данных не может быть концептуально упрощен как объект.
Есть ли какие-нибудь простые в реализации алгоритмы, которые люди использовали для создания уникальных структур данных?
Моя система: я пишу подпрограммы в PICK для дополнений к Eclipse Epicor, который находится на вершине UniVerse. Я знаю, что есть интерфейс C# для UniVerse, но они не подходят для большинства моих работ.
2 ответа
СУБД Pick/MultiValue позволяет хранить несколько значений в одном поле.
Типичным примером может служить наличие одного атрибута для адреса улицы, с улицами Street1, Street2 и, возможно, Street3. Структура будет выглядеть следующим образом: 01 Название компании 02 Улица1] Улица2] Улица3 03 Город 04 Штат...
Это поля одного типа, но они не относятся ни к чему другому. Другая похожая структура будет иметь несколько атрибутов, где значения коррелируются. Обычно имеется один управляющий атрибут и любое количество зависимых атрибутов (atb 26 используется в качестве случайного примера):
26 ShipDate]ShipDate]ShipDate
27 ShipQty]ShipQty]ShipQty
28 ShipVia]ShipVia]ShipVia
Прикладная программа управляет RI, а не базой данных, хотя можно использовать триггеры, чтобы позволить базе данных принудительно применять RI.
Разработчик СУБД может предпочесть не использовать эту структуру, поэтому мы можем использовать традиционные внешние ключи для связанных данных. В этом случае мы можем увидеть один атрибут с ключами для записей в файле доставки:
26 1234*01]1234*02]1234*03
Таким образом, каждое из этих значений является ключом к другому файлу. Значение *00 - это поддерживаемый приложением последовательный числовой идентификатор для каждой доставки. Они могут использоваться здесь в случае, если одна из доставок будет позже помечена как неподтвержденная, поэтому значение можно удалить, оставив следующее:
26 1234*02]1234*03
Обычные платформы MVDBMS предоставляют еще один уровень для SubValues. Они используются с оговоркой, но они могут быть весьма ценными. Рассмотрим приведенные выше данные доставки в одном атрибуте:
26 ShipDate\ShipQty\ShipVia ] ShipDate\ShipQty\ShipVia
ShipVia из второй партии будет указываться в коде как Item<26,2,3>,
Некоторые разработчики предпочитают использовать несистемные разделители. Все действительно, если оно не будет найдено в данных. Обычно вы видите звездочку, косую черту, пробел, запятую или другие буквенно-цифровые символы:
26 ShipDate|ShipQty|ShipVia ] ShipDate|ShipQty|ShipVia
Код для получения второго ShipVia может быть:
Field( Item<26,2> , "|" , 3 )
Это поле ShipVia само по себе может быть внешним ключом для файла таблицы, в котором есть только идентификатор ключа и ShipperName в atb1. Итак, мы говорим о той же структуре данных, которая используется для двух типов файлов: транзакционные данные и в основном статические таблицы. Это ничем не отличается от реляционной базы данных.
Да, вы можете создавать связанные списки, где, например, запись компании имеет один атрибут для отделов. Это переводится в файл департаментов, где есть атрибут для менеджеров. Это преобразуется в файл Employees, в котором для членов Команды выделен атрибут. Каждый из этих идентификаторов будет также переводиться на сотрудников, где некоторые из этих сотрудников также могут быть менеджерами со своими собственными командами. Эта структура используется для ведомости материалов, для компаний, занимающихся многоуровневым маркетингом, где физические лица имеют нижестоящие позиции, или для страхования, когда риск разбивается на несколько компаний, каждая из которых затем дополнительно разбивает риск.
Таким образом, есть много универсальности для структур. Все, что вы можете сделать с RDBMS или структурой Key/Value, может быть сделано с MV.
Насколько близко этот ответ соответствует вашему вопросу? А какой другой пример вы хотели бы увидеть?
Что касается объектов, то в QM MVDBMS есть OO BASIC, а СУБД Caché включает в себя реализацию MVDBMS, в которой данные MV могут быть представлены как объекты. Кроме того, с помощью mv.NET и других инструментов мы можем генерировать строго типизированные классы из определений словаря (схемы), которые допускают точно такой же тип ORM, что и для любой реляционной платформы.
Мне нужно знать больше о том, что вы пытаетесь сделать, но есть и другие типы данных.
Если вы хотите использовать другие языки с другими структурами данных, обратитесь к U2 Common Clients.
Тем не менее, если вы хотите заняться разработкой на стороне сервера в UniVerse, перейдите на веб-сайт Rocket Software и получите руководство "Базовые расширения Rocket UniVerse": Глава 10. Объект U2 Dyanmic Глава 8. Перенос данных между документами XML и файлами UniVerse.
Вы также можете обратиться к "Руководству по RoCI UniVerse GCI". "Общий интерфейс вызова (GCI) действует как шлюз от UniVerse BASIC к внешней подпрограмме. GCI передает данные в подпрограммы и из подпрограмм через аргументы и массивы".
http://docs.rocketsoftware.com/nxt/gateway.dll?f=templates$ fn = default.htm
Наконец, пока он еще находится в бета-версии, то, что может вас заинтересовать, - это использование Python для разработки MultiValue вместе с BASIC. Я представил это на собрании CMUG (группа пользователей Colorado MultiValue) еще в октябре.
Майк Райковски
Rocket Software