1

私のデータベースには、Organization、User、OrganizationUserJunctionの3つのテーブルがあります。OrganizationUserJunctionテーブルは、ユーザーが所属する組織、ユーザーが組織のメンバーになったとき、およびユーザーが組織を離れたときを追跡します。MemberFromフィールドには既知の日付が入力されていますが、MemberToの日付は最初は不明です。テーブルにNULL値を含めるのは好きではありません。

文字列フィールドを処理しているときは、NULLではなく「UNKNOWN」を入力できます。日時列についても同様のことをしたいと思います。値が不明なSQLServer日時列を処理するための、null以外の優れた戦略は何ですか？

4

6 に答える 6

4

あなたが説明した例を取るために。現在のメンバーにはMemberTo日付がないため、メンバーシップの表ではMemberTo日付は必要ありません。MemberTo日付を元メンバーのテーブルに入れます（これには、現在のメンバーには適用されない、元メンバーシップに関連付けられたこの属性とその他の属性が含まれます）。これを行うためにnullは必要ありません。

于 2013-04-17T09:30:03.080 に答える
3

他の誰も言及していない別の方法は、2つの日付列に別々のテーブルを使用することです。（再読すると、他に類を見ない@sqlvogelがこれについて言及していることがわかります。コードを例として残しておきます。@ sqlvogelがそれを彼の回答に組み込みたい場合は、私が賛成しましたが、それで問題ありません。後で私の答えを削除してください。）

create table org_users (
  org_id integer not null references organizations (org_id),
  user_id integer not null references users (user_id), 
  member_from date not null default current_date,
  primary key (org_id, user_id, member_from)
);

create table org_users_member_to (
  org_id integer not null, 
  user_id integer not null,
  member_from date not null,
  member_to date not null default current_date
    check (member_to > member_from),
  primary key (org_id, user_id, member_from),
  foreign key (org_id, user_id, member_from) 
    references org_users (org_id, user_id, member_from)
);
于 2013-05-16T10:36:12.207 に答える
2

これは正当な質問であり、なぜあなたが反対票を投じられたのかわかりません。

少なくともJoeCelkoによると、正解は9999-12-31をendDateとして使用することです。これは、ISO8601に準拠した公式の「時間の終わり」です。

この目的のために設計された6番目の通常の形式（別名アンカーモデリング）の使用を検討することもできます。

于 2013-04-16T06:49:40.160 に答える
1

何が問題になっていNULLますか？それが重要である実際の理由（たとえば、彼が死んでいるため、またはまだキャプチャしていないためのNULL心拍数）の場合は、別の列で追跡します（おそらく、テーブルと呼ばれるルックアップテーブルにFKします）。NULLtinyintdbo.DateIsNULLReasons

これに対するすべての回避策（「魔法の」日付値、可能な列を持っているNULLか、代わりに魔法の日付を格納する必要がある別のテーブルを検索するすべての日付にINTを使用する）は、私にはハックのようです。

嫌いなものを乗り越えればいいと思いますNULL。それらは、値がunknownであると指定する、好きかどうか、理由に関係なくなどの理由で存在します。

UNKNOWN代わりに保存することで何が得られますNULLか？テーブルとセカンダリインデックスでどれだけの余分なスペースが必要か知っていますか？特定のクエリに対してそのシナリオを除外する必要があるのは面倒ではありませんか？

于 2013-03-26T18:58:12.940 に答える
1

メンバーレビューにデフォルトの日付を使用するのはどうですか。入社してから5年と言います。

または、私たちが企業組織と取引していて、生年月日と性別を把握している場合は、定年を計算できます。

個人的には、NULLの問題は見られません。MemberTo dateのコンテキストでは、ISNULL=まだメンバーです。これは、デフォルト値とまったく同じ目的を果たし、入力されるデフォルトの日付値よりもはるかに複雑ではありません。

于 2013-03-26T19:30:01.293 に答える
0

これが古いスレッドであることは知っていますが、私はそれに遭遇しました。

nullこれは、特にの場合、避けるべき良い点ですDateTime。

理由：SQLサーバーのデフォルトは。nullのようなもの1/1/1900です。のようなユースケースがある場合はdateOfCasuality、DOB関連のルールを処理するための特別なロジックを含める必要があります。

考えられる解決策：ForeignKey日付を含む別のテーブルとの関係を使用します。しかし、それはスキーマの複雑さを増します。ただし、コーディングの悪夢につながるため、文字列に変換しようとはしません。

于 2020-03-15T18:58:47.703 に答える