長い文字列をデータベースに保存するのは良いですか？

Question

長い文字列をデータベースに保存する必要があります。文字列の長さは5または6文です。これは良い設計戦略だと思いますか。または、その文字列のIDを保存してから、文字列を保存するファイルの場所を含む別のテーブルとの関係を作成する必要があります。 両方の利点と欠点を教えてください。

文字列は前処理され、データベースに保存されています。変更すると、文字列全体が読み取られ、完全に置き換えられます。そのため、文字列は分割できないと想定できます。

Answer 1

データベースに文字列を保存しても問題ありません。代わりにファイルポインターを格納する場合、文字列を読み取るたびにファイルI / Oを実行する必要があります。いくつかの文はそれほど長くないので、必要に応じていつでもロングテキストデータフィールドを使用できます。テキストがあるので、データベースは明らかに少し大きくなりますが、それでも構いません。確かに、ファイルを保存するよりも優れた代替手段です。

Answer 2

言及する文字列はまったく長くありません。

<！> quot; long <！> quot;を参照したとき文字列、私は32kB以上について考えていました-一部の文は<！> lt; 1kbです-今日は何もありません。

IDを保存すると、間接的にアクセスする必要があるため、処理が遅くなります。

最高のパフォーマンスが必要な場合、私がお勧めする唯一のものは、必要な列のみを選択する必要があります（SELECT *は省略します）-サーバーからの文字列の転送のため、不要な場合はテキスト列を省略しますアプリケーションに最も時間がかかります。不要な列（特に列に多くのデータが含まれている可能性がある場合）に触れないようにするのが良い方法です。

Answer 3

別のテーブルを作成する唯一の理由は、これらの長い文字列が多くのレコードで同じになる場合です。それ以外の場合は、余分な合併症であり、見返りが得られない可能性があります。

Answer 4

5つか6つの文は、現代のDBMSには何の役にも立ちません！テキストをデータベースに直接保存します。

（テキストを保持する外部ファイルへの参照を持つ別のテーブルへの参照を保存する他の手法-使用するのがはるかに面倒で、パフォーマンスがはるかに劣ります。）

Answer 5

答えは、保存する文字列の量と、保存に使用するDBによって異なります。多くの文字列を保存していない場合は、XMLまたはリソースファイルに保存し、それをアプリケーションに事前に読み込むことを検討してください。ただし、文字列データがたくさんある場合は、使用しないメモリに文字列を読み込む機会をとるよりも、必要に応じて文字列をメモリ単位で読み込む方がよいでしょう。

Answer 6

データベース自体には、長い文字列の保存に関して実際の問題はありません。いくつかの制限が適用されます（SQL Serverの8kレコードサイズの制限など）が、それでもすべての適切なものが上限なしでBLOB / TEXTデータ型をサポートするため、データベースに任意の長さのテキストを格納できます。

5〜6文はそれほど長くありません。それらが一緒に属し、全体として取得および操作することを意図している場合は、先に進み、適切なディメンションのCHARデータ型フィールドに格納できます。

それらを分離してIDを添付するかどうかは、アプリケーション/データモデルがこのアプローチから直接恩恵を受ける場合にのみ発生します。つまり、実際にはそれらは別個のものです。あなたの場合、そうする理由はないようです。

Answer 7

誰もがパフォーマンスについて言及していますが、OSファイルへのポインターを保存することが悪い考えである他の主要な理由、つまりバックアップとリカバリーについては誰も言及していません。すべてがデータベース内にある場合、データをバックアップするための単一のメカニズムと回復のための単一のメカニズムがあります。一方、OS上のファイルでは、おそらく2つの異なる粒度で2つの異なるバックアップメカニズムがあり、リカバリは同期の悪夢になります。

トランザクションが非常にまれであり、REDOまたはトランザクションログなしで存続できるデータウェアハウスなど、これが適用されないケースがいくつかあります。

Answer 8

特別な場合を除き、フィールドはそのままにします。

他の唯一のオプションは、文字列を別のテーブルに入れることです（実際の文字列をそこに入れます）...それらを別々のファイルに入れるとパフォーマンスが低下します。