sqlite, xml или их комбинация?

Question

Я разрабатываю систему, которая позволяет искать в законодательстве соответствующие положения, и мне сложно найти лучший способ хранения данных. Вот критерии:

1. Соответствующее законодательство имеет древовидную структуру. Каждый Акт содержит Разделы, которые могут иметь Подразделы любой глубины (например, Акт 1: 2.1.a.c). Каждый раздел или подраздел на каждом уровне является отдельным предложением. Акты могут также содержать Правила, которые в основном являются приложениями и содержат аналогичный набор разделов и подразделов. Каждый акт и постановление имеют дату, когда они вступили в силу (не обязательно совпадают). Простой пример структуры:

   Act1: "Act controlling something" (2001)
       Section 1: This section relates to:
           a.     Something
           b.     These things too:
               1.    A long thing
               2.    A short thing
       Regulation 1: (12 Jan 2004)
           Section 5: This section relates to Section 1 of the main Act
               a.   This applies to everything short
               b.   This applies to everything long
       Regulation 2: (14 Feb 2008)
           Section 6: This section relates to Sections 1 and 2 of the main Act
               a.   This applies to all everything in the sections
               b.   This applies to something
   

2. Пункты и разделы связаны друг с другом на основе субъективных критериев, и отношения должны быть установлены вручную, но они могут применяться на любом уровне, например, Act1.Regulation1.Section5.a -> Act1.Section1.b.2 или Act1.Regulation2.Section6 -> Act1.Section1. Отношения не обязательно происходят в обоих направлениях.

3. Система должна иметь возможность запрашивать эти отношения, чтобы при поиске Act1.Section1 было обнаружено все, помеченное как относящееся к нему или любому из его подразделов, возможно, также ограниченное по дате.

4. Система должна находиться в автономной среде, поэтому файловая, а не серверная.

5. Данные будут доступны только для чтения пользователям.

Интерфейс и поисковая система довольно просты, и, тем не менее, я храню данные, которые, вероятно, реализую, используя python.

Поскольку серверная часть должна быть основана на файлах, я предполагаю, что sqlite будет самой простой базой данных для использования. Тем не менее, я не совсем уверен, что XML не лучший способ сделать это. Единственное, что меня беспокоит, это то, что при необходимости базу данных будет легче интегрировать с другими системами позже. Я мог бы также объединить их, используя xml для хранения всего законодательства и таблицу sqlite, содержащую все ссылки.

Вкратце, вот мой вопрос: Какая структура хранения была бы наиболее подходящей для данных этого типа?

Answer 1

Я бы выбрал вариант "комбинации", как вы предложили.

• сохранить фактическое содержимое в XML
• сохранить отношения как пары (абсолютных) XPath в базе данных, например ['/Act1/Regulation1/Section5/a', '/Act1/Section1/b/2']; ['/Act1/Regulation1/Section5/a', '/Act1/Regulation2/Section6'] (это 2 строки по 2 столбца в каждой, первый столбец не уникален, пары уникальны)
• сохранить обратное отношение в отдельной таблице с той же структурой (для обратного просмотра): ['/Act1/Section1/b/2', '/Act1/Regulation1/Section5/a']; ['/Act1/Regulation2/Section6', '/Act1/Regulation1/Section5/a'] (те же ограничения уникальности, что и выше)

Если вы хотите выполнить частичный поиск а-ля "Покажите мне, если /Act1/Regulation2 упоминается как /Act1/Regulation1", вы можете добавить косвенное указание к кросс-таблицам (показано ниже), или если вам нужна чрезвычайная производительность (что я не думаю, что вы делаете, потому что, вероятно, не так много данных (менее 100 миллионов отношений)) вы можете использовать три исправления (как в префиксе и суффиксе)

relation_table (id, id):
[set_112, set119]
[set_112, set120]

set_table (id, prefix, is_full_path):
[set_112, '/Act1', false]
[set_112, '/Act1/Regulation1', false]
[set_112, '/Act1/Regulation1/Section5', true]
...

Это набор всех префиксов (и / или суффиксов) XPath. Ответ на запрос выше будет тогда:

• SELECT set_id FROM set_table WHERE prefix = FOO
• SELECT second_colum FROM relation_table WHERE first_column IN (set_112, ...) (т.е. результат предыдущего запроса)
• SELECT prefix FROM set_table WHERE set_id = RESULT_FROM_PREVIOUS AND is_full_path=true

Простите, если я не воспроизвел ваши примерные отношения прямо в моих примерах.

Редактировать: В зависимости от ваших потребностей в отношении выходных данных (и размера исходного XML-файла) я бы даже избегал проверок XPath в исходном документе и вместо этого сохранял бы фрагменты XML в базе данных (как и все остальные). фактические текстовые узлы, которые принадлежат каждому XPath), а затем на лету восстанавливают уменьшенную версию исходного XML. Синтаксический анализ (и индексация) XML происходит медленно, печатая что-то как XML.

Answer 2

Какой язык программирования будет использоваться?Если он поддерживает XML / XSLT, я бы предпочел это.По крайней мере, Acts - это текстовые данные, а XML лучше подходит для этой базы данных.В базе данных вы должны разбить иерархию данных на части, в то время как в XML вы храните ее как есть.Если вы обнаружите, что пропустили иерархию, базу данных необходимо изменить, в то время как вы можете расширить иерархию XML там, где это необходимо, без изменения остальных.Какой из них лучше интегрировать, зависит от того, во что интегрировать.Для интеграции в веб-сайты или локальные HTML-страницы или через XSL-FO с PDF-Export XML идеально подходит.PHP имеет очень хорошую поддержку XSLT, но я не знаю, что именно вы хотите сделать.