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

Как лучше всего хранить эту информацию?

Моей первой мыслью было включить в текст некий Markdownсинтаксис , который затем будет проанализирован при извлечении. Что-то похожее на это:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit,
sed diam __nonummy nibh__[@note this sounds really funny latin]
euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Это может привести к двум проблемам:

1. Относительно небольшим является то, что если указанный синтаксис случайно оказался в указанном тексте, он может испортить синтаксический анализ.
2. Наиболее важным является то, что это не поддерживает эти метаданные отдельно от самого текста.

Я хотел бы иметь дискретную структуру данных для хранения этих данных, такую ​​как другая таблица БД, в которой хранятся эти метаданные, чтобы я мог использовать их по-разному: запросы, статистика, сортировка и так далее.

РЕДАКТИРОВАТЬ: Поскольку ответчик удалил свой ответ, я думаю, что было бы неплохо добавить его предложение здесь, так как это было реальное предложение, которое расширило эту первую концепцию. Плакат предложил использовать подобный синтаксис, но связать метаданные к PRIMARY KEYиз metadataтаблицы базы данных.

Нечто похожее на это:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit,
sed diam __nonummy nibh__[15432]
euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Где 15432будет находиться IDстрока таблицы, содержащая необходимую запрашиваемую информацию, как показано в примере ниже.

Моя вторая мысль заключалась в том, чтобы хранить информацию такого рода в таблице БД, которая выглядит следующим образом:

TABLE: metadata

ID    TEXT_ID    TYPE    OFFSET_START    OFFSET_END    CONTENT
1     lipsum     note    68              79            this sounds really funny latin

Таким образом, метаданные будут иметь уникальный идентификатор, text_idкак внешний ключ, связанный с таблицей, в которой хранятся тексты, и он будет связывать данные с самим текстом, используя простой диапазон смещения символов .

Это позволило бы отделить данные от метаданных , но проблема, которую я сразу вижу при таком подходе, заключается в том, что текст в принципе не подлежит редактированию . Или, если бы я захотел осуществить редактирование текста после назначения метаданных, мне пришлось бы в основном рассчитывать добавление или удаление символов по сравнению с предыдущей версией и проверять, добавляет ли каждая из этих модификаций символы или удаляет их до или после каждого из них. связанных метаданных.

Что для меня звучит как по-настоящему не элегантный подход.

Есть ли у вас какие-либо указания или предложения о том, как я мог бы подойти к проблеме?

Редактировать 2: некоторые проблемы с XML

Добавление еще одного случая, который сделал бы совершенно необходимым для такого разделения данных и метаданных.

• Допустим, я хочу, чтобы разные пользователи могли иметь разные наборы метаданных одного и того же текста , с возможностью или без возможности каждого пользователя фактически отображать метаданные другого пользователя.

Любое решение типа уценки (или HTML, или XML) было бы трудно реализовать на данном этапе. Единственное решение в этом случае, о котором я мог подумать, - это иметь еще одну таблицу БД, которая будет содержать однопользовательскую версию исходного текста, соединяющуюся с исходной текстовой таблицей с помощью a FOREIGN KEY.

Не уверен, что это очень элегантно.

• У XML есть иерархическая модель данных: любой элемент, который оказывается в границах другого элемента, рассматривается как его дочерний элемент , что чаще всего не соответствует той модели данных, которую я ищу; в XML любой дочерний элемент должен быть закрыт до того, как родительский тег может быть закрыт, не допуская перекрытия элементов.

Пример:

<note content="the beginning of the famous placeholder"> Lorem ipsum dolor sit <comment content="I like the sound of amet/elit"> amet </note> , посвященный адептированию elit </comment> , <note content="adversative?"> sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.<note content="funny latin"> </note> </note>

Здесь у нас есть две разные проблемы:

1. Различные элементы перекрываются: первый комментарий начинается в первой заметке, но заканчивается после окончания первой, т. Е. Это не его дочерний элемент.

2. Одинаковые элементы перекрываются: последняя нота и полужирная нота перекрываются; однако, поскольку они являются элементом одного типа, синтаксический анализатор закроет последний открытый элемент при первом закрытии, а первый открытый элемент - при последнем закрытии, что в данном случае не является тем, что предназначено.

Я бы выбрал сочетание ваших решений, но вместо этого я бы использовал стандарт: XML. У вас будет такой синтаксис

Lorem ipsum dolor sit amet, consectetuer adipiscing elit,
sed diam <note content="It sound really funny in latin">nonummy nibh</note>
euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Почему XML

Если вы подумаете об этом, это именно то, как структурирована вся сеть : контент (фактический текст), который несет семантическую - то, что вы называете метаданными - через HTML-теги.

Таким образом, у вас есть действительно крутой мир, который открывается:

• Бесплатный парсер
• Боевой проверенный способ добавления метаданных к контенту
• Простота использования (в зависимости от того, на каких пользователей вы ориентируетесь)
• Вы можете легко извлечь необработанный текст без метаданных, поскольку это стандартные функции синтаксических анализаторов XML. Это очень полезно иметь индексируемую версию вашего контента, поэтому Lorem <note>ipsum</note>поднимается, когда вы ищете, lorem ips*например.

Почему XML по уценке

Веб-сайт, такой как stackexchange, использует разметку, поскольку семантика, которую передает его контент, довольно проста: выделение, ссылки / URL-адреса, изображение, заголовок и т. Д.

1. Более сложный
2. Подлежит изменению или должен быть расширяемым

Таким образом, я чувствую, что Markdown не будет хорошей идеей. Кроме того, Markdown на самом деле не стандартизирован, и его анализ / сброс могут быть проблемой в заднице, даже более унылым синтаксисом, см . Пост Джеффа Этвуда о WTF, который он встретил при анализе Markdown .

О разделении данных и метаданных

По сути, такое разделение не является обязательным. Я полагаю, вы ищете преимущество, которое оно приносит:

• Возможность иметь сырой контент без метаданных
• Разделение проблем: я не хочу иметь побочных эффектов / сложности при манипулировании метаданными из-за данных, и в противном случае.

Все эти проблемы устраняются с помощью XML. Из XML вы можете легко вывести любой контент, лишенный тегов, и данные / метаданные разделены, точно так же, как атрибут и фактический текст разделены в XML.

Кроме того, я не думаю, что ваши метаданные могут быть абсолютно не привязаны к вашим данным . Из того, что вы описываете, ваши метаданные представляют собой композицию ваших данных, то есть удаление данных приводит к удалению метаданных. Здесь метаданные расходятся с обычным HTML / CSS. CSS не исчезает при удалении html-элемента, потому что он может быть применен к другим элементам. Я не чувствую, что это так в ваших метаданных.

Наличие метаданных, близких к данным, как в XML или Markdown, позволяет легко понять (и, возможно, отладить) данные. Кроме того, пример, который вы привели со своей второй мыслью, добавляет некоторую сложность, потому что для каждых данных, которые я читаю, мне нужно запросить таблицу метаданных, чтобы получить их. Если отношение между вашими данными и вашими метаданными составляет 1: 1 или 1: N, то это IMO, очевидно, бесполезно и приносит только сложность (хороший случай YAGNI).

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

Я не согласен с некоторыми другими ответами, просто потому что, хотя отличные решения, они, вероятно, не ваше решение. Да, у XML есть разметка слова в его аббревиатуре, но это, вероятно, не идеально для вашей ситуации. Он слишком сложный, он мало помогает в хранении метаданных отдельно от исходного текста. По сути это превратит все в форму метаданных, создав один избыточный набор данных.

Поскольку, вероятно, не существует абсолютно правильного решения или подхода, лучшее решение отвечает на вопрос:

Как данные будут использоваться системой?

Кроме того, если вы попытаетесь спросить, как дизайн решения может по своей сути повысить ценность системы и то, как она будет использоваться, тогда вы ближе к поиску своего элегантного ответа.

Понимание проблемы

Хорошо, достаточно комментариев, давайте углубимся в проблему. Это проблема, насколько я понимаю (очевидно, что добавление к ней будет полезно):

• Есть оригинальный текст
  • Предположения об этом оригинальном тексте:
  • Этот текст может состоять или не состоять из нескольких независимых документов
  • Этот текст может редактироваться одним или несколькими пользователями
  • Этот текст содержит связанную информацию. При этом я предполагаю (поправьте меня, если я ошибаюсь), что метаданные связаны, а не описательны . Таким образом, он хранит информацию, относящуюся к исходному тексту, а не информацию, которая описывает текст. Так он будет хранить заметки об исходном тексте, а не на примере описать , что текст является заголовком , который является смелым и является ссылкой на веб - сайт и т.д.
  • Текст должен легко фильтроваться отдельно от метаданных
  • Текст должен быть защищен от повреждения и повреждения метаданных.
• Должны быть средства хранения информации, связанной с исходным текстом (метаданными)
  • Этим метаданным также нужны собственные (мета) метаданные, которые будут содержать информацию, например, для какого пользователя (или групп?) Метаданные имеют отношение, например, описание метаданных, скажем, является ли это примечанием, или комментарием, или описание и т. д.
  • Эти метаданные (и их (мета) метаданные) должны выдерживать изменения в исходном тексте, изменения метаданных и изменения (мета) метаданных
  • Метаданные (+ метаданные) должны быть хорошо структурированы и легко запрашиваться, а также индексироваться или даже объединяться реляционным способом с другими наборами данных. Реляционная природа метаданных должна не только ограничиваться запросами, но также облегчать обновления или обратную запись и изменение метаданных в результате действий с реляционными данными.
  • Значение метаданных (+ Meta-Metadata) в своей очень связанной природе. Он сразу же становится контрпродуктивным, как только теряет связь с исходным текстом. Таким образом, целостность его отношения к исходному тексту является обязательным императивом дизайна.
• Другие предположения о природе проблемы и о том, как она будет использоваться:
  • Параллельный доступ к гетерогенной системе. То есть пользователь может захотеть просмотреть текст и отредактировать метаданные одновременно с тем, как администратор (или другой процесс) выполняет запросы реляционных данных над структурированными метаданными.
  • Система будет иметь несколько пользователей
  • Система современная. То есть он не ограничен объемом памяти, скоростью обработки или требованиями реального времени. Целостность и целенаправленная функциональность являются более приоритетными, чем ограничения физических вычислительных ресурсов.
  • Существует (хотя и небольшая) вероятность того, что использование и функциональные возможности системы могут несколько изменяться или изменяться по мере использования системы.

Построение дизайна решения

Понимая проблему, как я обрисовал ее выше, я сейчас начну предлагать возможные решения и подходы, направленные на решение вышеуказанной проблемы.

Компоненты

Таким образом, я бы увидел, что должна быть специально построенная система доступа пользователей. Это отфильтровывает релевантные и нерелевантные метаданные из исходного текста. Это облегчит редактирование и просмотр метаданных в тексте. Это обеспечит целостность отношений между метаданными и их оригинальным текстом. Он структурирует метаданные и предоставит источник данных для реляционной системы данных. Скорее всего, он предоставит множество других функций, управляемых целью.

Структура

Поэтому, поскольку важно сохранить целостность метаданных по отношению к исходному тексту, лучший способ обеспечить это - поддерживать метаданные в соответствии с исходным текстом. Это даст преимущество в том, что исходные данные можно уверенно редактировать, не нарушая эту целостность.

Проблемы с этим подходом связаны с искажением метаданных исходными данными и наоборот. Адекватное индексирование и структурирование метаданных и их (мета) метаданных таким образом, чтобы обеспечить запросы и обновления и эффективный доступ. Простая фильтрация метаданных из исходного текста.

Имея это в виду, я бы предложил, чтобы часть решения основывалась на подходе использования ESCAPE CHARACTERS в исходном тексте. Это не то же самое, что разработка собственного языка разметки или использование существующего языка разметки, такого как XML или HTML. Легко спроектировать ESCAPE CHARACTER с нулевым или почти нулевым шансом существования в исходном тексте.

В этом отношении я бы посоветовал вам внимательно изучить исходные данные и попытаться определить характер кодовой страницы, в которой они хранятся, а затем найти идеальную последовательность символов или последовательность символов.это вряд ли или невозможно произойти. Например, в ASCII есть буквально встроенные управляющие символы со значениями байтов, которые никогда не используются в стандартных пользовательских интерфейсах. То же самое можно сказать о информационной системе на основе шрифтов или реляционных данных. Просто будьте осторожны с двоичными кодеками данных. В зависимости от характера исходных данных может быть полезно создать синтаксический анализатор, который подтверждает обнаружение управляющей последовательности, возможно, просматривая экранированные данные и проверяя их целостность, либо с помощью простой проверки структуры экранированного данные, или даже путем включения управляющего символа, который рассчитывается для каждой экранированной последовательности данных.

Пример данных с Escape-последовательностями

Это история человека. >>>> (#) Почему эта история о мужчине, а не женщине? (#) ( ) Userid :: 77367 ( ) Комментарий менеджера ( ) DataID :: 234234234 >>>> Человек, который пошел косить луг, пошел косить луг. Человек пошел со своей собакой >>>> (#) Спросите клиента, будет ли лучше история с кошкой (#) >>>> косить луг. Итак, теперь это история о человеке и его собаке, которые пошли косить луг.

Один человек и его собака пошли косить луг, косить луг, луг достиг горы. >>>> (#) Звучит лучше с лесом (**) Примечание для заметки (#) >>>>

Человек и его собака и его миссия - косить луг, луг, достигающий горы, достигается только при пересечении реки.

Пример данных без Escape-последовательностей

Это история человека. Человек, который пошел косить луг, пошел косить луг. Человек пошел со своей собакой косить луг. Итак, теперь это история о человеке и его собаке, которые пошли косить луг.

Один человек и его собака пошли косить луг, косить луг, луг достиг горы.

Человек и его собака и его миссия - косить луг, луг, достигающий горы, достигается только при пересечении реки.

Очевидно, что это легко разбирается, не является сложным как весь язык разметки и легко адаптируется к вашей цели.

Решено еще? Ну, я бы сказал, нет. В нашем решении все еще есть дыры. Индексирование и структурированный доступ к этим данным оставляет желать лучшего. Кроме того, было бы неразумно запрашивать этот файл (или несколько файлов) одновременно с редактированием.

Как мы можем решить эту проблему?

Я бы предложил таблицу размещения данных в качестве заголовка документа. Я бы также предложил внедрить ТРАНЗАКЦИОННУЮ ОЧЕРЕДЬ ОБНОВЛЕНИЯ ТАБЛИЦ . Позволь мне объяснить. Разработчики файловой системы, в частности файловой системы с вращающимся диском, столкнулись с проблемами проектирования, аналогичными тем, которые вы описали выше. Им нужно было вставить информацию о файлах на диск вместе с данными. Отличным решением для целостности отношений этих данных было ДУБЛИРОВАТЬ их в Таблице размещения файлов (FAT).

Это означает, что для каждого отдельного элемента метаданных есть соответствующая запись в таблице распределения данных . Так что это быстро, структурировано и реляционно, и не зависит от исходных данных. Если необходимо выполнить запросы, объединения или обновления метаданных, то это легко сделать, просто открыв таблицу распределения данных .

Очевидно, следует позаботиться о том, чтобы исходные встроенные метаданные являлись истинным отражением данных таблицы распределения данных. Вот где приходит очередь обновления транзакционной таблицы. Каждое изменение, добавление или удаление метаданных производится не на самих данных, а на очереди. затем очередь будет гарантировать, что либо все изменения будут внесены как в данные в строке, так и в данные таблицы, либо вообще не будут внесены изменения. Это также позволяет выполнять асинхронные обновления, например, все метаданные определенного пользователя могут быть удалены с помощью команды удаления в очереди. Если встроенные метаданные были заблокированы и использовались, очередь не будет вносить никаких изменений, пока не сможет сделать это как с данными таблицы, так и с встроенными данными.

Это типичный технический вопрос, поскольку все ваши варианты имеют разные компромиссы, и что лучше всего зависит от того, что важно для вас. К сожалению, вы не дали достаточно информации, чтобы принять решение.

Вы также, кажется, не рассматривали важную семантическую проблему. Допустим, оригинальный текст

Мой друг Боб одолжил мне пять долларов

Кто-то добавляет комментарий вокруг «Боб», говоря

Боб полный идиот

Затем исходный текст редактируется в

Джейн одолжила Бобу пять долларов, которые он позже одолжил мне

Вы можете иметь некоторый смысл в этом конкретном случае, используя алгоритм сопоставления текста, например, используемый для отображения файла сравнения, но смещение символов приведет к тому, что метаданные присоединятся к «Jan» в «Jane».

Хуже, если текст редактируется в

Мой друг Стив одолжил мне пять долларов

Вы могли бы понять, как прикрепить метаданные к «Стиву», но как узнать, применимо ли это?

Кроме того, вы решили, могут ли метаданные иметь метаданные? Это может изменить вашу реализацию.

Помимо семантических проблем, не очень понятно, что вы делаете с данными. Я подумал, что, возможно, было очень неудобно, чтобы исходный текст был «загрязнен» какой-либо разметкой, но тогда вы были в порядке с наличием значений ID в нем. Что не имеет большого смысла, если метаданные применяются к части текста, а не вставляются в точку в тексте.

Я предполагаю, что для большинства целей проще хранить размеченный текст или, во-вторых, использовать весь SQL-код и представлять текст и разметку в виде иерархии узлов - в основном DOM в форме таблицы. Если ваши данные иерархичны, то, возможно, будет проще использовать XML и получать существующие парсеры бесплатно, а не писать свои собственные.

Вполне возможно, что есть какое-то довольно простое решение, которое достаточно подходит для вашей конкретной ситуации, но я не могу сказать вам, что это такое, потому что оно действительно зависит от того, что вы пытаетесь сделать, в деталях.

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

Извините, что ответ так разбросан и полон "это зависит", но вопросы дизайна реального мира такие.

Я думаю, что предложение предыдущего ответчика, которое вы упоминаете по вашему вопросу), очень хорошее.

Он будет вести себя так же, как мы публикуем ссылки на сайтах StackExchange, но информационные данные будут находиться в другой таблице. Преимущества заключаются в том, что у вас есть отдельные данные, и, следовательно, возможность запроса и индексации. При редактировании текста вы можете проверить наличие удаленных идентификаторов метаданных и очистить таблицу метаданных.

Единственная небольшая проблема, как вы сказали, - это разбор, но вы можете справиться с ней довольно легко.

Допустим, у меня есть текст:

Lorem ipsum dolor sit amet, посвященный адептированию elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Я добавляю записку так:

Lorem ipsum dolor sit amet, посвященный здоровью elit, sed diam [@ 123, # 456,2w] nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

[@123,#456,2w]означает: user_id = 123, note_id = 456, а текст, помеченный этой заметкой, охватывает следующие 2 слова (может быть chars ( c), фраз ( s), параграпов ( p) или что угодно). Точный синтаксис может быть разным, конечно.

В текстовых редакторах текст заметок может быть легко сохранен в конце документа, как в сносках Markdown.

В редакторах форматированного текста этот вид заметки может отображаться в тексте в виде значка, а помеченный текст может быть выделен некоторым образом. Затем пользователь может удалять такие заметки, как обычные символы, с помощью Delили Backspace, и редактировать их в каком-то особом режиме редактирования. Я представляю изменение размеров отмеченных областей с помощью мыши и редактирование текста заметки с помощью всплывающего окна.

Плюсы:

• Хорошо сочетается с «пересечениями», поскольку вы помечаете смещение (неявно по позиции заметки в тексте) и длину для каждой заметки.
• Поддерживает многопользовательскую среду. (На самом деле, это требует более глубокого исследования, и вам, вероятно, придется иметь дело с чем-то вроде оперативных преобразований Google Wave , с которыми мой мозг не может справиться.)
• Может быть отредактирован как с помощью полноформатных, так и текстовых редакторов.
• Вы можете легко обрабатывать ревизии, поскольку все маркеры на месте - когда вы редактируете текст перед маркером, маркер просто сдвигается вместе с другим текстом.
• Легко разобрать.
• Нет необходимости во внешней БД, но вы все равно можете использовать ее, если хотите.
• Может быть смешан с Markdown или XML, если вы выберете какой-нибудь ненавязчивый синтаксис.

Минусы для редактирования простого текста:

• Вы не можете видеть области в тексте, помеченные заметками (если только вы не выделите открытый текст, что тоже возможно), но только места, где начинаются заметки. Это компенсируется возможностью выбирать произвольные единицы длины: символы, слова, предложения, абзацы.
• Вы можете редактировать текст под заметкой, не замечая этого, особенно если заметка занимает достаточно длинный участок (например, 2+ абзаца). Может быть компенсирован механизмом контроля версий, который сравнивает текст каждой заметки с предыдущей версией и уведомляет пользователя, если он был изменен.

Общие минусы:

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