VARCHAR(max)現在、いくつかの変換が含まれているため、データベースに JSON を保存しています。当社の技術者の 1 人が、変換元の元の JSON を保存するよう求めています。
別の JSON 列を追加すると、ページ サイズが肥大化し、アクセス時間が遅くなるのではないかと心配しています。一方で、このテーブルはそれほど大きくなく (JSON 列ごとに 4 ～ 6 K バイトを使用し、最大で約 100 行)、1 分間に 4 ～ 5 回アクセスされる可能性があります。
私は技術者を容赦なく悪用するケチなゲートキーパーなのか、それともシステムのスケーラビリティを維持する賢明なアーキテクトなのか?
また、(比較的) 新しいファイルストリーム/BLOB タイプにも興味があります。私が読んだことから、リレーショナル クエリの速度がまったく低下しないように、BLOB が別の場所に格納されているように感じます。varchar を filestream に切り替えると役立ちますか?
一般に、格納されるオブジェクトが平均して 1 MB を超える場合は、BLOB が推奨されます。
それらを同じデータベースに保持するのは良いことだと思います。100 行はデータベースにはあまりありません。
また、元の JSON と変換された JSON を保持するユースケースは何ですか。元の JSON が通常の処理の一部として使用されず、参照のために保持する必要がある場合は、別のテーブルを保持し、そこに元の JSON を参照キーと共にダンプし、必要な場合にのみ元の JSON を使用することをお勧めします。
あなたのユースケースは、あまり需要がないように思えます。4 ～ 6KB で、100 行未満、さらには 1000 行未満でも、まだかなり軽量です。予想されるユースケースが実際のユースケースになることはほとんどありません。人々が JSON フィールド以外の目的でテーブルを使用する場合、潜在的なサイズと不要な肥大化のために、JSON をプルバックしたくない場合があります。
幸いなことに、SQL には他にも複雑ではないオプションがいくつかあります。https://msdn.microsoft.com/en-us/library/ms173530(v=sql.100).aspx
将来の互換性があり、行内のテキスト オプションは非推奨であるため、Large Value Types out of Row のテーブル オプションを確認することをお勧めします。基本的に、これらのオプションはこれらの大きなテキスト フィールドをプライマリ ページの外に格納し、正しいデータを必要な場所に配置し、余分な STUFF を別の場所に配置できるようにします。