インライン、テキストのメタデータを保存する必要があるアプリケーションを開発しています。つまり、長いテキストがあり、特定の単語またはテキストの文に関連するメタデータを保存するとします。

この情報を保存する最良の方法は何でしょうか？

私が最初に考えたのは、テキストを検索するときに解析される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.

これにより、私が考えることができる2つの問題が発生します。

1. 比較的小さいのは、前述の構文が偶然にも前述のテキストにあった場合、構文解析を混乱させる可能性があるということです。
2. 最も重要なのは、このメタデータがテキスト自体とは別に維持されないことです。

クエリ、統計、並べ替えなどの個別の方法でそれらを使用できるように、これらのメタデータが格納されている異なるDBテーブルなど、このデータを保持する個別のデータ構造が必要です。

編集：回答者が答えを削除したので、この最初の概念を拡張した実用的な提案だったので、ここに彼の提案を追加するのが良いと思います。ポスターは似た構文を使用するが、これにメタデータをリンクすることが示唆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以下の例のように、必要に応じて、照会可能な情報を含むテーブルの行の。

私の2番目の考えは、このような情報を次のようなDBテーブルに保存することでした。

TABLE: metadata

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

この方法では、メタデータは一意のIDを持ちtext_id、テキストを格納するテーブルに接続された外部キーとして、単純な文字オフセット範囲を使用してデータをテキスト自体に接続します。

これは維持のトリック行うだろうデータから分離されたメタデータを、私はすぐにこのアプローチを見ることができるという問題は、テキストが根本的になることで編集することはできません。私は、メタデータの逢引後のテキストの編集を実装したい場合は、私は基本的に以前のバージョンに比べて文字の追加、または削除を計算し、かどうかを確認する必要がありますそれぞれ、この変更の前または後に削除文字を追加したり、各関連するメタデータの。

私には、これは本当に違法なアプローチのように聞こえます。

この問題にどのようにアプローチできるかについての指針や提案はありますか？

編集2：いくつかのXMLの問題

このデータとメタデータの分離を行うために非常に必要になる別のケースを追加します。

• 各ユーザーが実際に他のユーザーメタデータを表示するかどうかにかかわらず、異なるユーザーが同じテキストの異なるメタデータセットを持つことができるようにしたいとしましょう。

この時点では、マークダウンの種類のソリューション（またはHTML、XML）の実装は困難です。私が考えることができるこの場合の唯一の解決策は、元のテキストのシングルユーザーバージョンを含む別のDBテーブルを持ち、を使用して元のテキストテーブルに接続することです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>

ここには2つの異なる問題があります。

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*。

Markdown over Markdownを使用する理由

stackexchangeのようなWebサイトは、コンテンツが伝える意味論がかなり基本的であるため、マークダウンを使用します。強調、リンク/ URL、画像、ヘッダーなど。コンテンツに追加する意味論は

1. より複雑
2. 変更されるか、拡張可能である必要があります

したがって、Markdownはあまり良いアイデアではないと思う。また、Markdownは実際には標準化されておらず、解析/ダンプはお尻の痛みになる可能性があります。さらにマークダウンの構文については、Markdownの解析で出会ったWTFに関するJeff Atwoodの投稿を参照してください。

データとメタデータの分離について

本質的に、そのような分離は必須ではありません。私はあなたがそれがもたらす利点を探していると思います：

• メタデータなしで生のコンテンツを持つ可能性
• 懸念の分離：データなどの理由でメタデータを操作する際に、副作用/複雑さのオーバーヘッドを持ちたくありません。

これらの懸念はすべて、XMLを使用することで解消されます。XMLから、タグストリップされたコンテンツを簡単にダンプでき、属性と実際のテキストがXMLで分離されるように、データ/メタデータが分離されます。

また、メタデータを完全にデータにバインドすることはできないと思います。説明から、メタデータはデータの構成です。つまり、データを削除するとメタデータが削除されます。ここで、メタデータは通常のHTML / CSSとは異なります。CSSは、他の要素に適用できるため、html要素が削除されても消えません。これはあなたのメタデータに当てはまるとは思いません。

XMLやMarkdownのように、メタデータをデータに近づけることで、データを簡単に理解（およびデバッグ）できます。また、あなたが考え直した例を与えると、複雑さが増します。なぜなら、私が読んでいるデータごとに、メタデータテーブルをクエリしてこれらを取得する必要があるからです。データとメタデータの関係が1：1または1：Nである場合、IMOは明らかに役に立たず、複雑さのみをもたらします（YAGNIの良いケース）。

ソリューションの使用例

私は他のいくつかの答えには同意しません。単に優れたソリューションではあるが、おそらくあなたのソリューションではないからです。はい、XMLには頭字語にマークアップという言葉がありますが、おそらくあなたの状況には理想的ではありません。あまりにも複雑すぎて、メタデータを元のテキストから分離するのにほとんど役立ちません。基本的に、すべてをメタデータの形式に変換し、1つの過大なデータセットを作成します。

絶対に正しい解決策やアプローチがない可能性が高いため、最適な解決策が質問に答えます。

システムはどのようにデータを使用しますか？

また、ソリューションの設計がシステムの価値を本質的にどのように使用するのかを尋ねると、エレガントな答えを見つけることに近づきます。

問題を理解する

十分な解説をして、問題を掘り下げましょう。これは私が理解している問題です（明らかにこれに追加することは有益です）：

• 元のテキストがあります
  • この元のテキストに関する仮定：
  • このテキストは、いくつかの独立したドキュメントで構成されている場合とされていない場合があります
  • このテキストは、1人以上のユーザーによって編集される場合とされない場合があります
  • このテキストには、関連情報が含まれています。それによって、メタデータが関連しており、説明的ではないと仮定しています（間違っている場合は修正してください）。そのため、テキストを説明する情報ではなく、元のテキストに関連する情報を保存します。それは、元のテキストについてのメモを保存し、そして例によりテキストがあることについては説明しませんので、ある見出しで大胆かつあるなど、ウェブサイトへのリンク
  • テキストは、メタデータとは別に簡単にフィルタリングする必要があります
  • テキストは、メタデータによる破損、およびメタデータの破損から保護する必要があります
• 元のテキスト（メタデータ）に関連する情報を保存する手段が必要です
  • また、このメタデータには、メタデータの説明、メモ、コメントなどのメタデータの説明など、メタデータが関連するユーザー（またはグループ）などの情報を保持する独自の（メタ）メタデータが必要です。説明など
  • このメタデータ（および（メタ）メタデータ）は、元のテキストの変更、メタデータの変更、および（メタ）メタデータの変更に耐える必要があります。
  • メタデータ（+メタメタデータ）は、適切に構造化され、簡単にクエリを実行し、インデックスを作成するか、他のデータセットとリレーショナルな方法で結合する必要があります。メタデータのリレーショナルな性質はクエリに限定されるだけでなく、リレーショナルデータアクティビティの結果としてメタデータの更新または書き戻しと変更を促進する必要があります。
  • メタデータ（+ Meta-Metadata）の価値は、非常に関連した性質にあります。元のテキストとの関係を失うと、すぐに逆効果になります。したがって、元のテキストとの関係の整合性は、必須の設計上の必須事項です。
• 問題の性質とその使用方法に関するその他の仮定は次のとおりです。
  • 同時異種システムアクセス。つまり、管理者（または別のプロセス）が構造化されたメタデータに対してリレーショナルデータクエリを実行すると同時に、ユーザーがテキストを表示してメタデータを編集したい場合があります。
  • システムには複数のユーザーがいます
  • システムは最新です。つまり、ストレージスペース、処理速度、またはリアルタイムの命令に制約されないということです。整合性と目的重視の機能は、物理的なコンピューティングリソースの制限よりも優先度が高くなります。
  • システムが使用されるにつれて、システムの使用と機能が多少進化または変化する可能性があります（ただし、低い）。

ソリューション設計の構築

上記で概説した問題を理解し、上記の問題を解決することを目的とする可能な解決策とアプローチを提案し始めます。

構成部品

したがって、カスタムビルドのユーザーアクセスシステムが必要になることがわかります。元のテキストから関連性のあるメタデータと無関係なメタデータをフィルタリングします。テキストへのメタデータの編集と表示が容易になります。メタデータと元のテキストとの関係の整合性を保証します。メタデータを構造化し、データソースをリレーショナルデータシステムに提供します。多くの場合、他の目的駆動機能のホストを提供します。

構造

したがって、元のテキストに対するメタデータの整合性を保つことが重要であるため、これを保証する最善の方法は、元のテキストとメタデータをインラインに保つことです。これにより、この整合性を損なうことなく元のデータを自信を持って編集できるという利点が得られます。

このアプローチの懸念は、元のデータによるメタデータの破損とその逆です。メタデータとその（メタ）メタデータの適切なインデックス作成と構造化により、クエリと更新、および効率的なアクセスが可能になります。元のテキストからのメタデータの簡単なフィルタリング。

これを念頭に置いて、ソリューションの一部は、元のテキスト内でESCAPE CHARACTERSを使用するアプローチに基づいていることをお勧めします。これはない、独自のマークアップ言語を設計するか、XMLやHTMLなどの既存のマークアップ言語を使用するのと同じ。元のテキストに存在する可能性がゼロまたはゼロに近いESCAPE CHARACTERを設計するのは簡単です。

この点についての私のアドバイスは、元のデータを慎重に検討し、それが格納されているコードページの性質を判断して、理想的な文字または 文字シーケンスを探すことです。それは起こりそうもないか不可能です。たとえば、ASCIIには、標準のユーザーインターフェイスでは使用されない、バイト値を持つ文字通りの組み込み制御文字があります。フォントベースまたはリレーショナルデータベースの情報システムでも同じことが言えます。バイナリデータコーデックには注意してください。元のデータの性質によっては、エスケープされたデータの構造を簡単に検査して、おそらくエスケープされたデータを調べ、その整合性を検証することにより、制御シーケンスの発見を確認するパーサーを構築することが重要な場合がありますデータ、またはエスケープされたデータシーケンスごとに計算される制御文字を含めることもできます。

エスケープシーケンスを使用したデータの例

これは男の物語です。>>>>（＃）なぜこの物語は男性ではなく女性ですか？（＃）（）userid :: 77367（）Manager's Comment（）DataID :: 234234234 >>>>牧草地を刈りに行きました。男は犬と一緒に行きました>>>>（＃）牧草地を刈るのに代わりに猫を使って話をした方が良いかどうかクライアントに尋ねます（＃）>>>> だから今、これは牧草地を刈りに行った男と彼の犬の物語です。

一人の男と彼の犬は、牧草地を刈りに行き、牧草地を刈りに行き、牧草地は山の上に達しました。>>>>（＃）これは、森林でより良く聞こえます（**）提案ノート（＃）>>>>

男と彼の犬と彼の使命は、牧草地を刈る、山を越えて到達した牧草地は、川を渡るときにのみ到達します。

エスケープシーケンスのないサンプルデータ

これは男の物語です。牧草地を刈りに行った男は、牧草地を刈りに行きました。男は犬と一緒に牧草地を刈りに行きました。それで今、これは牧草地を刈りに行った男性と彼の犬の物語です。

一人の男と彼の犬は、牧草地を刈りに行き、牧草地を刈りに行き、牧草地は山の上に達しました。

男と彼の犬と彼の使命は、牧草地を刈る、山を越えて到達した牧草地は、川を渡るときにのみ到達します。

明らかに、これは簡単に解析され、マークアップ言語全体として複雑ではなく、目的に簡単に適応できます。

まだ解決しましたか？ まあ、私はノーと言うでしょう。私たちのソリューションにはまだいくつかの穴があります。このデータのインデックス作成と構造化アクセスは不十分です。また、このファイル（または複数のファイル）を編集すると同時に照会することは合理的ではありません。

どうすればその問題を解決できますか？

ドキュメントヘッダーとしてDATA ALLOCATION TABLEをお勧めします。TRANSACTIONAL TABLE UPDATE QUEUEを実装することもお勧めします。説明させてください。ファイルシステム、特に回転ディスクファイルシステムの設計者は、上記で説明したものと同様の設計上の課題に直面しました。彼らは、データとともに、ディスク上のファイルに関する情報を埋め込む必要がありました。このデータの関係の整合性に対する優れたソリューションは、ファイルアロケーションテーブル（FAT）でデータを重複させることでした。

これは、個々のメタデータアイテムごとに、データ割り当てテーブルに対応するエントリがあることを意味します。そのため、高速で構造化され、リレーショナルであり、元のデータから独立しています。メタデータに対してクエリ、結合、または更新を実行する必要がある場合、データ割り当てテーブルにアクセスするだけで簡単に実行できます。

明らかに、元のインラインメタデータがデータアロケーションテーブルのデータを正確に反映するように注意する必要があります。それがトランザクションテーブル更新キューの出番です。メタデータのすべての変更、追加、削除は、データ自体ではなく、キューで行われます。キューは、インラインデータとテーブルデータの両方にすべての変更が行われるか、まったく変更が行われないようにします。また、非同期更新を実行できます。たとえば、特定のユーザーのすべてのメタデータは、キューで削除コマンドを実行することで削除できます。インラインメタデータがロックされて使用中の場合、キューは、テーブルデータとインラインデータの両方に変更を加えるまで、変更を実行しません。

これは、すべてのオプションに異なるトレードオフがあるという点で、典型的なエンジニアリングの質問であり、どれが最も重要かによって異なります。残念ながら、あなたは決定を下すのに十分な情報を与えていません。

また、重要なセマンティックの問題を考慮していないようです。元のテキストが

友達のボブが私に5ドルを貸してくれました

誰かが「ボブ」の周りにコメントを追加します

ボブは完全な馬鹿です

次に、元のテキストを編集して

ジェーンはボブに5ドルを貸し出し、後で彼に貸してくれました

diffファイルの表示に使用されるものなどのテキストマッチングアルゴリズムを使用して、この特定のケースをある程度理解するかもしれませんが、文字オフセットにより、メタデータが「Jane」の「Jan」にアタッチされます。

さらに悪いのは、テキストが

友人のスティーブが私に5ドルを貸してくれました

メタデータを "Steve"にアタッチする方法を理解することはできますが、それが適用されるかどうかはどのようにわかりますか？

また、メタデータ自体にメタデータを含めることができるかどうかを決めましたか？それはあなたの実装を変えるかもしれません。

セマンティックの問題以外に、データで何をしているのかはあまり明確ではありません。オリジナルのテキストをマークアップで「汚染」するのは非常に不便だと思ったかもしれませんが、ID値を入れても大丈夫です。メタデータがテキストのポイントに挿入されるのではなく、テキストのセクションに適用される場合、これはあまり意味がありません。

私の推測では、ほとんどの目的でマークアップされたテキストを保存する方が簡単です。データが階層構造の場合、XMLを使用して既存のパーサーを無料で取得する方が、独自に作成するよりも簡単です。

あなたの正確な状況に十分なかなり簡単な解決策がある可能性は十分にありますが、それはあなたが何をしようとしているかに詳細に本当に依存しているため、それが何であるかを伝えることはできません。

実装の多くを多くのSQLクエリに可視化する必要がある場合、これを行うのはかなり困難ですが、選択した戦略は可能な限りカプセル化することを強くお勧めします。

返信が非常に散らばっていて、「依存する」ことに満ちていることを申し訳ありませんが、実際のデザインの質問はそのようなものです。

前の回答者（あなたが質問で言及した回答者）からの提案は非常に良いものだと思います。

StackExchangeサイトにリンクを投稿するのと同じように動作しますが、情報データは別のテーブルにあります。利点は、データが分離されているため、クエリとインデックスが可能なことです。テキストの編集時に、削除されたメタデータIDを確認し、メタデータテーブルを消去できます。

あなたが言ったような唯一の小さな問題は構文解析ですが、あなたはそれをかなり簡単に扱うことができます。

テキストがあるとしましょう：

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単語（chars（c）、sentences（s）、paragraps（p）など）にまたがります。もちろん、正確な構文は異なる場合があります。

プレーンテキストエディターでは、Markdownの脚注と同様に、ノートのテキストをドキュメントの最後に簡単に保存できます。

リッチテキストエディターでは、この種のメモをテキストとしてアイコンとして表示でき、マークされたテキストを何らかの方法で強調表示できます。ユーザーは、DelまたはBackspaceで通常の文字と同様にそのようなメモを削除し、何らかの特別な編集モードで編集できます。マウスでメモ領域のサイズを変更し、ポップアップウィンドウでメモテキストを編集することを想像します。

長所：

• オフセット（テキスト内のノートの位置によって暗黙的に）と各ノートの長さをマークするため、「交差点」とうまく調和します。
• マルチユーザー環境をサポートします。（実際、これにはさらに深い研究が必要であり、おそらくあなたは私の脳が処理できないGoogle Waveの運用変換のようなものに対処する必要があるでしょう。）
• リッチテキストエディターとプレーンテキストエディターの両方で編集できます。
• すべてのマーカーがインプレースであるため、リビジョンを簡単に処理できます。マーカーの前のテキストを編集すると、マーカーは他のテキストとともに移動します。
• 解析が簡単。
• 外部DBは必要ありませんが、必要に応じて使用できます。
• 控えめな構文を選択する場合、MarkdownまたはXMLと混合できます。

プレーンテキスト編集の短所：

• メモでマークされたテキスト内の領域は表示できません（オプションであるプレーンテキストをハイライトしない限り）が、メモが始まる場所だけが表示されます。これは、任意の長さの単位（文字、単語、文、段落）を選択する機能によって補償されます。
• 特にノートが非常に長い場合（2段落以上など）、ノートの下のテキストを気付かずに編集できます。各ノートの下のテキストを以前のバージョンと比較し、変更された場合にユーザーに通知する改訂制御メカニズムによって補正できます。

一般的な短所：

• 複数のユーザーが同じテキストを編集する際のトラブルですが、とにかく避けられないと思います。私はこの分野の専門家ではありません。