目前我将 JSON 存储在我的数据库中，因为VARCHAR(max)它包含一些转换。我们的一位技术人员要求存储转换后的原始 JSON。
恐怕如果我添加另一个 JSON 列，它会增大页面大小并导致访问时间变慢。另一方面，这个表不会很大（最多大约 100 行，每个 JSON 列占用 4-6 K 字节）并且每分钟可以访问多达 4 或 5 次。
我是一个无情地滥用我们的技术的小气守门人，还是一个保持系统可扩展性的睿智架构师？
另外，我对（相对）新的文件流/BLOBs 类型很好奇。从我读到的内容中，我感觉 BLOB 存储在某个单独的位置，因此关系查询根本不会减慢速度。将 varchar 切换到文件流有帮助吗？
通常 BLOB 优先用于存储的平均大于 1 MB 的对象。
我认为您应该擅长将它们保存在同一个数据库中。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 的 table 选项，因为它是未来兼容的，并且不推荐使用 text in row 选项。本质上，这些选项将那些大型文本字段存储在主页之外，允许正确的数据存在于它需要存在的地方，并且额外的 STUFF 有一个不同的家。