Инструменты GUI и API для небольших / средних иерархических структур данных - PullRequest
0 голосов
/ 23 июня 2010

Я пытаюсь найти инструмент и библиотеку для редактирования, записи и чтения данных в иерархической структуре, похожей на дерево LDAP, реестр Windows или структуру БД Berkeley. Ключи должны представлять некоторую иерархию, а значения должны иметь относительно гибкий формат (ввод необязателен, но может быть полезен). Вот пример:

Items/item_1/shape = "rectangle"
Items/item_1/top = 10
Items/item_1/left = 10
Items/item_1/width = 30
Items/item_1/height = 40

Items/item_2/shape = "square"
Items/item_2/top = 10
Items/item_2/left = 10
Items/item_2/width = 30

Items/item_3/shape = "circle"
Items/item_3/centre_x = 40
Items/item_3/centre_y = 50
Items/item_3/radius = 20
Items/item_3/colour = blue

Вариант использования:

  1. Редактирование хранилища данных через удобный графический интерфейс. Это может выглядеть как Windows Regedit или Apache Directory Studio (браузер LDAP) .

  2. Сохраните эти данные в каком-то хранилище (например, в файле).

  3. Загрузить этот магазин из другого приложения, которое сможет запрашивать это из API. Библиотека для этого в идеале должна вызываться из Python.

Мне бы хотелось, чтобы эти операции были достаточно быстрыми для чтения, но не загружали их заранее в память. Хранилище данных будет обновляться в приложении более или менее вручную, гораздо реже, чем данные читаются. Возможность записи в эти данные из API была бы плюсом, но это не является строгим требованием.

Запросы были бы хорошими. Например, (в псевдопросмотре) «List Items / *, где top == 10» вернет:

  • товары / Item_1
  • товары / item_2

Простота редактирования (через хороший графический интерфейс) - одна из самых важных функций.

Я рассмотрел несколько вариантов:

  1. Сервер LDAP отвечает большинству требований (особенно с помощью Apache Directory Studio). Однако развертывание сервера LDAP только для этого слишком тяжело. Как бы ни был хорош Apache Directory Studio, пользователю все еще нужно разумное понимание LDAP (больше, чем просто объяснение иерархии дерева). Я также хотел бы иметь некоторую гибкость в создании схем (или вообще никаких схем) вместо того, чтобы полагаться на администратора, чтобы сделать это.

  2. Windows Regedit . Я не уверен, возможно ли это, но я предполагаю, что возможно иметь подобный реестру файл, который не имеет никакого отношения к фактическому реестру Windows, редактируемый с пользовательским контентом через Regedit. Однако мне бы хотелось, чтобы это приложение с графическим интерфейсом было доступно на платформах, отличных от Windows, и я даже не уверен, что есть Python API для чтения файла реестра Windows.

  3. РДФ . Это может сработать. Я уверен, что есть довольно хорошие библиотеки Python для семантической сети. Тем не менее, мне не нужны никакие рассуждения. Я предпочел бы иметь что-то быстрое, и это не использует много памяти. Я не уверен, что есть какие-либо хорошие инструменты с графическим интерфейсом для просмотра и редактирования дерева (поскольку оно ориентировано на веб-сайты и графики).

Конечно, есть способы построения такого рода структур данных поверх существующих систем, таких как SQLite (например), и это было бы неплохо, но я не уверен, есть ли хороший графический интерфейс, который будет с ним. *

Буду признателен за комментарии и предложения, спасибо.

1 Ответ

0 голосов
/ 23 июня 2010

Простите за мою плотность, но если ваша иерархия не является самым грубым примером, должны быть чрезвычайно убедительные, непреодолимые причины для вашего выбора, скажем, JSON или даже (глоток!) XML:

<items>
  <item>
   <number>1</number>
   <shape>rectangle</shape>
   <top>10</top>
   <left>10</left>
   <width>30</width>
   <height>40</height>
  </item>
  <item>
   <number>2</number>
   <shape>triangle</shape>
   <top>20</top>
   <left>50</left>
   <width>30></width>
   <height>40</height>
  </item>
</items>

Что касается XML, вы знаете, что существует множество редакторов, которые отвечают вашим потребностям. То же самое с JSON. И я думаю, что есть также XML-> MySQL-> XML-библиотеки.

Почему бы не принять такой подход?

...