C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[2]: 汎用(システム共通)テーブルって駄目ですか？

(過去ログ 28 を表示中)

[トピック内 13 記事 (1 - 13 表示)]　 << 0 >>

■12881 / inTopicNo.1)

　汎用(システム共通)テーブルって駄目ですか？

□投稿者/ やじゅ (18回)-(2008/01/19(Sat) 17:20:41)

分類:[データベース全般]　

masabunさんの「システム共通テーブルは嫌いですか？」参照
http://blogs.wankuma.com/masabun/archive/2008/01/18/118159.aspx

言葉としては、「汎用マスタ」としますが、
消費税率コード/性別コード/敬称コード/端数処理/法人種類などを
用途の違うコードなどを一つにまとめてしまう方法です。

Ognacさんのコメントを引用：http://blogs.wankuma.com/ognac/archive/2007/08/20/91115.aspx
「コード体系が固定で要素が数件のテーブル類は独立して存在させるのが悪であると錯覚しているようです。
汎用機のマスター設計の伝承で「変化のあるテーブルは独立させるのが良いが、要素が数件で内容が変化
しないテーブルはマトめるべし」というのがあったとか。」

私的には、正規化して別々のテーブルにするほどでもないという古い考えですが
テーブルがたくさん増えると管理が面倒ではないのかという考えもあり
わざわざ、小さいテーブルに分ける必要はあるのでしょうか？

ＳＱＬを書くとしても、私は使いやすいようにＳＱＬのユーザー関数を定義して、
分類コードと項目などを渡せば値を返すものを作成して使っています。

例
Select
T.C1_CODE,GetCodeItem('JSH',T.C1_CODE,'Name') C1_NAME
T.C2_CODE,GetCodeItem('ZEI',T.C2_CODE,'Name') C2_NAME
from TranData T

汎用的に定義するため無駄な項目(例 str1,str2,str3,num1,num2,num3)があるのは
確かですが、コスト面を考慮してもこの程度なら問題になるほどのこともないはず

小さいテーブルに分ける意味ってなんでしょうか、ご参考までにご教授ください。

引用返信 編集キー/

■12914 / inTopicNo.2)

　Re[1]: 汎用(システム共通)テーブルって駄目ですか？

□投稿者/ シャノン (265回)-(2008/01/21(Mon) 01:16:14)

■No12881 (やじゅさん) に返信

> 私的には、正規化して別々のテーブルにするほどでもないという古い考えですが

まったく関連のないデータであれば、分けることは正規化ではないと思います。

> テーブルがたくさん増えると管理が面倒ではないのかという考えもあり

たとえば、どういう事態が起こりうるから面倒なのでしょう？

> 小さいテーブルに分ける意味ってなんでしょうか、ご参考までにご教授ください。

逆に問うと、まとめることの利点とは何なのでしょうか？

ちなみに、俺は、そもそも関連のないデータをまとめる理由がないので分ける派です。

引用返信 編集キー/

■12919 / inTopicNo.3)

　Re[2]: 汎用(システム共通)テーブルって駄目ですか？

□投稿者/ VOW (1回)-(2008/01/21(Mon) 02:10:57)

私も小さいテーブルはどんどん作ってしまってもかまわない派。

>私的には、正規化して別々のテーブルにするほどでもないという古い考えですが

引用返信 編集キー/

■12920 / inTopicNo.4)

　Re[3]: 汎用(システム共通)テーブルって駄目ですか？

□投稿者/ VOW (2回)-(2008/01/21(Mon) 02:13:42)

すみません。途中で送信してしました。

>私的には、正規化して別々のテーブルにするほどでもないという古い考えですが

逆に将来的に大きくなって、別々のテーブルにせざるをえなくなった時の事は考えないのですか？
それはそのときに別々のテーブルにすればよいということでしょうか？

引用返信 編集キー/

■12930 / inTopicNo.5)

　Re[1]: 汎用(システム共通)テーブルって駄目ですか？

□投稿者/ よねＫＥＮ (110回)-(2008/01/21(Mon) 11:44:40)

2008/01/21(Mon) 11:47:44 編集(投稿者)

■No12881 (やじゅさん) に返信
> masabunさんの「システム共通テーブルは嫌いですか？」参照
> http://blogs.wankuma.com/masabun/archive/2008/01/18/118159.aspx
>
> 言葉としては、「汎用マスタ」としますが、
> 消費税率コード/性別コード/敬称コード/端数処理/法人種類などを
> 用途の違うコードなどを一つにまとめてしまう方法です。

私が今まで見てきたある程度の規模の案件では、名称は違えどこういう用途のテーブルはありましたね。

　汎用マスタ、名称マスタ、等々。

で、まとめられているからといってさして困ったことはないので、そんなに問題かな？と個人的に思います。

何でもかんでも入れていいマスタというわけではなく、
プログラムで定数や列挙型を使うのと同様のシステム都合で用意しているマスタだからだと思います。
このマスタから情報取得をするための共通機能も用意するので、
プログラムやデータベース構成の変更なく、微妙な文言変更や微妙な大人的事情による仕様変更への対応が可能です。
(というか可能なように設計してありました)

こういうマスタが用意されるのは、ちょっとした機能追加等、コストをかけたくない部分のために、
新たな名称や名称のグループを増やすたびに、マスタを増やしたくないというのが理由でしょうね。
もちろん、汎用マスタの用途・役割を逸脱したような内容で汎用マスタを利用するのはまずいですし、
その基準が曖昧になりがちだという闇の部分はあります。

<修正>
改行位置、文体等を修正
</修正>

引用返信 編集キー/

■12932 / inTopicNo.6)

　Re[2]: 汎用(システム共通)テーブルって駄目ですか？

□投稿者/ 黒龍 (93回)-(2008/01/21(Mon) 12:32:35)

ん～とまずテーブル(つかエンティティ)というのは事象の記録、保存それから値の組み合わせを管理。それらの情報の捕捉の3パターンに分けられます。で、マスタってのは値の組み合わせに関する制限を設けるものと言えると思います。なもんで型で表現できるバリエーション以外は基本作るもんだと思ってます。例えば性別などどっちかに必ず設定するならbitで切り分け不要ですがおかまとか秘密とかを認めるならnchar(1)とかにしてマスター化みたいな感じですね。
で、まとめちゃうと値自体は含んでくれるが参照制約として中途半端という形になります。プログラムからの制御も出来なくなるので今度はマスタ種別とかの列を足してプログラムで制御するんですが制約は相変わらず脹れないまんまだしプログラムでの対応が必要になります。分ける場合はメリットが多いのですがまとめてテーブル数を減らすことに対して支払うペナルティ(デメリット)があまりに多すぎるんです。
マスタメンテ画面が爆発するってんならマスタ画面こそ共通化したほうがメリットある気がしますです。

引用返信 編集キー/

■12933 / inTopicNo.7)

　Re[2]: 汎用(システム共通)テーブルって駄目ですか？

□投稿者/ やじゅ (19回)-(2008/01/21(Mon) 12:51:13)

2008/01/21(Mon) 13:12:46 編集(投稿者)
2008/01/21(Mon) 12:57:36 編集(投稿者)

■No12914 (シャノンさん) に返信
> ■No12881 (やじゅさん) に返信
>
>>テーブルがたくさん増えると管理が面倒ではないのかという考えもあり
>
> たとえば、どういう事態が起こりうるから面倒なのでしょう？
>
>>小さいテーブルに分ける意味ってなんでしょうか、ご参考までにご教授ください。
>
> 逆に問うと、まとめることの利点とは何なのでしょうか？
>

よねＫＥＮさんの書かれている通り、
「プログラムで定数や列挙型を使うのと同様のシステム都合で用意しているマスタ」
の意味合いが強いので、

分類CDと内容CDと名称と並び順とその他(拡張用)の項目分けとなっています。
BUNRUI_CD ,NAIYO_CD,HYOJI_NM,SORT,SRT1,SRT2,SRT3,NUM1,NUM2,NUM3,BIKO
HASU_PROC_KBN,1,四捨五入,1
HASU_PROC_KBN,2,切り捨て,2
HASU_PROC_KBN,3,切り上げ,3
KAZEI_KBN ,1,課税,1
KAZEI_KBN ,2,非課税,2
KAZEI_KBN ,3,対象外,3
SEX_KBN,1,男,1
SEX_KBN,2,女,2

今のプロジェクトでも現時点で８５種類に分類されています。
これをそれぞれ小さいテーブルに分けると８５種類のテーブル数が増えることになり
管理が面倒ってことなんですが･･･
(数が増えれば、それだけ管理するのが大変になってくるから)

そういった用途であっても、小さいテーブルに分ける必要ってあるのかなー。

引用返信 編集キー/

■12934 / inTopicNo.8)

　Re[4]: 汎用(システム共通)テーブルって駄目ですか？

□投稿者/ やじゅ (20回)-(2008/01/21(Mon) 13:01:51)

■No12920 (VOW さん) に返信
> すみません。途中で送信してしました。
>
> >私的には、正規化して別々のテーブルにするほどでもないという古い考えですが
>
> 逆に将来的に大きくなって、別々のテーブルにせざるをえなくなった時の事は考えないのですか？
> それはそのときに別々のテーブルにすればよいということでしょうか？

そうですね、基本的には仕様が固まっているので大幅に変更はない上で作成していますが、
汎用マスタでまかなえない程度になってしまったら、その項目だけは、別々のテーブルに
変更せざるえませんね。

引用返信 編集キー/

■12935 / inTopicNo.9)

　Re[3]: 汎用(システム共通)テーブルって駄目ですか？

□投稿者/ Ognac (5回)-(2008/01/21(Mon) 13:44:14)

Ognacです。以前こんな事がありました。
性別/消費税率/端数処理/敬称などは数件しかデータが存在しません。汎用テープルで実装しているシステムがありました。
型付DataTableを採用して、明示的Bindingで記述することになりました。(是非はともかく)
型付DataTableを使うときは対になるクラスを生成してくれます、汎用項目の型付テーブルだと、置換部分はハードコーディングになるのでメリットか飛びます。どうするのかなぁと眺めていたら、性別View,消費税View,端数処理Viewなどn種類のViewを実装してました。"同数のViewを作るほうがコスト高いやん" と感じたものでした。
メリットはソースに変換コードを記述しない分スッキリすることだと思うのですが。

引用返信 編集キー/

■12974 / inTopicNo.10)

　Re[2]: 汎用(システム共通)テーブルって駄目ですか？

□投稿者/ やじゅ (22回)-(2008/01/22(Tue) 12:48:02)

■No12930 (よねＫＥＮさん) に返信
> 2008/01/21(Mon) 11:47:44 編集(投稿者)
>
>>言葉としては、「汎用マスタ」としますが、
>>消費税率コード/性別コード/敬称コード/端数処理/法人種類などを
>>用途の違うコードなどを一つにまとめてしまう方法です。
>
> 私が今まで見てきたある程度の規模の案件では、名称は違えどこういう用途のテーブルはありましたね。
>
> 　汎用マスタ、名称マスタ、等々。
>
> で、まとめられているからといってさして困ったことはないので、そんなに問題かな？と個人的に思います。
>

今回の例でいえば、自分も特に問題はないなと思っておりますが･･･
外部との接触が少ないので、違う意見が出てくると、そのやり方がいいのか迷うところがあります。

引用返信 編集キー/

■12975 / inTopicNo.11)

　Re[3]: 汎用(システム共通)テーブルって駄目ですか？

□投稿者/ やじゅ (23回)-(2008/01/22(Tue) 12:52:15)

■No12932 (黒龍さん) に返信
> で、まとめちゃうと値自体は含んでくれるが参照制約として中途半端という形になります。プログラムからの制御も出来なくなるので
>今度はマスタ種別とかの列を足してプログラムで制御するんですが制約は相変わらず脹れないまんまだしプログラムでの対応が必要になります。
>分ける場合はメリットが多いのですがまとめてテーブル数を減らすことに対して支払うペナルティ(デメリット)があまりに多すぎるんです。

確かにマスタ種別とかの列を足すと、参照制約は出来なくなってしまいますね。
参照制約は使ったことがないんですが、これはデメリットですね。

引用返信 編集キー/

■12976 / inTopicNo.12)

　Re[4]: 汎用(システム共通)テーブルって駄目ですか？

□投稿者/ やじゅ (24回)-(2008/01/22(Tue) 13:03:19)

■No12935 (Ognac さん) に返信
> Ognacです。以前こんな事がありました。
> 型付DataTableを使うときは対になるクラスを生成してくれます、汎用項目の型付テーブルだと、
> 置換部分はハードコーディングになるのでメリットか飛びます。どうするのかなぁと眺めていたら、
> 性別View,消費税View,端数処理Viewなどn種類のViewを実装してました。"同数のViewを作るほうがコスト高いやん" と感じたものでした。
> メリットはソースに変換コードを記述しない分スッキリすることだと思うのですが。

それぞれにViewを作成するなら、別個に分けても同じですね。
ハードコーディングをしない方向の開発が、今後の流れなんでしょうか。

引用返信 編集キー/

■12977 / inTopicNo.13)

　Re[3]: 汎用(システム共通)テーブルって駄目ですか？

□投稿者/ まどか (436回)-(2008/01/22(Tue) 13:18:37)

> 今のプロジェクトでも現時点で８５種類に分類されています。
> これをそれぞれ小さいテーブルに分けると８５種類のテーブル数が増えることになり
> 管理が面倒ってことなんですが･･･
> (数が増えれば、それだけ管理するのが大変になってくるから)
>
> そういった用途であっても、小さいテーブルに分ける必要ってあるのかなー。

数に対する管理ならその場の事情でいいんじゃないでしょうか。
あえてデメリットを言うなら、
・汎用項目(名)なので仕様が見えない。また、区分ごとの意味のある無しがわからない。
・長さ等もいわゆる十分な大きさになるため、テーブル側での仕様における歯止めが弱くなる。
・ある区分に付随項目が増えた場合、空いている適当な項目(名)を使ってしまう。(リリース後)
といったところでしょうか。

引用返信 編集キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可