0

我有一个名为 Schoolyear 的业务对象，目前有一个 flags 枚举：

[Flags]
public enum VisibleDayOfWeek : int
{
    None = 0,
    Monday = 1,
    Tuesday = 2,
    Wednesday = 4,
    Thursday = 8,
    Friday = 16,
    Saturday = 32,
    Sunday = 64
}

对我来说，这是没有标识符的值对象，它们没有额外的 sql 表。这也将是矫枉过正。

现在我考虑将这些可见日期（用户可以配置）保存为数据库中的 int 值。它目前可以工作，但是在数据库中读/写并将这些值读/写到业务对象中并与该对象进行集成测试是很痛苦的。

因为我有一个使用 json 数据的 javascript 客户端，所以今天早上我想为什么不将我从浏览器直接获取的 json 数组保存为数据库中的 json 字符串。所以我唯一要做的就是客户端的 json.parse 。为了在服务器端进行集成测试，我使用了 json 库中现有的 json.serialize/deserialize 方法。

可见天数在一年中仅更改 1,2 或 3 次，并不经常。每个用户每 5 年有 5 个学年数据行可能不多。永远不会通过 sql select 查询可见天数列。UI 逻辑在客户端完成。

所以对我来说，将 json 数组作为 json 字符串存储在 sql 数据库中是一个好主意。

你觉得我的新方法怎么样？你有没有看到我没有想到的任何负面影响，我以后可以再次悔改......？

4

1 回答 1

5

不将 JSON 放在关系数据库的文本字段中的原因：

  1. 您将失去执行依赖于 JSON 字段中数据的查询的能力。
  2. 由于您没有向 SQL 引擎描述您的数据，因此您的应用程序/服务器代码有责任验证数据并确保在数据损坏时它可以正常工作。

将 JSON 放在关系数据库的文本字段中的原因：

  1. 效率（JOIN 可能很慢，如果您知道永远不需要使用字段中的数据进行查询，则不需要以允许的方式存储它）。
  2. 简化实现（只需确保您（在服务器上）检查客户端是否为您提供了有效的 JSON 字符串）。
于 2014-01-19T12:42:12.860 回答