長い文字列をデータベースに保存する必要があります。文字列の長さは5または6文です。これは良い設計戦略だと思いますか?または、その文字列のIDを保存してから、文字列を保存しているファイルの場所を含む別のテーブルとの関係を作成する必要があります。両方の長所と短所を教えてください。
文字列は前処理され、データベースに保存されています。変更を加えると、文字列全体が読み取られ、完全に置き換えられます。したがって、文字列は分割できないと見なすことができます。
長い文字列をデータベースに保存する必要があります。文字列の長さは5または6文です。これは良い設計戦略だと思いますか?または、その文字列のIDを保存してから、文字列を保存しているファイルの場所を含む別のテーブルとの関係を作成する必要があります。両方の長所と短所を教えてください。
文字列は前処理され、データベースに保存されています。変更を加えると、文字列全体が読み取られ、完全に置き換えられます。したがって、文字列は分割できないと見なすことができます。
文字列をデータベースに保存しても問題ありません。代わりにファイル ポインターを保存する場合、文字列を読み取るたびにファイル I/O を実行する必要があります。いくつかの文はそれほど長くはありません。必要に応じて、いつでもロングテキスト データ フィールドを使用できます。テキストがあるため、明らかにデータベースは少し大きくなりますが、問題ありません。ファイルを保存するよりも、確かに優れた代替手段です。
あなたが言及した文字列はまったく長くありません。
あなたが「長い」文字列に言及したとき、私は 32kB 以上について考えていました -- 一部の文は 1kb 未満です -- 今日では何もありません。
Id を保存すると、間接アクセスを行う必要があるため、処理が遅くなります。
私がお勧めする唯一のことは、最大のパフォーマンスが必要な場合は、必要な列のみを選択する必要があることです (SELECT * を省略します)。サーバーからアプリケーションへの文字列の転送にはコストがかかるため、不要な場合はテキスト列を省略します。最も時間。必要のない列には触れないことをお勧めします (特に、列に多くのデータが含まれる可能性がある場合)。
別のテーブルを作成する唯一の理由は、それらの長い文字列が多くのレコードで同じになる場合です。それ以外の場合は、見返りを提供する可能性が低い単なる余分な複雑さです.
5 つか 6 つの文は、最新の DBMS にとっては何の意味もありません。テキストをデータベースに直接保存します。
(あなたが言及した他のテクニック - それ自体がテキストを保持する外部ファイルへの参照を持つ別のテーブルへの参照を格納することは、使用するのがはるかに面倒で、パフォーマンスがはるかに低下します。)
答えは、実際には、保存する予定の文字列の量と、それを保存するために使用する予定のDBによって異なります。多くの文字列を保存していない場合は、それらをXMLまたはリソースファイルに保存し、それをアプリケーションに事前にロードすることを検討してください。ただし、文字列データがたくさんある場合は、最終的に使用しない文字列をメモリに読み込むよりも、必要なときに必要なときに文字列を読み取る方がよいでしょう。
データベース自体は、長い文字列を格納することに実際の問題はありません。いくつかの制限が適用されます(SQL Serverの8kレコードサイズ制限など)が、適切なものはすべて実質的に上限のないBLOB / TEXTデータ型をサポートするため、データベースに任意の長さのテキストを格納できます。
5〜6文はそれほど長くはありません。それらが一緒に属し、全体として取得および操作することを目的としている場合は、先に進んで、適切なディメンションのCHARデータ型フィールドに格納できます。
それらを分離してIDを付加するかどうかという問題は、アプリケーション/データモデルがこのアプローチから直接利益を得る場合にのみ発生します。つまり、実際にはそれらは別個のものです。あなたの場合、そのようにする理由はないようです。
パフォーマンスについては誰もが言及していますが、OS ファイルへのポインタを保存することが良くないもう 1 つの主な理由であるバックアップとリカバリについては誰も言及していません。すべてがデータベースにある場合、データをバックアップするための単一のメカニズムと、回復のための単一のメカニズムがあります。一方、OS 上のファイルには、おそらく 2 つの異なる粒度で 2 つの異なるバックアップ メカニズムがあり、リカバリは同期の悪夢になります。
これが当てはまらないケースもいくつかあります。たとえば、トランザクションの頻度が非常に低く、やり直しやトランザクション ログがなくても存続できるデータ ウェアハウスなどです。
特別な場合を除いて、私はそれがある場所にフィールドを残します。
他の唯一のオプションは、文字列を別のテーブルに配置することです(実際の文字列をそこに配置します)...それらを別々のファイルに配置すると、パフォーマンスが低下します。