Я розробляю додаток, в якому потрібно буде зберігати вбудовані , інтекстні метадані. Я маю на увазі під собою таке: скажімо, у нас довгий текст, і ми хочемо зберегти деякі метадані, пов'язані з певним словом або пропозицією тексту.

Який найкращий спосіб зберігати цю інформацію?

Моя перша думка полягала в тому, щоб включити до тексту якийсь 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. Найголовніше те, що це не підтримує ці метадані окремо від самого тексту.

Я хотів би мати дискретну структуру даних для зберігання цих даних, таку іншу таблицю БД, в якій зберігаються ці метадані, щоб я міг їх використовувати дискретно: запити, статистика, сортування тощо.

EDIT: Оскільки відповідь видалив свою відповідь, я думаю, що було б добре додати тут свою пропозицію, оскільки це було корисною пропозицією, яка поширилася на цій першій концепції. Плакат запропонував використовувати аналогічний синтаксис, але пов'язати метадані 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

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

Це дозволило б зробити фокус збереження даних відокремлених від метаданих , але проблема, яку я одразу бачу при такому підході, полягає в тому, що текст не можна редагувати . Або, якщо я хотів реалізувати редагування тексту після передачі майна метаданих, я б в основному доведеться розраховувати символи доповнення або видалення по порівнянні з попередньою версією, і перевірити , є чи кожен додає цій модифікації або видалити символи до або після кожного пов'язаних метаданих.

Що, на мене, звучить як справді неелегантний підхід.

Чи є у вас вказівки чи пропозиції щодо того, як я міг би підійти до проблеми?

Редагувати 2: деякі проблеми з XML

Додамо ще один випадок, який би став цілком необхідним для цього поділу даних та метаданих.

• Скажімо, я хочу зробити це можливим для різних користувачів різні набори метаданих одного тексту , з або без можливості кожного користувача фактично відображати метадані іншого користувача.

Будь-яке рішення уцінки виду (або HTML або XML) буде важко реалізувати в цій точці. Єдиним рішенням у цьому випадку, про який я міг би подумати, було б мати ще одну Таблицю БД, яка містила б єдину користувацьку версію оригінального тексту, підключення до початкової таблиці тексту за допомогою 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> , consectetuer adipiscing 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. Підлягає зміні або має бути розширеним

Тому я вважаю, що Маркдаун не був би дуже хорошою ідеєю. Також Маркдаун насправді не стандартизований, і розбір / демпінг може бути болем у дупі, ще більше помітний синтаксис - див . Допис Джеффа Етвуда про WTF, з яким він познайомився під час розбору Markdown .

Про розділення між даними та метаданими

Таке розмежування не є обов'язковим. Я припускаю, що ви шукаєте перевагу, яку вона приносить:

• Можливість мати вихідний вміст без метаданих
• Розділення проблем: Я не хочу мати надмірних побічних ефектів / складності під час маніпулювання метаданими через дані та інше.

Усі ці проблеми усуваються за допомогою використання XML. З XML ви можете легко скинути будь-який вміст, позбавлений тегів, і дані / метадані відокремлені, подібно до атрибута та фактичного тексту, розділеного у XML.

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

Маючи метадані, близькі до даних, як у XML або Markdown, дозволяють легко зрозуміти (і, можливо, налагодити) дані. Також приклад, який ви наводите на свою другу думку, додає певної складності, оскільки для кожного даних, які я читаю, мені потрібно запитати таблицю метаданих, щоб їх отримати. Якщо співвідношення між вашими даними та вашими метаданими становить 1: 1 або 1: N, то IMO явно марний і приносить лише складність (хороший випадок YAGNI).

Справа використання рішення

Я не згоден з деякими іншими відповідями, просто тому, що, маючи чудові рішення, вони, ймовірно, не є вашими рішенням. Так, у XML є розмітка слова в абревіатурі, але це, мабуть, не ідеально для вашої ситуації. Це занадто складно, він мало допомагає зберігати метадані окремо від початкового тексту. По суті, це перетворить усе у форму метаданих, створивши один набір даних про зайву вагу.

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

Як дані будуть використовуватись системою?

Крім того, якщо ви спробуєте і запитаєте, як дизайн рішення по суті може додати значення системи таким чином, як вона буде використана, то ви ближче до пошуку своєї елегантної відповіді.

Розуміння проблеми

Добре коментар, давайте розберемося в проблемі. Це проблема, наскільки я розумію, що це (очевидно, додавання до цього буде корисним):

• Є оригінальний текст
  • Припущення щодо цього оригінального тексту:
  • Цей текст може бути, а може і не складатися з декількох незалежних документів
  • Цей текст може бути або не може редагуватися одним або кількома користувачами
  • Цей текст містить відповідну інформацію. Цим я припускаю (виправте мене, якщо я помиляюся), що метадані пов'язані, а не описові . Таким чином, він зберігає інформацію, що стосується початкового тексту, а не інформацію, що описує текст. Так він зберігатиме нотатки про оригінальний текст, а не на прикладі описує, що текст - це заголовок, що є жирним шрифтом і є посиланням на веб-сайт тощо.
  • Текст повинен легко фільтруватися, відрізняючись від метаданих
  • Текст повинен бути захищений від пошкодження та пошкодження метаданих
• Повинні бути засоби для зберігання інформації, що стосується початкового тексту (метаданих)
  • Ці метадані також потребують власних (мета) метаданих, які б містили інформацію, таку як для користувача (або групи?) Метадані, що стосуються, наприклад, опис метаданих, скажімо, погода це примітка, коментар, або опис тощо
  • Ці метадані (і це (мета) метадані) повинні витримувати зміни в оригінальному тексті, зміни метаданих та зміни (мета) метаданих
  • Метадані (+ Meta-Metadata) повинні бути добре структуровані та легко запитуватися, індексуватися або навіть приєднуватися реляційно до інших наборів даних. Реляційний характер метаданих не повинен обмежуватися лише Запити, але також сприяти оновленням, запису або зміни метаданих в результаті діяльності щодо реляційних даних.
  • Значення метаданих (+ Meta-Metadata) полягає в її дуже спорідненому характері. Він стає негайно протилежним моменту, коли втрачає відношення до початкового тексту. Таким чином, цілісність його відношення до оригінального тексту є обов'язковим імперативним дизайном.
• Інші припущення щодо природи проблеми та способів її використання:
  • Одночасний гетерогенний доступ до системи. Тобто, користувач, можливо, бажає переглядати текст і редагувати метадані, одночасно, коли адміністратор (або інший процес) виконує реляційні запити даних на структурованих метаданих.
  • У системі буде кілька користувачів
  • Система сучасна. Тобто це означає, що це не обмежується простором зберігання, швидкістю обробки або необхідними імперативами в режимі реального часу. Функціональність, орієнтована на цілісність та ціль, є вищим пріоритетом, ніж обмеження ресурсів фізичних обчислень.
  • Існує (хоч і низький) шанс, що використання та функціональність системи можуть еволюціонувати або дещо змінюватися в міру використання системи.

Побудова дизайну рішення

Розуміючи проблему, як я її окреслив вище, я зараз почну пропонувати можливі рішення та підходи, спрямовані на вирішення вищезазначеної проблеми.

Компоненти

Тож я побачив би, що там повинна бути спеціально побудована система доступу користувачів. Він би фільтрував відповідні та нерелевантні метадані з початкового тексту. Це полегшило б редагування та перегляд метаданих у тексті. Це забезпечило б цілісність взаємозв'язку між метаданими та його оригінальним текстом. Вона структурувала б метадані та пропонувала б джерело даних реляційній системі даних. Він, швидше за все, забезпечить безліч інших керованих цілей функцій.

Будова

Отже, оскільки важливо зберегти цілісність метаданих до оригінального тексту, найкращий спосіб забезпечити це - підтримувати метадані в точності з оригінальним текстом. Це дасть перевагу в тому, що оригінальні дані можна буде впевнено редагувати, не порушуючи цієї цілісності.

Побоювання такого підходу полягають у пошкодженні метаданих оригінальними даними та навпаки. Адекватна індексація та структурування метаданих та її (мета) метаданих таким чином, що дозволяє здійснювати запити та оновлення та ефективний доступ. Легка фільтрація метаданих з оригінального тексту.

Зважаючи на це, я б запропонував, щоб частина рішення базувалася на підході до використання ESCAPE ХАРАКТЕРІВ у початковому тексті. Це не те саме, що створити власну мову розмітки або використовувати існуючу мову розмітки, наприклад XML або HTML. Розробити ХАРАКТЕР ESCAPE легко, який має нульовий або майже нульовий шанс існування в оригінальному тексті.

Моя порада вам у цьому відношенні полягає в тому, щоб уважно розглянути вихідні дані та спробувати визначити характер кодової сторінки, в якій вони зберігаються, а потім шукати ідеальний ЗАРЯДОК або ХАРАКТЕР ПОСЛІДНОСТІце малоймовірно або неможливо. Наприклад, в ASCII є буквально вбудовані символи управління зі значеннями байтів, які ніколи не використовуються в стандартних інтерфейсах користувача. Те саме можна сказати для інформаційної системи на основі шрифту або реляційних даних. Будьте обережні з кодеками двійкових даних. Залежно від характеру вихідних даних може бути корисним побудувати аналізатор, який підтверджує виявлення послідовності керування, можливо, переглянувши дані, які вийшли та перевіривши цілісність, або за допомогою простої перевірки структури вилучених даних. дані, або навіть шляхом включення символу управління, який обчислюється для кожної послідовності даних, що вийшли.

Приклад даних із послідовностями втечі

Це історія людини. >>>> (#) Чому ця історія про чоловіка не жінку? (#) ( ) Userid :: 77367 ( ) Коментар менеджера ( ) DataID :: 234234234 >>>> Чоловік, який пішов косити луг, пішов косити луг. Чоловік пішов зі своєю собакою >>>> (#) Запитайте клієнта, чи краще буде історія з котом замість (#) >>>> косити луг. Тож тепер це історія людини та його собаки, які пішли косити луг.

Один чоловік і його собака, пішли косити луг, пішли косити луг, луг сягав над горою. >>>> (#) Це набагато краще звучить із лісом (**) Примітка щодо пропозицій (#) >>>>

Людина та його собака та його завдання, косити луг, луг, що над горами, досягається лише при перетині річки.

Приклад даних без послідовностей уникнення

Це історія людини. Чоловік, який пішов косити луг, пішов косити луг. Чоловік пішов зі своїм собакою косити луг. Тож тепер це історія людини та його собаки, які пішли косити луг.

Один чоловік і його собака, пішли косити луг, пішли косити луг, луг сягав над горою.

Людина та його собака та його завдання, косити луг, луг, що над горами, досягається лише при перетині річки.

Очевидно, що це легко аналізується, не є складним як ціла мова націнки і легко адаптується до вашого призначення.

Вирішили все ж? Ну, я б сказав, що ні. У нашому рішенні все ще є деякі дірки. Індексація та структурований доступ до цих даних поганий. Крім того, було б недоцільно запитувати цей файл (або кілька файлів) одночасно з його редагуванням.

Як ми могли вирішити цю проблему?

Я б запропонував таблицю розподілу даних як заголовок документа. Я б також запропонував запровадити ОНОВЛЕННЯ ЧАСТИНИ ОНОВЛЕННЯ ТРАНСАКЦІЙНОГО ТАБЛИЦІ . Дозволь пояснити. Дизайнери файлової системи, зокрема файлової системи з обертовим диском, стикалися з подібними дизайнерськими проблемами, ніж ті, які ви описали вище. Їм потрібно було вставити інформацію про файли на диску разом із даними. Прекрасним рішенням цілісності зв’язків цих даних було розмноження даних у таблиці розподілу файлів (FAT).

Це означає, що для кожного окремого елемента метаданих є відповідний запис у таблиці розподілу даних . Таким чином, він швидкий, структурований і реляційний і не залежить від вихідних даних. Якщо запити або приєднання або оновлення потрібно виконувати на метаданих, це легко зробити, просто відкривши таблицю розподілу даних .

Очевидно, що потрібно бути обережним, щоб оригінальні вбудовані метадані були справжнім відображенням даних таблиці розподілу даних. Саме тут надходить черга оновлення транзакційних таблиць. Кожна зміна, додавання чи видалення метаданих здійснюється не на самих даних, а на черзі. тоді черга гарантуватиме, що або всі зміни внесені як до рядкових, так і до даних таблиці, або взагалі не буде внесено змін. Він також дозволяє виконувати асинхронні оновлення, наприклад, всі метадані певного користувача можна видалити, виконавши команду delete на черзі. Якщо вбудовані метадані були заблоковані та використовуються, черга не проводитиме жодних змін, поки вона не зможе зробити це як даними таблиці, так і вбудованими даними.

Це типовий інженерний питання, оскільки всі ваші варіанти мають різні компроміси, і це найкраще залежить від того, що для вас важливо. На жаль, ви не дали достатньо інформації, щоб визначитись.

Ви також не вважали важливою семантичною проблемою. Скажімо, це оригінальний текст

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

Хтось додає коментар навколо "Боба", кажучи

Боб - повний ідіот

Потім оригінальний текст редагується в

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

Ви могли б зробити якийсь - то сенс в цьому конкретному випадку , використовуючи алгоритм зіставлення тексту , такі як то , що використовується , щоб показати файл відмінностей, але зміщення символів збираються зробити метадані прикріплюються до «Ян» в «Джейн».

Гірше, якщо текст буде відредагований

Мій друг Стів позичив мені п’ять доларів

Вам вдалося розібратися, як прикріпити метадані до "Steve", але як ви знаєте, чи застосовуються вони?

Також ви вирішили, чи можуть самі метадані мати метадані? Це може змінити вашу реалізацію.

Крім семантичних питань, не зовсім зрозуміло, що ви робите з даними. Я вважав, що, мабуть, дуже незручно, щоб оригінальний текст був "забруднений" будь-якою розміткою, але тоді у вас було все гаразд із наявністю в ньому значень ID. Що не має великого сенсу, якщо метадані застосовуються до розділу тексту замість того, щоб вставляти їх у точку тексту.

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

Цілком можливо, що є якесь досить просте рішення, яке досить добре для вашої точної ситуації, але я не можу вам детально сказати, що це таке, оскільки це насправді залежить від того, що ви намагаєтеся зробити, докладно.

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

Вибачте, що відповідь настільки розкиданий і настільки насичений "це залежить", але реальні питання дизайну світу такі.

Я вважаю, що пропозиція попереднього відповіді, того, про кого ви згадуєте, ви дуже добре.

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

Єдина невелика проблема, як ви сказали, - це аналіз, але ви можете впоратися з цим досить легко.

Скажімо, у мене є текст:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Я додаю примітку так:

Lorem ipsum dolor sit amet, consectetuer adipiscing 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 слова (можуть бути символами ( c), реченнями ( s), параграфами ( p) або будь-яким іншим). Точний синтаксис, звичайно, може бути різним.

У текстових редакторах текст приміток легко зберігається в кінці документа, як і у виносках Markdown.

У редакторах з багатою текстовою формою ця примітка може відображатися в тексті як значок, а позначений текст може бути виділений певним чином. Потім користувач може видалити такі нотатки, як звичайні символи, за допомогою Delабо Backspace, і відредагувати їх за допомогою якогось спеціального режиму редагування. Я уявляю, як змінити розмір помічених областей за допомогою миші та редагувати текст примітки із спливаючим вікном.

Плюси:

• Чудово поєднується з "перехрестями", оскільки ви позначаєте зміщення (неявно положення ноти в тексті) та довжину для кожної ноти.
• Підтримує багатокористувацьке середовище. (Насправді для цього потрібні глибші дослідження, і вам, мабуть, доведеться мати справу з чимось на зразок операційних перетворень Google Wave , з якими мій мозок не може впоратися.)
• Можна редагувати як редакторами насиченого, так і простим текстом.
• Ви можете легко обробити зміни, оскільки всі маркери є на місці - коли ви редагуєте текст перед маркером, маркер просто зміщується разом з іншим текстом.
• Легко розібратися.
• У зовнішній БД немає потреби, але ви все одно можете використовувати її, якщо хочете.
• Можна змішувати з Markdown або XML, якщо ви вибрали якийсь ненав’язливий синтаксис.

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

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

Загальні мінуси:

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