＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
設計：ＲＤＢのテーブル設計で金額／数量にNull可
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-03-11 20:16
自分はむしろ、プログラム内でできるだけ何でも記述したい方です。
DBは他システムと共有することなどもありますし、誰でも簡単に変更できますし。 列情報をXMLなど外部ファイルで定義しておく、などの対策もありますが、 「テーブルがNULL不可だからNULLチェックなしで演算」なんてコードがあると 気になって仕方がないです。 Javaプログラマなので、jarの中に入らないところに依存するのが気持ち悪いというのも あるかもしれません。 [追記] まとまりがなかったため追記。 本題の、DB設計時にNULLのない列をNULL不可にすることには大賛成です。 ただ、それをあてにしたコーディングはあまりしません。（たんなる私見です） [ メッセージ編集済み 編集者: taro 編集日時 2004-03-11 20:30 ] | ||||||||
|
投稿日時: 2004-03-11 20:39
そう言われると自信無いです。 
プログラミング言語だと空文字列とnullは区別するのが当然ですから、 Oracleが特別、なんだと思ってましたが、別にSQL Serverとかを調査した わけではないですし･･･。 「Oracleが部分的にサポートする（＝完全にサポートしていない）ANSI SQLの仕様」 の中に 「nullと空文字列を区別しない」 が含まれていることは確認しましたが。 （OracleのSQLリファレンスマニュアルの後ろの方に載ってます） | ||||||||
|
投稿日時: 2004-03-11 21:06
# 本題からちょっと逸れて、「値省略に0かNULLか」のお話です。
文化の違いなんでしょうか・・・ >業務アプリ（特に機関系）では数値、金額が集計対象となる事が多いので >一般的に省略の意味でも０を設定するアプリケーションが多いのですが、 私も業務アプリの開発が多いですが、「省略の意味で０を設定する」ってちょっと考えられません。 今まで「真に０」なのか「値無し」なのかわからなくて困った事がないなら、それははにまるさんの運が良かった（他の列の情報を見たら0か値無しかわかる構造に”たまたま”なっていた）のだと思います。 『それでは困る』という場面に出くわして初めてNULLを許容する、なんてやり方だと、 「NOT NULL制約は『「真に０」なのか「値無し」なのかわからなくて困るかどうか』で決まる」という、お世辞にも美しいとは言えないルールが出来てしまいます。 正道はやはり”列単体で見て、NOT NULLである必然性があるかどうか”でしょうね。 | ||||||||
|
投稿日時: 2004-03-11 21:54
確かにNOT NULLのフィールドに空文字("")をINSERTすることはできませが、強引にchr(0)をINSERTすることができます。ただしこれをSELECTするとNULLに変換されます。不思議ですけど。 | ||||||||
|
投稿日時: 2004-03-12 14:56
はにまるです。
sauceさんの仰る通り、金額や数量で省略と０と切分けの必要性が無かったので 今回の投稿になりました。 ん．．多分、想定している項目が異なるのかな？ と思い一歩踏み込んで。 「省略の意味で０を設定する」の「省略」は、御客様にとっての省略の意味です。 厳密に言うと、金額や数量はビジネス上、重要な意味を示しますので 本当の省略は無いと考えています。 前投稿通りで、私は基幹系をメインとしています。 伝票、実績集計などで数量や金額の省略値がNullというのは過去ありません。 ただ、単価のNullはありますが、 この単価を省略する場合、「数量×単価→金額の計算をしない」仕様が付きます。 これは、システム機能として明記される為、問題視していません。
「必須項目だから」と「数値項目でNull値は障害を起こす要因となる」で NOT NULL制約に求める設計理由は異なります。 ここが考えの差異かな？ | ||||||||
|
投稿日時: 2004-03-12 15:32
わたしも以下のような用件があった場合はNULLを使用していました
どちらかというと省略というよりは使用しないという意味です 数量、単価、金額があった場合 金額がNULL以外の場合、金額をそのまま使用 金額がNULLの場合、数量×単価を金額として使用 金額、単価がNULLの場合、数量×マスタに登録されている単価を金額として使用 集計などに実際使う金額は上記の判断するユーザ関数を使用する（SQL Server） まぁNULLは本当に必要でない限り使わないほうがいいというのは賛成です。 SQLServerの場合、文字列でもNULLと空文字を区別しているのでなおさらです | ||||||||
|
投稿日時: 2004-03-18 09:20
かなり乗り遅れてしまいましたが．．．
金額／数量のテーブル項目についてNullを許可するのは仕様上の理由であれば 有り得ますね。 Null値の演算ロジック内エラーの可能性についてはありますが、それはNull値 に限ったことではなく、プログラムの仕様によって他にも存在します。 ０ ： 0割が発生する場合（分数の分母になる時） マイナス値 ： ロジックのエラーでは無いですが業務上有り得ない場合 小数 ： 金額には小数は入ることは少ないですが、単価や外貨を扱うと必要に なります。 Null ： GUIで使用者が意図的に０を入力したのか、入力していないのか を区別する必要がある場合等 ある閾値 ： これを越えると業務上おかしいとか。別の項目との相関関係で判断 することも。 というような、テストでは「限界値テスト」と呼ばれるところで、テストケースに上がる 数値ですね。 数値項目の場合、SQLの文法上Nullというのは他とはコーディングが異なるので意識 されているのだと思いますが、これも上に書いたNull以外の値と同じように意識して 設計する必要がありますね。 | ||||||||
|
投稿日時: 2004-03-18 10:29
おはようございます。てけつくです。
私も金融系のシステム経験が多いですが、殆ど全て Beatleさんのご説明通りかと。 フィールドの詳細な状態を把握したいのでNULL、マイナス値、その他も可とし、 それを考慮した状態把握のロジック、演算などを行う、という感じです。 確かに煩雑ですし、色々と制約は付けて楽したいところですが、最近の金融系の ユーザさんはシステムの事よく解ってらっしゃるので、出される要求もかなりシビアです。 まぁ、考えてみればはにまるさんがおっしゃるような設計が一番楽なんでしょうけど、、、 なんだろう、楽できない所にばかり突っ込まれてたのかなぁ
| ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.