記事やその他の大きなテキストをデータベースに保存する方法
私は現在、データベース主導のウェブサイトを設計している最中です。主な理由は学習目的のためですが、私は嘘をつきません、少量の虚栄心が含まれています！
私のデータベース設計は今のところかなり良いと思いますが、記事や他の大きなテキストを保存する最良の方法についてはまだ完全にはわかりません。ほとんどのDBMSがTEXTデータ型または同等のデータ型を持ち、大量のテキストを保持できることを知っています。ただし、記事全体を1つの長い文字列として保存すると、読みづらくなるため、書式設定が必要になります。
すべてのHTMLタグまたはBBcodeタグと一緒に記事のテキストを保存しますか？それとも、HTMLまたはXMLドキュメントでページを作成し、このファイルへのパスをDBに保存する方が良いですか？
記事をカスタムドキュメントで簡単にマークアップし、PHPのXMLおよびXSLT関数を使用してXMLをHTML [またはその他の形式]に変換できるため、記事をXMLドキュメントとして保存するというアイデアがとても気に入っています。また、作成者が改行/改ページを作成するタイミングを指示することもできます。このアプローチはもちろん追加のコーディングを必要とします（私は恐れていません）が、記事を検索可能にすることには問題があります。
たとえば、MySQLには、テキストフィールドに保持されている文字列内の特定の語句を検索するためのSQL構文があることを知っています。テキストを個別のファイルに保存する場合、これらの記事を検索可能にするにはどうすればよいですか？
このような単純な質問について私がここで書いたことはかなりたくさんあるので、それを分解します。
1：大量のフォーマット済みテキストをデータベースに直接保存する「最良の」方法はありますか、または
2：HTML/XML/Whateverドキュメントの形式でそのテキストへのパスを保持する方が良いでしょう。
2の場合、そのテキストを検索可能にするエレガントな方法はありますか？
あなたの時間をありがとう:)
アレックスが提案したように、すべてを1つの大きなテキストフィールドに格納します。検索については、データベースを傷つけないでください。出力のインデックスを作成するには、 Lucene または htdig を使用します。この方法で検索は非常に高速です。副作用は、検索を検索エンジンにやさしくすることです。キーワードフィールドを（バックスラッシュが示唆するように）取り、それらをmeta-keywords属性に貼り付けます。
編集する
キーワードだけを検索しているのでない限り、dbに検索を行わせるのはひどく遅くなります（フォーラムを検索したことがあり、それは永遠にかかりますか？）。データベースにインデックスを付ける方法はありません
select.. where FULLTEXTFIELD like '%cookies%'.
記事を探すのは面倒で、キーワードフィールドになかったため、検索しても検索結果が返されません。 Htdigを使用すると、記事の全文を効率的に検索できます。検索はすぐに戻り、記事のすべての用語が完全に検索可能です。キーワードをメタタグに入れると、結果ページでそれらの用語の検索が高くなります。
別の利点は、あいまい一致です。 「アクティブ化」を検索すると、htdiggはアクティブ、アクティブ化、アクティビティなど（構成可能）を持つページに一致します。または、ユーザーが単語のスペルを間違えても、一致します。ユーザーにGoogleのような体験をしてもらいたいのです。迷惑な体験ではありません。 :)
データベースからすべてのページへのリンクのリストを作成するには、スクリプトが必要です。 htdigがこれを自動的にクロールするようにすれば、再び考える必要はありません。
また、htdigはデータベース以外のページもクロールするため、サイト全体を同じシンプルなインターフェースで検索できます。
キーワードフィールドについては、 すべき 記事のIDとキーワードフィールド（1行に1つのキーワード）を含む、keywordsという別のテーブルがあります。ただし、簡単にするために、dbに単一のフィールドを含めることはひどい考えではありません。フォームに入力すると、キーワードの更新が非常に簡単になります。
面倒なことをすべてやりたくない場合は、 Googleカスタム検索 を使用してみてください。作業量ははるかに少なくなりますが、すべてのページがインデックスに登録される保証はありません。
幸運を！
TEXT、BIGTEXT、LONGTEXTおよびその他のデータ型フィールドは、大量のテキスト（RDBMSに応じて64Kバイトから4Gバイト）を格納するために作成されました。データベース内のテキストを見つけるためのバイナリポインタを作成するだけで、テーブルに直接格納されません。ドキュメントを見つけるためにvarcharフィールドにパスを格納する場合もほとんど同じ手順ですが、データベースにパスを置くと、他の手順で行を削除しなくても行が削除されるとドキュメントが消えるため、維持が容易になります。 （まるでファイルとして保存したかのように）。論理的には、これによりデータベースが大きくなり、場合によってはバックアップと転送がそれほど簡単ではなくなりますが、ドキュメントを1つずつ転送するのは面倒で時間がかかります。
ご覧のとおり、データベース内のドキュメントと行の数によって異なります。
検索手順については、検索を高速化するために、新しい「キーワード」フィールドを作成することをお勧めします。文書の最初のn文字も検索して、それらをCHARまたはVARCHARとしてキャストし、特定のフィールドがない場合は、タイトルとサブタイトルをこれらの量に配置できます。
すべての配置方法やインストール方法によっては、DBに正常にアクセスできるリモートクライアントから外部ファイルにアクセスするのが難しい場合があります。代わりに、すべてのXMLを1つのTEXTフィールドに保存してみませんか？ DBエンジンがその負荷を適切に処理できない場合は、後でリファクタリングして最適化できますが、それが最も簡単な方法です。
ネイティブXML DBをざっと見てみましょう。いくつかあり、とても良いものは無料です。
EXist、Document xDB、Oracle Berkeleyを検索してください。
半構造化テキストを永続化、クエリ、および更新していて、構造に深さがある場合、ポインタのRDBまたはstuff-it-in-a- blobテクニック-これらのアーキテクチャが必要であり成功することができる多くの外部の理由があります。
設計に取り掛かる前に、XPathとXQueryについて少し読んでください。ここから始めるのが良いでしょう： https://community.emc.com/community/edn/xmltech