0

現時点では、flags 列挙型を持つ Schoolyear というビジネス オブジェクトがあります。

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

私にとって、これは識別子のない値オブジェクトであり、余分な SQL テーブルを取得しません。これもやり過ぎでしょう。

ここで、これらの可視日 (ユーザーが構成できる) を int 値としてデータベースに保存することを考えました。現時点では機能しますが、データベースでの読み取り/書き込み、およびそれらの値のビジネスオブジェクトへの読み取り/書き込み、およびそのオブジェクトとの統合テストの実行は苦痛です。

JavaScriptクライアントがjsonデータを消費しているので、今朝、ブラウザから直接取得したjson配列をjson文字列としてデータベースに保存しないと思いました。したがって、私がしなければならない唯一のことは、クライアント側の json.parse です。サーバー側で統合テストを行うには、json ライブラリの既存の json.serialize/deserialize メソッドを使用します。

目に見える日は、年に1、2、または3回しか変更されません。ユーザーごとに、5 年間で 5 学年のデータ行があり、それ以上ではないかもしれません。可視日数列は、SQL 選択を介してクエリされることはありません。UI ロジックはクライアント側で行われます。

したがって、json配列をjson文字列としてsqlデータベースに保存することをお勧めします。

私の新しいアプローチについてどう思いますか? 後でもう一度悔い改めることができる、私が考えていなかったマイナスの副作用が見られますか.. ?

4

1 に答える 1

5

リレーショナル データベースのテキスト フィールドに JSON を配置しない理由:

  1. JSON フィールドのデータに依存するクエリを実行できなくなります。
  2. データを SQL エンジンに記述しないため、アプリケーション/サーバー コードは、データを検証し、データが破損した場合に動作できることを確認する責任があります。

リレーショナル データベースのテキスト フィールドに JSON を配置する理由:

  1. 効率 (JOIN は遅くなる可能性があり、フィールド内のデータを使用してクエリを実行する必要がないことがわかっている場合は、それを可能にする方法でデータを保存する必要はありません)。
  2. 実装を簡素化します (クライアントが有効な JSON 文字列を提供したことを (サーバー上で) チェックするようにしてください)。
于 2014-01-19T12:42:12.860 に答える