【より良い】データモデリング【モデルを】 (542レス)
1-

160: 04/10/08 07:13 ID:??? AAS
担当1・担当2のようになるなら繰り返し。
最大値が決まってるというのは幻想で、実は今だけってのが現実
161
(1): 04/10/08 07:15 ID:??? AAS
最大値を制限するのはプログラム側でなくDBのトリガや制約等の機能を利用し
て制限するのが普通
162: 04/10/08 07:16 ID:??? AAS
とにかくやつらにプログラムさせるな、が基本
163
(2): 04/10/08 07:52 ID:??? AAS
>>161
ユーザーにやさしくエラーを返してあげるためにプログラム側での工夫も必要?
164: 04/10/08 10:05 ID:h796f5Km(1) AAS
>>163
それはこっちでちょっと話題になったな

制約っていらなくね?
2chスレ:db

悩みどころだね。
165
(2): 04/10/09 01:08 ID:??? AAS
>163
制約エラーが発生すればエラーメッセージを出すようにはプログラムする
普通のエラー処理のある言語なら問題なく可能
制約でのエラーの方がプログラムをほぼしなくて済むので良い

とにかくやつらと、そしてわたしにプログラムさせるな、が基本である事にかわりない
プログラムは組めば組むほどバグが増加する物、それはだれが作成してもだ
166
(2): 04/10/09 14:07 ID:WoYiUuS/(1) AAS
>>165
C/Sの業務アプリなんかだとそう理想どおりいかないんですわ。

例えば、必須項目の入力チェックをする時に、
エラー表示を閉じたら自動的に
未入力の入力欄にフォーカスを移動して欲しいって
要望があった場合、アプリ側でチェックせんといけない、
NOT NULL制約のエラーだけに頼れないんですよ。

とはいえ、制約はそれをみればドキュメントが貧弱だったとしても
設計した人の意図が浮き上がりやすいので捨てがたい。

で、制約・アプリ両方盛り込むと二重管理になる。
省1
167: 04/10/09 16:04 ID:??? AAS
アプリ側でのバリデーションなんてWebだろうが業務アプリだろうが当然すると思うけど
DB側の制約(CHECKとかNOT NULLとか)は制約内容とDB設計者の好みに寄る希ガス

漏れはビジネスルール的なものであればアプリ側でかけさせて
それ以外はなるべくDB側でかけさせるようにしてるかなあ
まあ、NOT NULLなんかは二重管理になりがちだけど
168: 04/10/09 16:12 ID:??? AAS
ユーザーに返すエラーメッセージを「不正な処理を行ったため停止します」に統一
すればいいんじゃない?
169
(1): 04/10/10 13:02 ID:??? AAS
>>166
DBMSの制約情報を動的に読みとってアプリ側でチェックするような仕掛けを
作ればいいのでは?
結局は二重だけどDBMS側をいじればアプリ側も追従してくるようにすれば
目的は達成できる気がする。
170: 04/10/10 14:11 ID:??? AAS
それやるとアプリのDBMS依存性が高くなる
 ↓
ライブラリ/ミドルウェア層にまとめちゃおう
 ↓
だったらDBMSの制約情報読み取るよりも、最初からこっちで
管理した方が融通が利いて良いよな

SAPとかそんな感じだよね
171: 165 04/10/10 19:39 ID:??? AAS
>166 >169
わたしの所はあるアプリでDB定義を書くのだが、そこからSQLと
Valid用XMLが自動生成されるようになっている
172
(2): 04/10/17 20:38 ID:gvma0fXW(1) AAS
DB設計ビギナーです。
相談に乗ってください。

たとえば次のようなテーブル群があるとします。
部署(部署ID, 部署名)
社員(社員ID, 社員名)
所属履歴(所属履歴ID, 部署ID, 社員ID, 所属開始年月日, 所属終了年月日)

社員は時を経るにつれて所属が変わるのですが、
これは所属履歴レコードを1件追加することで示します。

ここで、経年するごとに次のような変化がおきます。
・部署名が変わる
省11
173: 04/10/18 01:10 ID:??? AAS
合併した部署は、新しいIDを振ればいいのでは?
174: 04/10/18 09:55 ID:??? AAS
>>172
一般的な方法として、やるとしたら(2)だけど、本当にそこまでする必要が
あるのかどうかって所が一番大事だと思われ
175
(3): 04/10/18 16:18 ID:??? AAS
先生
名前・メールアドレス・パスワード・他色々

生徒
名前・メールアドレス・パスワード・担当先生・他色々(先生と全く同じパラメータ)

という構成の場合どういう設計にすべきですか?

(1)
先生
先生id(主キー),名前,メールアドレス・パスワード,他色々

生徒
生徒id(主キー),名前,メールアドレス・パスワード,先生id(外部キー:先生->先生id),他色々
省15
176: 04/10/18 16:19 ID:??? AAS
(3)間違えたので修正

人id(主キー),名前,メールアドレス・パスワード,他色々

先生
人id(主キーかつ外部キー:人->人id)

生徒
人id(主キーかつ外部キー:人->人id),先生id(外部キー:先生->人id)
177: 175 [age] 04/10/18 16:19 ID:??? AAS
すいませんがageさせて頂きます。
178
(1): 04/10/18 16:53 ID:??? AAS
>>175
(4)
179
(1): 04/10/18 18:17 ID:??? AAS
>>178
具体的にはどんな感じですか?
1-
あと 363 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.007s