06/01/10 21:22:34 emDEfEEV
すみませんが、質問です。
ユーザの追加オプションを管理する、以下のようなテーブルがあります。
ユーザID オプションID 制限回数
00001 1 12
00001 3 15
00001 4 NULL
...
ユーザIDで検索すると、利用できる追加オプションの一覧が取得できるのです
が、オプションの種類によっては、利用できる回数に制限があります。そして、
・オプションID 1, 2, 3 については、必ず制限回数を指定する必要がある。
・オプションID 4, 5 については、制限回数は要らない。
（仮に指定しても使われない）
このようなテーブルで、誤った組み合わせ
（例） 00001 1 NULL
のような挿入を防ぎたいのですが、どうしたら良いでしょうか？
今ままでも、CHECK制約を使えば、誤った組み合わせの挿入は避けられますが、
オプションIDの即値というマジックナンバーをCHECK制約に埋め込みたくあり
ません。できれば正規化で対応したいのですが。
101:NAME IS NULL
06/01/11 01:19:44
俺的には、テーブルの作り自体は現行で最善な感じがする。
マジックナンバーがいやなら、チェックはアプリケーションロジックでやるとか。
トータルコスト考えて、どこで妥協するかって話だと思う
102:100
06/01/11 12:25:56 VpUtuDIC
>>101
やはりそう思われますか…。トータルコストを考えると、どんな用件に対して
も正規化が可能なわけではないということでしょうか。
マジックナンバーがイヤなのは、オプションのマスタテーブルのレコード追
加・削除に伴って、>>100のユーザテーブルのCHECK制約を書き換えなければな
らないからです。
オプションのマスタテーブルに、制限回数が必要かを示すフラグを、カラムと
して用意すれば、マジックナンバーに頼らなくても済みます。しかし、使用DB
がPostgreSQLなので、CHECK制約で外部テーブルを参照できないのです。
アプリの側でチェックすれば、外部テーブルを参照することもできます。しか
し、いかにも煩雑です。
うーん、やっぱり正規化を諦めるのはつらいなあ。
103:100
06/01/11 12:29:38
外部テーブルという言い方は変ですね。単に、別テーブルという意味です。
URLﾘﾝｸ(www.postgresql.jp)
>現在、CHECK 式には、副selectや現在の行の列以外の値を含むことはできません。
104:NAME IS NULL
06/01/13 01:03:49
>100
オプション4,5 では何を指定しても使われないなら、NOT NULL にして4,5を挿入するときは適当に
0でも入れておけばいいんじゃないの? DEFAULT 0 とかつけてやったりして。
105:NAME IS NULL
06/01/13 03:04:52
>>104
そうやっても 00001 1 0 という誤挿入を防ぐことはできない罠。
106:NAME IS NULL
06/01/13 06:31:18
>105
0 がないとすると、残り1回のまま永久にオプションを使い続けられることにならない?
107:100
06/01/13 11:29:00 TppsOzrm
>>105
説明不足ですみません。カラム「制限回数」は、ゼロを入れる予定は（NULLの
代用でない限り）ないんです。
オプションサービスが利用されると、別テーブル（利用状況記録テーブル）に
新規レコードが挿入されます。そのレコード数と制限回数を比較して、超過を
チェックしております。
だから、カラム「制限回数」の数字がだんだん減る、という使われ方ではあり
ません。
さらに言えば、この制限回数は、月ごとのトータル回数なので、現在月の利用
回数（レコード数）と、カラム「制限回数」を比較します。来月はまた同じ値
の「制限回数」と比較する必要がありますから、このカラムの値を減らしては
いけないんです。
以上、補足でした。
108:100
06/01/13 11:30:11
あ、リンクを間違えました。× >>105 → ○ >>106
109:NAME IS NULL
06/01/13 19:37:09
>>107
アプリで管理すればいいやんとは思うが正規化スレなので正規化で考えると、
ユーザID、オプションID、制限回数のち制限回数には回数とそれを使うかどうかの情報が含まれている。
この制限回数を使うかどうかの情報を分離して回数制限フラグと呼ぶこととする。
回数制限フラグはオプションID毎に決まっており推移的関数従属であるためそれを排除して第３正規系にする。
で答えはオプションIDマスタを作ってそこに制限回数フラグを持つべしということになる。
110:100
06/01/13 22:01:07 TppsOzrm
>>109
ありがとうございます。
ただ、私は、>>102の後半に、かなり似た内容を書いておりまして、それと
どう違うのか、良くわかりません…。
111:NAME IS NULL
06/01/14 00:03:14
>>110
制限回数はnot null にしてユーザーに常に数字を入れさせるということ。初期値ゼロでもよい。
表を参照するときに連結して問い合わせるVIEWを作っておくとよい。
select a.ユーザID, a.オプションID, CASE b.制限回数フラグ WHEN 1 THEN a.制限回数 ELSE NULL END as 制限回数
from テーブル a join オプションIDテーブル b on (a.オプションID = b.オプションID)
これで制限回数を使わないケースでは今までどおりNULLが帰ってくる。
check制約をつけることを正規化とは言わないといいたかったのだが、
同等なことをしたいならトリガーなり更新用のストアドなり作って違反した場合に例外を起こさせることはできる。
処理系で方法は違うだろうけど。
112:100
06/01/15 14:40:37 iP9+MlmJ
>>111
ありがとうございます。返答が遅くなってすみません。
NOT NULL制約を付けるということですが、これだけでは 00001 1 0 といった
誤挿入を防ぐことはできません。オプションID 1, 2, 3 に対しては、NULL と同
様に 0 も不適なのです。
ならば1以上のみを許容するようにすればいいかと言うと、今度はオプションID
4,5に対して、使われもしない数値を入力する義務ができてしまい、やはり良い
設計とは思えません。
本来ならcheck制約でもっとキメ細かい入力値のチェックをできたら良かったの
ですが、PostgreSQLの機能の制約でできませんでした。
ここで、check制約の代りに、トリガを使えば良い、というのは盲点でした。ト
リガというと更新系の動作をさせることしか頭にありませんでした。これならど
んな複雑なチェックでもできます。ありがとうございます。
なお、私はcheck制約と正規化を混同してはいません。check制約が使えないから、
正規化で対応したいと言っていたつもりでした。まずい説明ですみません。
113:100
06/01/15 14:42:47 iP9+MlmJ
ところで、頂いたレスを読み返しているうちに、あることに気づき、そして正規
化のアイディアを思いつきました。
> 制限回数には回数とそれを使うかどうかの情報が含まれている。
とのことでしたが、もっと言えば、このユーザオプション管理テーブルの内容自
体に、2種類の異なったタプルが混在しているのです。つまり、
00001 1 12
00001 3 15
の、3要素のタプルと、
00001 4
の、2要素のタプルとです。
この要素数の異なったタプルが混在しているのが問題の元だったのです。
そこで、このテーブルを、1, 2, 3を入れる3カラムのテーブルと、4, 5を入れる
2カラムのテーブルとに分けます。
同時に、オプションマスタも、1, 2, 3 のマスタと、4, 5のマスタに分け、それ
ぞれのユーザオプション管理テーブルに外部キー制約をつけ、ユーザオプション
管理テーブルの内容が混在しないようにします。
そして、ユーザごとのオプション一覧を1回で取得するために、2つのユーザオプ
ション管理テーブルを UNION でつないだビューを作ります。
しかしこれだと、二つのオプションマスタに共通のオプションIDが入ってしまう
危険があります。そこで、両者のIDを共通のシーケンスから自動採番するように
し、ID番号の重複を防ぎます。
以上です。またあまり分かりやすくない説明ですみません。
ややトリッキーですが、皆さんはどう思われるでしょうか？
114:NAME IS NULL
06/01/15 19:51:17
>>113
それなら>>111の設計の方がきれいだと思うぞ。
PostgreSQLならこういう技も使えるが。
create table user_master (
user_id number primary key
)
create table option_master (
option_id int primary key,
option_class int not null -- 1なら制限なし 2なら制限あり
)
create unique index option_master_class_idx on option_master (
option_id,
option_class
);
create table user_option (
user_id number not null,
option_id int not null,
foreign key ( user_id )
references user_master(user_id),
foreign key ( option_id )
references option_master( option_id ),
primary key ( user_id, option_id )
)
create table user_option_limit (
user_id number not null,
option_id int not null,
option_class int not null,
option_limit int not null,
primary key ( user_id, option_id ),
foreign key ( user_id )
references user_master( user_id ),
foreign key ( option_id, option_class )
references option_master( option_id, option_class ),
check ( option_class = 2 ),
check ( option_limit > 0 )
)
>>100の結果が欲しい場合はuser_optionとuser_option_limitを
outer joinするか、そういうviewを作っておく。
115:NAME IS NULL
06/01/16 00:46:38
初心者にありがちな考えすぎ
116:NAME IS NULL
06/01/24 10:05:52 eUiSn8SR
すいませんが、教えてください。
とあるシステムを解析する事になったのですが、テーブルの設計で分からないところがあります。
内容は下記のようなテーブルで枝構造になっています。
部門テーブル
部ID , 主キー
部門名
部課連携テーブル
部ID
課ID , 部IDと課IDでキー、課IDはユニーク
課テーブル
部ID
課ID , 部IDと課IDでキー、課IDはユニーク
課名
その他課情報項目
グループ連携テーブル
部ID
課ID
グループID, 部ID,課IDとグループIDでキー グループIDはユニークでない
グループテーブル
部ID
グループID, 部IDとグループIDでキー グループIDはユニークでない
こんな感じです。グループ連携テーブルとグループテーブルでなぜ同じキーを使わないのか、
また、なぜグループテーブルで部ID+グループIDなのか。
何か設計上のテクニックがあるのでしょうか
117:NAME IS NULL
06/01/24 13:12:15
>>116
歴史的経緯がいろいろありそうなテーブルですね。
課IDのところの説明を間違ってなければ、
課を複数の部に所属させることができるようにしようとした痕跡がありますね。
結局それは取りやめて部課連携テーブルは使ってない可能性が高いな。
（または課テーブルの部IDを使ってない可能性あり）
グループ＋部IDとグループIDでユニークで、課とグループはｎ：ｎの関係。
グループ連携テーブルはそのｎ：ｎの関係をあらわすためにある。
118:NAME IS NULL
06/01/24 14:32:17
>>117
なるほど。どちらかというと熟考して出てきたテーブルではなく、過去からの成り行きでこのように
なっている感じなのですね。私が使うとき課とグループがn:nにはならないと思いますので、自分な
りにアレンジして再構築します。ありがとうございました。
119:NAME IS NULL
06/01/24 23:52:14
おいおい、ちゃんとヒアリングしろよ・・・
120:NAME IS NULL
06/03/06 02:47:55
正規化しないで作った事とかないんですが、どうしてもテーブル構成なんかを考えてる時間がないんです。
1テーブルでむりやり作っちゃうってのは実際のとこ「あり」ですかね？
121:NAME IS NULL
06/03/06 11:04:40
>>120
あなたのその後の人生をそのシステムに捧げる覚悟があるならば「あり」かもしれない。
122:NAME IS NULL
06/03/06 23:05:20
>>121
ないです。つか、保守とか以前にぽしゃる悪寒＞そのサイト
123:NAME IS NULL
06/03/07 00:48:26
俺はありありだと思うなー。
とりあえずは動けば何でも良いよ
124:NAME IS NULL
06/03/09 23:59:15
>>123
結局1テーブルで全部くんでしまった。
やたらとtextのフィールドが多い・・・
もうしらね。全部のフィールドを検索対象にしてやる。
やけくそでやれば終るもんだ。あとはcssまわりだけ。
125:NAME IS NULL
06/03/10 00:08:53
>>124
自分でいいならいいんじゃね？
レコード数多くなければ全列の全走査でも
なんとかなるさｗ
126:124
06/03/11 01:53:53
基本的なとこは組み上がったからUIまわりをajaxでかっこいくしてたら暗唱に乗り上げた。悔しいがヤメることにする。一日ロスしたorz
127:NAME IS NULL
06/03/13 00:18:21
T字型ERって業務でやってる人居る？
ネットに全然情報ないし、本買わないといけないかな。
128:NAME IS NULL
06/03/13 23:00:16
出向に行ったら表記法がT字型だったなあ。
表記法だけって感じだった・・・・おそまつだったなあ・・・。
129:NAME IS NULL
06/03/14 01:46:14
なんか古臭い感じがするよね。
自分的には主キー、外部キー、カージナリティがちゃんと表現できれば必要十分。
ＥＲ図書くのは好きだけど、それだけじゃシステム動かないし
データモデリングに偏り過ぎてるのはなんだかねぇ・・・
130:NAME IS NULL
06/03/18 16:27:27 B7S2rjh8
勉強中です。第二正規形と第三正規形を分ける理由が良く分かりません。
分かりやすく教えてください。
131:NAME IS NULL
06/03/20 10:08:38
データベース理論的にはボイスコッド正規形との絡みとか色々あるから、
２と３を分けるのは必然だろうね
でも、実務上はそこまで意識しすることあまり無いね。
いつもなんとなく設計しちゃってる
132:NAME IS NULL
06/03/20 22:32:44
俺もなんとなくやったら第3正規形になる。
133:NAME IS NULL
06/03/22 07:14:06
漏れはなんとなくやると第6正規形になる。
134:NAME IS NULL
06/03/22 10:26:27
オレもなんとなくやったら第百万光年正規形になる。
135:NAME IS NULL
06/03/22 19:26:57
自分はなんとなくやったら正上位形になる。
136:NAME IS NULL
06/03/29 03:15:57
>>130
遅レスなので下げる。
第2正規形から推移性関数従属を取り除いたら第3正規形になるよな。
じゃあ、推移性関数従属する非キー項目があるとと何が不味いんだ？
って考えてみな。
ま、結局、単純に言えば更新時にリレーションが消えたり、
データ多重持ちになったりと不整合が起こる可能性を増やしてしまうからだな。
137:NAME IS NULL
06/03/29 04:41:23
>>136
レスありがとうございます。
ただ、私が知りたいのは、なぜ第三正規形にするか、ということではなく、
なぜ、第二正規形という形があるのかということです。
第一正規形から片っ端から関数従属を取り除くと第三正規形になると思うのですが、
その間に第二正規形を置いて第二と第三を区別する理由が良く分からんのです。
138:136
06/03/29 13:02:23 mr4gMX+s
>>137
うーん、正規形についてなんかちょいと誤解があるような気がするんだけど・・。
もしかして、第一正規形からスタートして第三正規形でゴール！
だから、第二正規形っていう中継点を通過する意味がわかんないよね、
一気にゴールでいいよね、とか思ってるのかな？
もちろん、設計上は第三正規形を目指して正規化しろとは言われるが、
各正規形にはそれぞれ特徴があって、例えば第二正規形でないと
リレーションをすべて保持できない、とかそういうケースもある（時系列の保持だか、期間の管理だか）
また実装時の動作速度を考えて（JOINより多重持ちの方が早いとか）で
あえて正規形を崩す場合もある。稀だと思うが。
で、名前をつけて区別するのは、それぞれの特徴を把握しておく事で、
上に述べた様な更新異常等の不都合に対抗する手を打っておく必要が
あるからだね。（もうこれは主にPGMでだけど）
ちなみに、余計な話だけどすべての関数従属をとりはずすと
ボイスコッドの正規形になるんじゃないかな？
第三正規形は候補キーの中の関数従属については容認してるはず。
間違いがあったら、どなたか指摘、訂正してくださいませ。よろしく。
139:136
06/03/29 13:07:11
自己レスだけど、ちょいと言いたい事が足りてなかったかも。
３だとリレーションを保てない、２，１ならOK,なら１にすれば良くて、２の存在価値は
相変わらず不明、とか思われると遺憾かなと思って。
こうなるとやっぱり程度の問題で２の方が更新異常とかの面でまだベターだから、
せめてそこまでは正規化しましょうよ、という事になるのかも。
だから、やっぱり無駄ではないと思うんだけどな。
140:130
06/03/30 03:44:07
度々レスありがとうございます。
>>138
> >>137
> うーん、正規形についてなんかちょいと誤解があるような気がするんだけど・・。
> もしかして、第一正規形からスタートして第三正規形でゴール！
> だから、第二正規形っていう中継点を通過する意味がわかんないよね、
> 一気にゴールでいいよね、とか思ってるのかな？
正にそんな感じで思っていました。
> もちろん、設計上は第三正規形を目指して正規化しろとは言われるが、
> 各正規形にはそれぞれ特徴があって、例えば第二正規形でないと
> リレーションをすべて保持できない、とかそういうケースもある（時系列の保持だか、期間の管理だか）
> また実装時の動作速度を考えて（JOINより多重持ちの方が早いとか）で
> あえて正規形を崩す場合もある。稀だと思うが。
ここらへんの話を詳しく知りたいと思っています。
ヒントをもらったので調べてみます。
> ちなみに、余計な話だけどすべての関数従属をとりはずすと
> ボイスコッドの正規形になるんじゃないかな？
> 第三正規形は候補キーの中の関数従属については容認してるはず。
> 間違いがあったら、どなたか指摘、訂正してくださいませ。よろしく。
そうなんですか、勉強不足でした。調べてみます。
ありがとうございました。
141:NAME IS NULL
06/03/31 18:08:00
>>140
テクニカルエンジニア DB の参考書とか読んでみるといいよ。
こういうDBの理論とかの専門書って少ないし高いし・・・
142:NAME IS NULL
06/03/31 23:46:12
テクニカル DB 保持者ですが設計の経験がほとんどありません、逝ってきます。
143:NAME IS NULL
06/03/32 16:16:11 45VqWbwv
テクデの勉強ってＤＢだけじゃなくて、業務知識のストックにも
なるところが実務向きでいいと思うんだよねー。
なんか、自分の周りではあんまり知られてない試験なんですが。
大規模システムとかやってると、色んな業務形態に触れる
ことが少ないと思うので、こういう試験を通して、自分の未経験分野の
業務知識をつけてくのって、試験受かる受からないに無関係で
重要だと思います。
144:NAME IS NULL
06/04/02 02:41:14
そんなに大きな案件ではなくて、クライアントが言うことばかりでかくて、
たとえば、データは何十万件になるとか、そのくせ、仕様はなんにも決まってなくて時間がない、
その上、実際は1年もしないうちに放置状態になるのが目に見えてるような案件だったら、
DB設計なんかくそ真面目に考えてるより、冗長になっても1テーブルで済ませちゃうってやり方が
我が社ではスタンダードなんですが、これってとんでもないことなんでしょうか？
145:NAME IS NULL
06/04/02 12:28:17
普通。
受託案件は自分がメンテするわけじゃないからなんでもありですよ。
146:NAME IS NULL
06/04/02 13:27:04
>>144
それって逆に開発が鬱陶しくならんか？
147:144
06/04/02 19:07:03
>>145
やりにげ、って感じですかね？
>>146
作り始めてからあれこれ口出されるのにいちいち対応するなら冗長でも1テーブルのほうが楽では？
変なとこで却下されたりすると、正規化してるのが足かせになってよけい面倒なことになってる希ガス
148:NAME IS NULL
06/04/03 13:32:44
確かに正規化しすぎると変更に弱くなるね。
ってか、DB構造見ていじわるしてるのか、という変更ばかり発生する不思議。
うちではその辺、設計者の腕（技術＋業務知識）の見せ所なわけですが。
149:144
06/04/03 23:33:06
>>148
そっちの方への拡張性を考慮して組んだりするとそのマスターまったく要らなくなったりとかw
なんで、足かせになるような仕様を要求しといて、それに対する対処がやっと済んだころに却下になるんだ？
もしかして、もうすごいスキルを持った嫌な奴なのかもしれん
150:白馬の玉子 ◆PqSzNbkqDo
06/04/12 12:43:45
スピードパフォーマンス重視
or
管理効率重視
この二極化しかないと思うんですが。
それぞれに応じて、正規化なんて、教科書どおりにやる必要、
取捨選択すればOKっすよ。
現場で仕事もしたことないOraMasの女とかが、
正規化を演説してたりするんだよなぁ・・・・頃したくなる・・・・。
151:NAME IS NULL
06/04/12 14:11:14
s/頃し/犯し/
152:NAME IS NULL
06/04/12 23:12:50
非正規化するのも、必ずしもパフォーマンスだけが目的ではないしね。
初心者の頃はマスター系とトランザクション系の区別さえつかんかったなぁ・・・
153:NAME IS NULL
06/04/17 14:10:43
T/R系は目的上、正規化しちゃマズい場合もあるし
154:NAME IS NULL
06/05/11 00:57:58 DgrOFV3I
誰か第５正規形を直観的に教えてください．．．
事例を示して、ほら第５正規形じゃないと異状が起きるでしょ？というのは良くあるけど
なんで異状が起きるのか構造的に理解できません。
出来れば結合従属性の概念も。
字面のままの定義は分かるけど、何がどう「従属」してるのかサッパリ。
155:NAME IS NULL
06/05/11 20:58:00
>>154
絶妙のタイミングでこんな記事が・・・
URLﾘﾝｸ(www.atmarkit.co.jp)
これ書いたのお前じゃないの？w
156:NAME IS NULL
06/05/13 01:44:22
>>155
どうもありがと。なんとなく解かりました。
でもこれ、多値従属性の定義の説明が若干間違ってるねえ。
157:NAME IS NULL
06/05/13 02:33:10
？ んー、やっぱ良く解かってないかも。
「すべての情報がそろわないと登録できない」という制約は
別に結合従属性だろうがなかろうが、
ぜんぶの属性がキーであるなら、どんな関係でも当てはまるよね？
何か問題をすり変えられた気分です。
ほかの解説でも、同じなのですが。
結合従属性を持つ関係は、
どういう冗長性があって／どうして情報無損失で分解可能なのか
．．．ってのがやっぱり解らんです。
158:NAME IS NULL
06/05/31 15:26:48
正規化のことじゃなぃんだけんども
リレーションの設定って要るの？
たしかにキーや関係の確認のためにあれば便利だけど、
自分で設計してるもんだから、リレーションを絡めた処理は
ＶＢＡで素で組む。困ったことないんだよ。
みんなどう？
159:NAME IS NULL
06/05/31 21:56:00
好み次第
160:NAME IS NULL
06/06/01 11:06:07
ここで議論が。止まってるけど。
制約っていらなくね？
ｽﾚﾘﾝｸ(db板)l50
161:NAME IS NULL
06/06/06 19:09:59
たしかに最初は律儀にリレーション設定してたけど、漏れも
クエリなんかでその都度繋げるし、参照整合性が邪魔になる時もあるし
同じマスターテーブル（一側ね）を複数繋げるときも邪魔。
設定しないほうが、他人が見たときＤＢの仕組みが分かれにくいから
いじられるの阻止するのにもいいし。
162:NAME IS NULL
06/06/06 22:11:39
データインポートするときとかうざいよね＞リレーション
まぁ、インポート時は無視するオプションとかもDBによってはあるけど
163:NAME IS NULL
06/06/20 02:03:12
あ～～～！むずがゆい！
164:NAME IS NULL
06/10/12 13:35:14 LD5ggMeq
平成の大合併で住所変更。顧客マスタの住所と住所マスタの住所の整合性がとれてない。。
正規化してねーと、こんなことになる。。今日中に終わるかな。。
165:NAME IS NULL
06/10/22 22:41:58
運用部員がマニュアルで作業するときには制約はあったほうがいい。
制約を回避するINSERT、UPDATEを書けるようになれ
166:NAME IS NULL
06/11/15 13:27:54
>155
アクセのレベルを疑うような記事だな。
BC正規化なんて、ひどい。つか、事例悪過ぎ。
ものすごい遅レスなんで下げる。
167:NAME IS NULL
07/01/04 15:07:35 Sogkk2is
すみません質問させて下さい。
共通の商品マスタ（キーは商品コードのみ）をシステムで使用していて桁数や採番ルール等で新たに
商品コードを使いまわすというのは皆さん普通にやりますか？各サブシステムには過去のデータ
が残っていて当然使いまわす前の商品コードも保持されています。ただしDBでリレーションシップが
組まれている訳ではありません。採番ルールを変えて新たな商品コードを取る事も可能です。
過去データを参照するのであればマスタデータを削除、使い回しをする行為は厳禁だと思ってます。（←ここら辺が大きな勘違い？？？）
自分的には採番ルールを変えるのが妥当だと思うんですが。皆さんはどう思われますか？
何分あまり経験が無いもので一般的にはどうしているのかわかりません。
皆さんの意見を聞かせて下さい。宜しくお願い致します。
168:NAME IS NULL
07/01/04 20:18:53
内容が漠然としすぎている気がするが、藻前が設計するんなら
藻前の好きにすればいいと思うが･･･。
つか、DBでリレーションされていないのに商品マスタがどーこーって話を
聞く時点で相当にアレな設計な印象をうけるのだが･･･。
169:NAME IS NULL
07/01/04 22:43:58
物理設計でリレーションシップなしは普通。
それ以前に「リレーション」とかいってる>168の方が
ちょっとなんだかなあという気がするんだが。
コードを使いまわして全く別の商品に割り当てるなんて
信じられない世界だけど、お客さんがそうしたいってなら
しょうがないんじゃないの？お客さん都合を実現するのが
システムなんだから。
お客さん都合でどうなるかわからんコードをキーにするのが悪いよ。
やるとしたら、コードと有効期日FromとToかなんかを複合キーにするしか
ないんじゃないですかね。
170:167
07/01/04 23:32:40
>>168
>>169
ご意見ありがとうございます。
しかし、システムを引き継いだ時点でそういった仕組みで稼動しており
どうにもならない状態だったもので・・・作り直すと結構莫大な工数となりますし。。。
>コードを使いまわして全く別の商品に割り当てるなんて
>信じられない世界だけど
自分が聞きたかったのはこの言葉かもしれません。
お客様もコードが重複する事の弊害も考えずに削除使いまわしを口のにされている模様ですので
コードの桁数を増やし100年位は重複せずにすむ採番ルールを採用する方向で進めて
いくべきだと思いました。
本当にありがとうございました。
171:NAME IS NULL
07/01/05 06:42:50
＞物理設計でリレーションシップなしは普通
物理だろうが論理だろうがリレーションシップがないんなら
そりゃExcelやCSVやCOBOLerな印象があるな。
設計者の理想であるクソ長い商品コードを使うか？か
顧客の要望の通り、過去の番号と重複するけど短い商品コードを使うか？
ってのはそれぞれの事情があるからなぁ。
まあ単に顧客が最初のクソ設計になれてしまったんだろうが。
172:NAME IS NULL
07/01/05 07:25:49
お客さんが既に使ってるコードにはデータベース的な厳密さはないが、
手作業上の必要や業務上のノウハウが詰まってることが多いから簡単にはなくせない。
多くの場合サロゲートキーモデルが有効であることが多く、
主キーはシステム側でユニークで長いのを振り、旧来のコードは属性として使用する。
例えば在庫などに張るシールなどでは後者を大きめに表示した上で両方のコードを印刷している。
173:NAME IS NULL
07/01/05 23:07:34
>>171
まあまあ、COBOLerとか言う前に現実を見よう。
制約っていらなくね？スレでも議論になったくらい
参照整合制約ありなしは結構二分されてるよ。
あり派は実装を見れば設計の意図が判るって意見があった。
なし派は制約つけるとデータメンテが面倒になるからって意見があった。
特に開発段階でテストデータガンガン入れたりする場合とかだね。
どっちも気持ちは判る。
まあつけない派は現場の現実解って感じではあるなあ。
バッドノウハウというか。
174:NAME IS NULL
07/01/05 23:18:39
>>173
いわんとする事はわかるが、だから>>171はCOBOLerと揶揄しているのだろう。
そして、必要最低限のテストもしない人種はCOBOLerに多いな。
職場にもよるが現代(?)のSQLやらJava寄りの人種は
テスト用のツールを用意＆作成したりして、テストのシナリオも
作って開発するけど、ExcelなVB厨やCOBOLerは
あんましそういう概念ないよな。ひたすら手で打鍵とか言うし。
現場の現実解と言えばそうなんだが、COBOLerはあんまし学習能力とか
向上心とかない連中の思想だと思う。
175:173
07/01/06 01:03:19
うーむ、確かに現実解てのは耳障りがよくて
要するに向上心の欠如じゃないかといわれると
ぎゃふんだなあ。
まあ制約に関しては話題がずれちゃった感があるので
ぎゃふんってことでゆるして。
で、制約いらないスレはこっち。止まってるけど。
ｽﾚﾘﾝｸ(db板)l50
>171の、クソ設計にお客さんが慣れちゃって
見直しさせてくれないってのは、判るよー判る。
これも向上心の欠如っていやそうか。
176:NAME IS NULL
07/01/13 19:49:54 xq5OSR3p
主キーが倍精度変数って別におかしくないですか？
主キーは文字変数であるのが望ましいと思っているのですが･･･
177:NAME IS NULL
07/01/13 20:27:34
倍制度でも検索が遅くないならいいんじゃね？
ただ、そんな計算結果みたいなフィールドを主キーにする設計の方がおかしいと思うけど。
178:NAME IS NULL
07/01/13 20:35:58
>>176
numberならアリかも知れんが、doubleみたいな近似値はありえん。
179:NAME IS NULL
07/01/13 20:41:39
64bit整数やdecimal(number)系で桁数の多い場合の主キーで、
それを扱えない言語から利用する場合やむなく実数変数を宛がう事があり
この場合は困ることがある。
180:NAME IS NULL
07/01/15 00:11:04
MSSQL の DATETIME を主キーのタプルに組みこんだらVBAがミリ秒の
分解能を扱えず逝きかけた当方が通りますよ。
181:NAME IS NULL
07/09/25 00:14:21 Cvnl8sn8
SQLから誘導されてきました
ずいぶん初歩的な質問で悪いんですが合併律、分解律、擬推移律の成り立ちを証明したいんですが…
アームストロングの公理系で調べても成り立つとしか書いてないもので…
だれか証明のプロセスを説明していただけないでしょうか？
182:NAME IS NULL
07/10/13 09:57:23
MySQLに natural join ってあったのな。
今頃知った俺ギザ間抜け
183:NAME IS NULL
07/10/21 01:04:39 6GmbKqtg
初心者です、質問です。（他スレで聞いたらここで質問するよういわれました）
Mysqlでテーブル作ってて、フィールド数が90くらいになりそうです。それで問題ないのか知りたいです。
正規化する必要があるのかどうかを知りたいんです。
テーブルは、ライブの情報を扱うものです。なので登録情報は
開催日、開始時間、料金、イベント情報etcの基本情報と
出演者名、出演者のURL、演奏楽器etc の出演者情報になります。
出演者はイベントごとに1～10人に分かれて不安定なので正規化・分離するなら
この部分かなぁと思うんですが、、
それともこの程度なら同じテーブルに入れてもいいのか、判断しかねてます
正規化（テーブルの分離）する場合、登録フローとしては、基本情報の登録時に
自動インクリメントでイベントIDを生成し、それを主キーとして参加者テーブルへの
参加者を登録することになるかと考えています。
正規化する必要あるでしょうか？ 初心者の為判断しかねています。
登録ごとにテーブルに空欄があったりなかったりというのが
マズイような気がしてそれが気になります。 お暇な方、回答お願いします。
184:NAME IS NULL
07/10/21 06:18:18
今はイベントテーブルに出演者やそれに付随するフィールドが
それぞれ10個ずつあるような作りになってるの？
まぁ、分けるとしたら。
イベント(id, 開始時間、料金etc)→出演(イベントid, 出演者id)→出演者(id, 出演社名、URL、吹奏楽器etc)
って感じで新たにテーブル2つ作るような感じかな。
フィールドが90個っての自体はギリギリ許容範囲かなという気もするけど、
同じ出演者が当然何回も出てくると思うんで、
出演者情報はテーブル分けて、別に管理すべきだろうね。
それでかなりシンプルに成りそうだし
185:183
07/10/21 12:48:09
詳しい説明ありがとうございます。ホントに助かります。
アドバイスいただいた中で、出演者情報（名前とURLと楽器、プロフ文etc）にあたる部分は
実は別に用意してるんですが、イベント登録するにあたって、当日演奏する楽器が
必ずしも登録してるものと一致するとは限らない可能性もあるので、
イベントテーブルに（名前、楽器、URLを）ガッチャンコしてるんです。
さらに言うと、出演者テーブルへの登録件数（演奏家の人数）が少ないうちは、
プレイヤIDをイベントテーブルに登録するというプロセス自体が機能しないのではという
危惧もあり、無駄にフィールド数が増えてるんです。
1)一覧から参照する（出演者テーブルをリスト表示後、各プレイヤ参照ボタン押す）→IDを入力
2) 1)が出来ない場合（お目当ての出演者がリストに未登録の時）は名前・URLを直接入力してください
みたいな感じで。
なので、１イベントあたり最大10人てのを全部登録したとしても、プレイヤ用フィールドのうち
半分（リスト参照して入力用or手動入力のいずれか）のフィールドは必然的に空欄になるんです
これがムダでヘタクソなやり方なのか、それとも仕方ないと判断していいものなのか…
仕方ないよですむならこのままやっちゃおうと思うんですが どうなんでしょう？
プロじゃないんで経験則が働きません…
186:NAME IS NULL
07/10/21 13:52:49
ユーザーインターフェースとテーブルは別だぞ。
187:NAME IS NULL
07/10/21 14:21:27
> 実は別に用意してるんですが、イベント登録するにあたって、当日演奏する楽器が
> 必ずしも登録してるものと一致するとは限らない可能性もあるので、
> イベントテーブルに（名前、楽器、URLを）ガッチャンコしてるんです。
イベントごとに楽器が違うということであれば、
楽器は中間テーブルに持てばよいね。
>>184でいくと
出演(イベントid, 出演者id, 楽器)
という感じ。
> 2) 1)が出来ない場合（お目当ての出演者がリストに未登録の時）は名前・URLを直接入力してください
> みたいな感じで。
必ずしも全ての出演者が登録される必要は無いってことだね。
それなら上の中間テーブルで
出演(イベントid, 出演者id, 楽器、名前、URL)
みたいにしたらいいかもね。
出演者idは空白可で。
> これがムダでヘタクソなやり方なのか、それとも仕方ないと判断していいものなのか…
> 仕方ないよですむならこのままやっちゃおうと思うんですが どうなんでしょう？
無駄でヘタクソなやり方だとは思うけど、
サイズ的に管理しきれないほどでもないから、
今のままでもいいんじゃないかという気はする
188:183
07/10/21 14:50:38
>>187
なるほど、凄く勉強になりました
イベント基本情報テーブルと、中間テーブルに分ける場合は、
インターフェース的には 基本情報の登録→そのイベントIDを拾って→出演者登録
って流れにすればいいんでしょうか？ 出来れば10人以上にも対応したいんで、
ソッチのやり方で理解した方がいいですよねぇ
>>186
＞ユーザーインターフェースとテーブルは別だぞ。
おっしゃるとおり、その部分の理解が薄いんです。
いろいろ勉強してみます。ありがとうございました。
189:NAME IS NULL
07/10/21 15:56:26
> インターフェース的には 基本情報の登録→そのイベントIDを拾って→出演者登録
それでいいと思う
190:183
07/10/21 18:18:38 6GmbKqtg
わかりました、どうもありがとうございました。
191:NAME IS NULL
07/10/26 11:24:48
許可マスタ
項目名 field名 型 桁数
コード code varchar2 2
エリアコード１ area_code_1 number 2
判定１ area_judge_1 varchar2 1
エリアコード２ area_code_2 number 2
判定２ area_judge_2 varchar2 1
エリアコード３ area_code_3 number 2
判定３ area_judge_3 varchar2 1
エリアコード４ area_code_4 number 2
判定４ area_judge_4 varchar2 1
エリアコード、判定は全84項目存在するが、途中を省略する
.
.
.
こんなDB定義もうやだー
192:NAME IS NULL
07/10/27 09:58:27
lol
193:NAME IS NULL
07/11/01 01:20:19 zMKsxNgF
こんなスレもある。
ｽﾚﾘﾝｸ(prog板)
194:NAME IS NULL
07/11/12 21:07:31
会社コードと会社名だけのテーブルに正規化する価値ってあるかな？
JOINのコストが恐ろしく無駄な気がするんだけど。
195:NAME IS NULL
07/11/12 21:36:34
>>194
「カイシャメイ」 も追加しろ。
196:NAME IS NULL
07/11/12 21:39:15
そうやってマスタでも管理してトリガで更新したいって提案したら不安な顔をされた。
こういうのはバットプラクティスだったのかな？
197:NAME IS NULL
07/11/13 11:47:27
>>194
会社なら(>>195のいうように)ふりがなとか所在地とか取引状況とか、付帯情報が後から湧いてきそうだから、俺ならマスタにする。
joinのコストがCPUを指してるなら「誤差の範囲ですよ」、開発時のタイプ量を指してるなら「ビュー用意しとくんで」。
つい最近だと、印紙種類(収入印紙と登記印紙)をどうしようか迷った。
「そんなもん、増えた時にシステムの対応が必要だったら、データ増やすだけじゃむりだから(アプリに手を入れるから)」
という理由で、これはマスタ可しなかった。
198:FEQoQDjgtx
07/11/14 04:53:31
gBMpor <a href="URLﾘﾝｸ(sflntwpuclbo.com) [url=URLﾘﾝｸ(vtoysuqfixvo.com) [link=URLﾘﾝｸ(iarrmvwkbpot.com) URLﾘﾝｸ(poyhgemjrdue.com)
199:NAME IS NULL
07/11/17 22:12:21
>>194
今の時代、会社名などいくらでも変わる可能性がある。
当然、正規化するべき。
200:NAME IS NULL
07/11/18 08:52:47
>>199
過去のデータで帳票を出す場合、
昔の名前で出なくなるな。
でも正規化自体は賛成。
201:NAME IS NULL
07/11/18 09:52:01
取引当時の社名を出力しなければならないという要件があるなら
そう作ればいいだけで、正規化の有無とは関係ない。
202:NAME IS NULL
07/11/20 02:00:19
いや、それも本とかでは正規化（というか非正規化）の文脈で語られてるよ
203:NAME IS NULL
07/11/20 14:01:50
社名の変更ならその程度で済むかもしれんが、合併とかどうするよ
204:NAME IS NULL
07/11/20 17:12:39
合併したら新会社としてデータを起こすとか。
どうせ与信だなんだ大きく変更になるだろうし。
ただ旧組織との紐付けが必要か否かだなあ。
合算して昨年実績としたい、みたいな。
205:あぼーん
あぼーん
あぼーん
206:NAME IS NULL
07/11/20 22:25:34
社名と日付を用意するなんてわざわざしなくても
社名変更だろうが合併だろうが別会社として扱えばいい
207:NOMO ESTAS NENIO
07/11/22 07:49:11
>194
(1)取引当時の「社名」を「会社コード」と一緒に「取引テーブル」に書き写せばいい。
社名変更して「会社テーブル」の社名列を更新しても取引記録を打ち出すときは旧社名で出るし、
その会社との取引履歴を出すときにはコードで引けば社名変更に関わりなくすべての履歴を
引き出せる。
(2)もしくは、「会社テーブル」に「旧会社コード」を設けて、社名変更後はレコードを追加して
別の会社として扱うようにするとか。こうすると新会社分、旧会社分の履歴だけを取り出すときに
便利になるし、旧会社の名前も残せる。
(3)「会社系統テーブル{旧会社コード, 新会社コード}」を設けて、社名変更後は「社名レコード」に
レコードを追加して、旧会社のコードと新会社のコードを「会社系統テーブル」に記録するように
すれば、履歴を多対多の関連で残せるので会社合併・分社があっても追跡ができる。
208:NAME IS NULL
07/11/22 08:26:10
(2)もしくは、「会社テーブル」に「旧会社コード」を設けて、社名変更後はレコードを追加して
別の会社として扱うようにするとか。こうすると新会社分、旧会社分の履歴だけを取り出すときに
便利になるし、旧会社の名前も残せる。
２回以上社名変更や合併を繰り返した場合でも大丈夫でしょうか？
209:NAME IS NULL
07/11/22 12:59:43
207じゃないけど、2回以上でも問題ないだろ、単なるリンクリストなんだから
リンクが1レベルしかできないリンクリストなんてないじゃん
ただ、「この会社名の通用期間」みたいなものを設けて、特定の日付がどの通用期間に含まれるかチェックするとか、面倒だよ
210:NAME IS NULL
07/11/22 20:09:17
吸収された後でまたスピンアウトみたいな離れ業はあるのだろうか
法的には関連性が切れてるだろうから、新しく起こせばいいのかな？
211:あぼーん
あぼーん
あぼーん
212:NAME IS NULL
07/11/23 23:15:27
>>207
（スレタイ）「頼むから正規化しろよ 第二正規形」
おそらく「取引テーブル」の候補キーは、「会社コード」以外の属性も含まれると
考えられ、
「取引テーブル」の「会社名」は、
「取引テーブル」の「会社コード」にのみ関数従属する為、
「取引テーブル」の候補キーの一部に関数従属することとなる。
よって、その「取引テーブル」は、第二正規形とならない。
ではどうするかというと、「会社テーブル」を履歴で作れば良い。
会社テーブル [ *会社コード、*適用開始日、会社名]（*が主キー）
>>209
新旧「会社コード」もありだろうけど、実装を考えると、
SQLでリンクリストを検索するより、
適用日付で検索した方が明らかにラク。
「取引テーブル」という名前から想像すると、「取引日」という属性を
持ってるだろから、「会社コード」「取引日」と「会社コード」「適用開始日」で
JOINするだけ。
213:NAME IS NULL
07/11/23 23:19:50
212の続き
もともとJOINのコストが無駄という話しからだったが、
その程度のJOINコストが無駄というのは、どんなハード使ってるんだ、
という話しだと思う。
214:NOMO ESTAS NENIO
07/11/24 03:30:10
>212
取引テーブルに会社名列を持たせる設計の場合、取引テーブルの会社名はスナップショット
として持たせるものであり、正規形を崩すものではない。正規形を崩す設計ならば、そもそも
会社テーブルを持たず会社の管理はすべて取引テーブルの中というようになる。
たとえば、商品販売明細テーブルに商品単価を転写するのと同じこと。商品単価を商品テーブル
から引いてくる設計にすると、商品の単価が変わったときに過去の売り上げまで全部書き換わるのを
防ぐためのよく知られた手法を、取引テーブルにおける会社名の持たせ方に応用したものだ。
215:NAME IS NULL
07/11/28 01:35:19
>>214
正規化について言及すると、それは正規形を崩してるだろ。
正規化手法は、”既約でない”関数従属を排除する為の射影である
必要があり、第二正規化された射影を結合することによって、
元の第一正規形の集合が得られる必要がある。
要するに、１事実１箇所になってないと正規形とは言えないってこと。
だから、スナップショットは正規化違反ということさ。
商品単価の話はJOINのコストが気にならないのであれば、
会社名と同様、履歴化して正規化すれば良かろう。
ただ、商品明細のように会社名に比べてデータ量が多く、
マシンの性能とJOINのコストバランスを考えると、
正規化崩して、明細にスナップショットを持たせた方が
良かったというだけだろ。
よろしく
216:NAME IS NULL
08/04/04 08:17:59
依頼とは別でアンケートの集計もお手伝いすることになったんだが、
先輩がエクセル表で
店舗ID 店舗名 質問1 質問2のA 質問2のB 質問2のA 質問2のB・・・
--------------------------------------------------------------------
ってな表を作っていた。
(質問2のAは複数回答有りで、2のBは複数回答した数だけ答えるアンケート。)
データを打ち込む人は、列が足りなかったら足していってた。
何万レコード分もあるから、普通に打つのさえ大変なのに…。
一緒に仕事したことないが、開発やってる時は多分できてることを
雑務になるとできないという不思議…。
いや、開発の時もできてるかどうか知らないが…。
217:NAME IS NULL
08/04/04 20:25:32
> 一緒に仕事したことないが、開発やってる時は多分できてることを
どういうこと？
SPSSとかで集計するときのマルチアンサーのフォーマットって
先輩がやってるようなのが一般的だと思うが
218:NAME IS NULL
08/04/04 22:06:03
先輩は勉強しはじめたばかりだから、
そんな仕事はしてない
219:NAME IS NULL
08/04/05 08:22:30
統計で言うオカレンスとデータベースのタプルは似て非なるものだということだよ。
220:NAME IS NULL
08/04/14 13:44:48
JOINのコストって高いね。
正確に言えば、検索キーワードとソートが必要な検索で
JOINを行うと、インデックスがどれか一つにしか使えないから遅い。
検索キーワードがlikeだったりするとさらに最悪。
非正規化したほうが良い。
221:NAME IS NULL
09/04/11 21:06:53
>>220
釣れますか？
222:NAME IS NULL
09/06/10 17:33:31
>>220
クラウド革命でITエンジニアは監獄行きです
URLﾘﾝｸ(d.hatena.ne.jp)
Google App Engine担当者に聞いた
クラウド環境ではデータベースは「非正規化」して使う？
URLﾘﾝｸ(www.atmarkit.co.jp)
223:NAME IS NULL
09/06/22 22:31:06
正規化について質問です
第一正規化は繰り返しフィールドの排除があるかと思いますが、
たとえば
ＩＤ｜購入者｜商品１｜金額１｜商品２｜金額２｜商品３｜金額３｜商品４｜金額４
01｜ＡＡＡ.....｜ＴＶ１....｜10万...｜ＴＶ２....｜11万....｜ＴＶ３...｜12万....｜ＴＶ４....｜13万...
このような場合は
ＩＤ｜購入者
01｜ＡＡＡ
......と
ＩＤ｜商品｜金額
01｜ＴＶ１｜10万
01｜ＴＶ２｜11万
01｜ＴＶ３｜12万
01｜ＴＶ４｜13万
と２つに分けるかと思いますが
ＩＤ｜購入者｜販売担当者｜購入日｜配送日
の場合
購入者と販売担当者は人フィールドで、
購入日と配送日は日付フィールドなので
これらも繰り返しフィールドとみなせるのでしょうか？
224:NAME IS NULL
09/06/22 22:46:59 Ii7lYaDv
>>223
それって違うんでねーの？
たぶん
225:NAME IS NULL
09/06/22 23:11:29
>>223
そうみなしたければみなして良い。みなしたくなければみなさなくても良い。
正規化というのはそういったところを決定した後に行う操作だから。
226:NAME IS NULL
09/06/23 07:20:42
通常は繰り返しとはみなさない。
あなたの言うとおりなら、
ID、人種類、人ID、日付種類、日付
みたいなカオステーブルができあがってしまう。
エンティティをしぼりこむのは業務分析ありきだから上記のカオステーブルが絶対ないとは言わないが、通常はないと言える。
227:NAME IS NULL
09/06/24 21:28:15 FsaDUw2R
>>226
ありがとうございます
そうですよね
何かこれに関する情報がのっているサイトとかご存知でないですか？
これを正規化と豪語する人がいて、そうじゃないという説得材料にしたいのですけど
228:NAME IS NULL
09/06/25 18:47:46
簡単なデータで例を作ってみたら？
問題でれば、それで説明つく。
出なければ、そのデータでは、問題ないのかもしれないよ（その人は
それを言っているのかもしれない）。
229:NAME IS NULL
09/06/25 19:55:02 uVxmIhxY
>>228
今日、この件お話したら、納得してくれたようです
たまたま具体的なデータ例で、話をしてたら話の論点があって、ある程度解決作がみえてきました
具体的な例で話し合うのは重要かもしれませんね
230:NAME IS NULL
09/06/25 22:24:51
よかたねー
231:NAME IS NULL
09/06/27 04:19:07
(・∀・) 白くなっとるﾜﾛﾀｗｗｗｗ
●● URLﾘﾝｸ(wakuwaku.docomo.han-be.com)
●● URLﾘﾝｸ(wakuwaku.docomo.han-be.com)
232:NAME IS NULL
09/09/21 18:26:25 4bCDESCP
同じ表にmember_idとmember_nameの二つの列があって、
member_id ・・・社内の人間なら社員コード。社外の人はNULL
member_name ・・・社内の人間ならNULL。社外の人は名前
みたいになってるんだけど、これってもっといい方法があるよね？
社員コードは別の社員表にある。
233:NAME IS NULL
09/09/21 20:51:56
社員表(社員コード,社員名)
社外表（コード,名前）
メンバー表(メンバーID,・・・・・)
社員コード∈メンバーID
社員コード∈コード
select B.社員名,C.名前
from メンバー表 A left join 社員表 B ON A.メンバーID=B.社員コード left join 社外表 C ON A.メンバーID = C.コード
234:NAME IS NULL
09/12/24 17:18:39 ao0/KMLR
>>215
＞正規化について言及すると、それは正規形を崩してるだろ。
＞正規化手法は、”既約でない”関数従属を排除する為の射影である
＞必要があり・・・
＞ ：
＞要するに、１事実１箇所になってないと正規形とは言えないってこと。
＞だから、スナップショットは正規化違反ということさ。
超遅レスだが、>>214の見解は的確で合理的じゃね？
販売業務で商品の販売単価が日時や取引数量、その他に応じて変動する場合、売上伝票や
注文書に載せる明細の単価に対し、商品マスタの単価との間に従属性を認めては駄目だよな。
ゆえに業務の性格によっては正規化の対象とはならないだろう。
そして、注文を行った時点でのスナップショットこそが、正に売買契約と売上認識の「事実」。
つまり、一つの売上伝票や一つの注文書をもって「一事実、一箇所」と認識しなければ、寧ろ
不都合なシステム設計をする事になるよな。 だから、>>214は優良な実務経験者だと思うぞ。
ボイスコッドから高次の正規化は要注意だな。
それより対象業務をよく分析し、ER図等で得られた業務の大切な性格と特徴を損なわない正規化を
心掛け、顧客指向のITソリューションでメリットを提供することがプロフェッショナルの仕事だと思う。
235:NAME IS NULL
09/12/26 01:44:47 dn/wTtyt
ニコニコ動画のコメントやアマゾンのレビュー、youtubeのコメントなど
1対多の関係はどういうデータベースの構造になっているんでしょうか？
自分は以下の3パターンを考えたのですがどれも疑問が残ります。
案1：1つのレコードに動画番号とその動画に対する全てのコメント番号を収納する
動画1, コメント1コメント2コメント3コメント4
動画2, コメント1コメント2
欠点：・コメント数が有限になってしまうのではないか。
・複数のコメントが一つのコラムに収納されている場合、
１つのコメントの追加によってそのフィールド全体を更新しないといけないから
重いのではないか。
案2：コメント主導で動画番号を対応づける
コメント1, 動画1
コメント2, 動画2
コメント3, 動画1
コメント4, 動画3
欠点：動画を見る度にコメントの抽出をしないといけないから重いのではないか
案3：各動画毎にコメント用のテーブルを用意する
動画1のコメントテーブル：
コメント1
コメント2
コメント3
動画2のコメントテーブル：
コメント1
欠点(?)：動画の数だけテーブルを用意することになるけど、
自分はどうプログラミングするのか分からないです。
236:NAME IS NULL
09/12/26 02:51:10 rKp6qWLp
>>235
リレーショナルデータベースでのデータ設計は、プログラム言語のように構造体で
カタチを決めて配列やリスト構造を持たせていくデータ設計と違って、集合論理と
関連の概念で解決しないとダメなんだよ。
↓こんな風に持たせればそれらしくなるんじゃない？
237:NAME IS NULL
09/12/26 02:51:56 rKp6qWLp
【投稿動画テーブル】
動画ID 会員ID 投稿日時 動画データ ・・・
---------+----------+---------------+----------+---
sm1234567 nv1000000 2008/10/21 11:25 mov999999 ・・・
sm1234568 nv1300000 2009/01/13 18:31 mov888888 ・・・
sm1234569 nv2000000 2009/07/02 09:05 mov989898 ・・・
sm1234510 nv1000000 2009/12/25 23:41 mov010101 ・・・
： ： ： ：
【投稿コメントテーブル】
動画ID タイム コメント
---------+-----+-----------------
sm1234567 00:01 wktk
sm1234567 00:03 高画質
sm1234568 01:52 ああああああああ
sm1234567 00:08 ﾃﾗ画質ｗ
sm1234567 00:12 ｷﾀｰ!
sm1234510 00:02 ｗ
： ： ：
sm1234567 01:32 これはすごいな
sm1234567 01:40 たしかにｗ
sm1234569 03:02 おおおおおおおおっ！
sm1234567 01:59 うｐ主様、乙でした
238:NAME IS NULL
09/12/26 02:52:50
そもそもRDBかどうかも疑うべきだと思うけど。
239:NAME IS NULL
09/12/26 03:21:23 dn/wTtyt
>>237
ありがとうございます。
つまりそれは案2で、動画を見る度に
全てのコメントを収納した巨大な投稿コメントテーブルから
動画IDでコメントの抽出を行うんですよね？
それって重くないんでしょうか。
案3だと抽出処理が要らないんで軽いのかと思ったんですが
そんな大差はないのかな。。
240:NAME IS NULL
09/12/26 04:06:02
>>239
案ずるには及ばないと思うよ。インデックスとサーチのアルゴリズムは高度だから。
この程度のデータなら、RDBMSで数万件からの抽出でも、あっという間な筈。
あと他の方法となれば、制限を設けて自前のアルゴリズムで管理するしかないね。
WindowsならVC++やVC#、VBなどでサービスプログラムを組んで、Webページの
サーバーサイドから呼ぶとかね。
ハッシュアルゴリズムとか独自方式とか好きな技法でカスタムメイドできるよ。
241:NAME IS NULL
09/12/26 19:20:41
>>238
ニコニコはMYSQLだと聞いてる。
242:NAME IS NULL
09/12/26 22:13:20
>>238
現実的に考えて、RDB以外にないだろ。
243:NAME IS NULL
09/12/27 00:06:26
多くの工業科＆組込制御系育ちはRDBMSをなかなか理解できないらしい。
自分をCPUに見立てたプログラム実行ロジックで考えてしまう癖が抜けなくて、
データの順番や個数、アドレス問題はポインタで解決済みの早見表として
オンメモリですべてを掌握していないと納得できないという。
役割分担や分散処理が苦手で、すべて自分のプログラムだけでやろうとする。
そして孤高だったりする。