DB設計を語るスレ - 暇つぶし2ch

DB設計を語るスレ at DB

845:NAME IS NULL
08/06/01 01:18:03
>>835
それって主キーをIDにして、別途自然キーにユニーク制約つけとけばいいんじゃないの？

846:NAME IS NULL
08/06/01 18:33:29
CASE文にサブクエリ書くのは汚いSQLになる

847:NAME IS NULL
08/06/01 22:18:01
CASEによる

848:NAME IS NULL
08/06/02 14:54:08
case by case と言って欲しかった

849:NAME IS NULL
08/06/02 20:51:43
だれがうまいことを

850:NAME IS NULL
08/06/26 23:19:26 9Bdxxe1P
質問です。通常は多対一（一対多）なんだけれども、例外的に多対多になる場合は
どの様に対応されているのでしょうか？
例えば社員と部署を考えてみると、一般的にその関係は多対一ですが、現実には
複数の店舗を掛け持ちしたりとかで多対多になるケースもあるとかです。
きっちりやるなら関連テーブルを作って対応ってことなんでしょうけど、
実際には多対一で設計して運用で対応してるのが多いんじゃないのかな？って疑問です。
どうなんでしょう？

851:NAME IS NULL
08/06/26 23:46:24
それを言うなら、「多対多で設計して運用(あるいはアプリ側)で対応」じゃないの？

852:NAME IS NULL
08/06/27 00:04:55
>>851
レアケースで多対多になる場合は、関連テーブルを作っているのでしょうか？
というのが主旨の質問です。この例ですと、多対一の設計にして、社員を重複登録等にして
関連テーブルを作成しない対応をするのが多いのでは？というものです。

853:NAME IS NULL
08/06/27 00:06:24
>>850
兼任してるのがすごい稀なら、ダミーの社員作って対応してる例はあったよ。

ダミーの社員には元の社員の社員番号 + 追い番付けといて、

select * from 社員テーブル where 社員番号 like 'xxxxx%'

みたいにして全ての所属部署を取得するとかしてた。

854:NAME IS NULL
08/06/27 00:28:40
>>853
レスありがとうございます。
すいませんが取り込んでしまいましたのでレスは後ほどいたします。

855:NAME IS NULL
08/06/30 07:02:58
「例外」をノーマルとして扱うものを最初から設計するのがシステム作りの基本。
このケースでは「多対多」でつくる。
そのほうがシンプルな構造になるし、あとあとの管理も楽。

部署コード＋社員コードからなる担当テーブルを作るってことになるのかな？

ただし、「例外」を実装するのにコストがかかるケースでは別途考える。

856:NAME IS NULL
08/06/30 22:15:57
>>855
> 「例外」をノーマルとして扱うものを最初から設計するのがシステム作りの基本。

費用対効果とかトレードオフって知ってる？

857:NAME IS NULL
08/06/30 22:21:10
N:1だろうとN:Nだろうとなんでもかんでも
関連テーブル作っておけばいいよ。

858:NAME IS NULL
08/06/30 22:45:04
>>856
基本N:1の設計に例外でN:Mサポートを作りこむのと、最初からN:Mの設計に
通常N:1とする制約を作りこむのとでどっちがコストが低いのかという話だろ。
で、費用対効果というものを知っているとどっちの結論になるの？

859:NAME IS NULL
08/06/30 22:58:06
>>858
いや、つっこまれてるのはその話じゃなくて、最初の1行目でしょ。
この場合、関連テーブル作っておくなんて「例外」でもなんでもない。
「エンティティ」って言葉の通りだよ。

860:NAME IS NULL
08/06/30 23:01:54
>>858
> で、費用対効果というものを知っていると

状況も考慮せずに、「どっちの結論になるの？」なんてバカなことを言わなくなる。

861:NAME IS NULL
08/06/30 23:08:00
>>856
その下に、
> ただし、「例外」を実装するのにコストがかかるケースでは別途考える。
って書いてあるのが目に入ってないのは何故だ。

862:NAME IS NULL
08/06/30 23:45:27
そんなものは別途考えるんじゃなくて、最初に考えることだから。

863:NAME IS NULL
08/07/01 01:00:21
一部のデータだけが多対多、なんてのを例外扱いするのがまず違和感。

その上、例外をノーマル扱いするのが基本、って言い方すれば
コスト意識ねーなーってつっこまれるのもしかたない。

まあ気持ちは一緒なんだと思いますよ。言葉のあやみたいなもんかと。

864:NAME IS NULL
08/07/01 01:14:39
はい、言葉のあやです。
スキップ！スキップ！

865:NAME IS NULL
08/07/01 03:00:36
「例外的に」としてしまうのは素人
客が「レアケースだから」と無意識に無いことにしてしまっているのを引き出す仕事なのだから、この意識は重要だと思う