長い文字列をデータベースに格納する必要があります。文字列は5または6文の長さにすることができます。これは良いデザイン戦略だと思いますか？その文字列のIDを格納してから、その文字列を格納しているファイルの場所を含む別のテーブルとの関係を作成する必要があります。 両方の長所と短所を教えてください。長い文字列をデータベースに格納するのは良いですか？
文字列は前処理されてデータベースに格納されています。変更があれば、文字列全体が読み込まれ、完全に置き換えられます。その文字列は分割できないとみなすことができます。
それはすべきですデータベースに文字列を格納するためには問題ありません。代わりにファイルポインタを格納すると、その文字列を読み込むたびにファイルI/Oを実行する必要があることを意味します。いくつかの文章はそれほど長くはありません。必要に応じて、長い文章のデータフィールドをいつでも使用できます。テキストがあるのでデータベースは少し大きくなりますが、それは問題ありません。それは確かにファイルを保存するよりも良い選択肢です。
5〜6文は現代のDBMSには何もありません！テキストをデータベースに直接格納します。
（あなたが言及した他の技術 - 自身がテキストを保持している外部ファイルへの参照を持っている別のテーブルへの参照を保存するには - 。使用することをはるかに面倒なことや多くの貧しいパフォーマンスを持っているでしょう）
「5〜6億円の文が最新のDBMSには何もありません！ – Xeoncross
私は別のテーブルを作成する唯一の理由は、それらの長い文字列が多くのレコードで同じになる場合です。そうでなければ、それはちょうど補充を提供する可能性のない余分な合併症です。
これらの長い文字列は異なります。私はあなたのポイントを理解し、別のテーブルを使用する必要はありません。私はファイルシステムに文字列を格納し、データベース内のファイルへのポインタを保持するか、文字列をデータベース自体に格納する必要があります。パフォーマンスに基づいた提案。 –
@iamrohitbanga：だから、どれくらい*正確には？何キロバイト（これはテキストのためにかなり多い）までのものは、データベースに保存することができます。その制限を超えるものは*まだ*大丈夫ですが、DBMSが提供するTEXTデータ型を使用する必要があります。パフォーマンス上の理由からファイルシステムにファイルを置くという考えは、私にとっては意味があります。 – Tomalak
@iamrohitbanga：これらの文字列は実際には重要なサイズである必要がありますが、10Kの倍数を話しています。 – AnthonyWJones
答えは本当にあなたが格納しようとしている文字列の量と、それを格納するために使用する予定のDBに依存します。多くの文字列を格納していない場合は、それらをXMLファイルまたはリソースファイルに格納し、アプリケーションに読み込むことを検討することをお勧めします。しかし、多くの文字列データがある場合は、文字列をメモリに読み込むチャンスを取るのではなく、必要に応じて文字列を読み出す方がよいでしょう。
データベース自体は、長い文字列を格納する上で実際の問題はありません。いくつかの制限が適用されます（SQL Serverの8kレコードサイズ制限など）。しかし、それでもすべての適切なBLOB/TEXTデータ型は実質的に上限を持たないため、任意の長さのテキストをデータベースに格納できます。
5〜6文は実際には長くありません。それらが一緒に属していて、全体として取り出され操作されることになっている場合、適切な次元のCHARデータ型フィールドにそれらを格納することができます。
これらを分離してIDを付けるかどうかは、アプリケーション/データモデルがこのアプローチから直接利益を得る場合、つまり実際には別のものである場合にのみ発生します。あなたの場合、そのように行く理由はないようです。
特別な場合を除いて、私はフィールドをそのまま残します。
他の唯一のオプションは、文字列を別のテーブルに配置することです（実際の文字列をそこに置く）。別々のファイルにそれらを配置すると、パフォーマンスが低下します。
あなたが言及している文字列はまったく長くありません。
「長い」文字列に言及したとき、私は32kB以上を考えていました。文章の一部は< 1kbです。これは今日は何もありません。
あなたが間接的にアクセスする必要があるので、IDを格納することは物事を遅くします。
最高のパフォーマンスが必要な場合は、必要な列のみを選択する必要があります（SELECT *を省略）。不要な場合はテキスト列を省略します。サーバーからアプリケーションに最も多くの時間がかかります。それは良いプラクシスであり、必要のない列に触れることはありません（特に多くのデータが含まれている場合）。
誰もがパフォーマンスについて言及していますが、誰もOSファイルへのポインタを格納することがバックアップと復元という悪い考えです。すべてがデータベースにあれば、データをバックアップするための単一のメカニズムと、回復のための単一のメカニズムがあります。 OSのファイルには2つの異なるバックアップメカニズムがありますが、おそらく2つの異なる粒度であり、復旧は同期の悪夢になります。
データウェアハウスなど、これは適用されないトランザクションが非常に少ないため、再実行ログやトランザクションログがなくても存続する場合があります。
これは、実際にSQLにTEXTタイプ（oh、およびCLOB）がある理由です。 – Powerlord