4

問題の文字列は (料理) レシピの説明フィールドであり、最大長は 99% のユーザーが遭遇することのないものでなければなりません。nvarchar(4000) はおそらく制限が多すぎるようです。

SQL テーブルの列は、これに適した場所ですか? このような (潜在的に) 大きな値をこのようなフィールドに格納するのは適切ではありませんが、そうではないでしょうか?

それが重要かどうかはわかりませんが、.NET 3.5 はおそらく LINQ2SQL を使用する予定です。

編集: VS Express Database Explorer を使用してテーブルを作成すると、4000 が nvarchar の最大サイズであることがわかります (オプションとして varchar がリストされていないようです)。これは SQLCE の単なる制限であり、何か他のことを調べる必要があることを示していますか?

これが SQLCE の制限であることが本当なら、他の推奨事項はありますか? ペットプロジェクトの場合、私は何か無料で、できればセットアップが簡単でなければなりません (できれば私とエンドユーザーの両方にとって望ましいですが、エンドユーザーにとってセットアップが簡単であることがより重要です)。データベースはローカルであり、パフォーマンスはそれほど重要ではありません。

4

6 に答える 6

5

既存のレシピについて何か研究したことはありますか? varchar(4000) は約 400 ～ 500 語を提供します。私が持っている多くのクックブックのレシピの多くは、それより長い説明を持っているとは思えません。

VarBinary は 8000 バイトを取得しますが、説明フィールドで varbinary を使用して検索を行う場合は、パフォーマンス ヒットを引き起こすキャストまたはその他の操作が必要になる可能性があります。

最後に、私はこれが特に好きではありませんが、説明を別のテーブルに正規化して、1 対多の関係を設定し、レシピに複数の説明部分を持たせて、インターフェースで再組み立てすることができます。 .

于 2009-04-05T02:31:24.487 に答える
1

必ずしも推奨されるわけではありませんが、思いついたので提供します。

一度保存されたテキストがめったに変更されない場合は、次のようなテキストの「行」を保存する新しいテーブルを作成することを検討してください。

recipe_id integer,
line_number integer,
line_text nvarchar(80)

または、レシピのテキストを検索する必要がない場合は、単純な圧縮アルゴリズムはどうですか? ハフマン エンコーディングは、テキストに対してかなり効果的であり、CPU をそれほど集中的に使用することはありません。

于 2009-04-05T09:22:27.010 に答える
0

ntext は 50 万文字を格納できるため、最善の策です。これが小さすぎる場合は、行を分割するなどの他のソリューションと組み合わせることができます。

https://technet.microsoft.com/en-us/library/ms172424.aspx

SQL コンパクトでは最大データベース サイズが 4GB であることを覚えておく必要があります。したがって、これらのレコードを多数保存する場合は、別のデータベース タイプに移行することをお勧めします。

于 2015-10-28T17:07:20.933 に答える
0

もう 1 つの方法は、テキストをファイルとして保存することです。データベースにはファイル名のみが保存されます。

于 2011-02-18T17:06:04.037 に答える
-1

ほとんどの SQL データベースは、大きな VARCHARS 列と TEXT 列に対してこれを自動的に実行できるほどスマートです。行の作成時に大きな列にスペースを割り当てるのではなく、各行のデータは、(最大サイズではなく) 実際の内容よりもわずかに多くのスペースしか占有しないような方法で格納されます。

于 2009-04-05T02:23:41.477 に答える
-1

SQL CE を使用したことはありませんが、VARCHAR(MAX) データ サイズをサポートしているかどうかを確認してください。基本的に、800K 行サイズ制限の範囲外の大量のテキスト (最大 2GB) を格納しますが、' = ' やその他の WHERE 句演算子も使用できます (TEXT データ型は LIKE のみをサポートしました)。

于 2009-04-05T02:28:30.310 に答える