11/02/23 19:37:11.95 iyykSQn2
以前働いていてたとこ、DB名、テーブル名からカラム名まで全て日本語 w
352:NAME IS NULL
11/02/23 19:50:08.25
>>351
それで具体的に何が困ったかｋｗｓｋ
353:NAME IS NULL
11/02/24 02:03:54.85
最近の自動生成系の機能がついたIDEなんかだと日本語変数名にもつながっていくので
規約で変数名にマルチバイト文字使っちゃダメとかやると面倒くさい。
逆に積極的にマルチバイトを使うように決めてしまえばあるいは。
354:NAME IS NULL
11/02/24 02:14:58.82
MySQLの公式ツールが落ちるからマルチバイトは使わないなぁ
コメントの日本語だけで詰むｗ
supplier.id ほげ.仕入れid hoge.siireid
こんなDB見た事がある
355:NAME IS NULL
11/02/24 03:46:34.08
>>354
MySQLってそんなにマルチバイトに弱いの？
一昔前までは、世界的なシェアで見ると、MySQL＞PostgreSQLだが
日本ではMySQL＜PostgreSQLだった。
PostgreSQLに比べてMySQLは、最初のころはマルチバイトに弱いとかで人気が出なかったが
だんだんそのへんが良くなって来てるから、PostgreSQLとトントンくらいのシェアになってるとか
どこかで読んだ気がするんだが。
公式ツールで扱えないんじゃMySQLではマルチバイトでカラム名を付けるなんてことは考えられないなｗ
356:NAME IS NULL
11/02/24 07:27:19.12
トントンくらいになったが、PostgreSQLの改善速度がかなり早く、MySQLはまた引き離されてしまった印象。
357:NAME IS NULL
11/02/24 12:17:16.70
>>354
公式っても、GUIツールだろ。
そりゃあしかたない。
他は全然安定してるから問題ない。
あんまり。
358:NAME IS NULL
11/02/24 12:43:23.84
サポートされてる機能を使っちゃいけないってのもおかしな話だしな
359:NAME IS NULL
11/02/24 16:58:43.49
>>357
仕方なくないだろ。
あきらかにマルチバイトは軽く扱われてるじゃん。
OracleやSQLServerですら稀に問題が起こるのに
MySQLで問題が起こらないとは到底思えないな。
360:NAME IS NULL
11/02/24 18:31:35.55
マルチバイトのテーブル名だの、項目名だの欲しがるのは、開発側じゃなくて大抵客。
だから、マルチバイトにしたビューを用意すればいいだけ
361:NAME IS NULL
11/02/24 22:29:28.02
Oracleだとマルチバイトのカラム名は""で括らないと動かん場合がある
362:NAME IS NULL
11/02/24 23:14:03.56
>>361
Oracleで""で括ってないって理由で動かないSQLを1度だけ見たことがある。
SQLServerは""で括らなくても問題ないの？
363:NAME IS NULL
11/02/25 23:38:18.25
>>346
ありがとうございます。
>o テーブルAに主キーを設定し、テーブルBには(テーブルAを参照する)外部キーを設定する。
なるほど、これが一番良さそうです
>o テーブルBに主キーが必要か否かは、エンティティA無しにエンティティBが存在しうるか否かで決める。
主キーについてまだ理解が足りてなかったみたいです
では、DB設計時は1:NやN:Nといった関連と、
単体で存在しうるか、という軸でも整理しておく必要があるってことですね
今作っているテーブルの該当部分は親子関係(子がない場合もあり、子単体は存在しない)なので
親への外部キーのみ設定して、子の主キーは設定しなくても良さそうです
364:NAME IS NULL
11/02/26 02:25:39.36
>>346, 363
訳が分からない。
> テーブルBに主キーが必要か否かは、エンティティA無しに
> エンティティBが存在しうるか否かで決める
なんでテーブルBに主キーが無くて良いことがあり得るの?
> 親への外部キーのみ設定して、子の主キーは設定しなくても
> 良さそうです
子の主キーも設定する。親への外部キーはNOT NULLで参照する。
そんだけ。あと初心者は気軽にNULL使わない。三値論理を理解して、
その面倒くささを理解してから使うこと。
365:NAME IS NULL
11/02/26 10:04:45.13
>>364
>なんでテーブルBに主キーが無くて良いことがあり得るの?
>>346で書いたように「A無しにBが(単体で)存在しえない」場合があるから。
具体的には、エンティティAの属性(attribute)としてテーブルBを表現するケース。
より抽象的に(モデル分析的視点で)、トップダウンな考え方を以下に説明する。
あるエンティティAが存在し、そのエンティティAは複数の属性を持つ。ここで各属性について、
(1) エンティティAがその属性を「ただ一つだけ(only one)」持つのなら、
その属性をテーブルAのカラム(フィールド)として表現する。
(2) エンティティAがその属性を「いくつか(zero or more)」持つのなら、
その属性をテーブルBとして表現し、テーブルBには(テーブルAを参照する)外部キーを設定する。
(3) エンティティAがその属性を「たかだか一つ(zero or one)」持つのなら、
その属性をテーブルBとして表現し、テーブルBには(テーブルAを参照する)外部キーを設定し、
更にその外部キーにはUNIQUE制約を設定する。
いずれの場合でも、テーブルBは「(単体で存在しうる)エンティティを表現」しているのではなく、
エンティティAが持つ「属性を表現」しているのだから、テーブルBに主キーは必要無い。
366:NAME IS NULL
11/02/26 10:16:03.18
>>365
BがAに依存する属性だったとしても、Bに主キーがなければ
その属性を一意に特定することができないってことだろ？
「主キー」の意味するところが違う？
367:NAME IS NULL
11/02/26 10:56:57.58
>>366
テーブルBの個々の行(ロウ)を一意に特定する必要があるのなら、
そのテーブルBは(属性ではなく)エンティティを表現していることになる。
もしテーブルBでエンティティを表現したいのであれば、当然のことながら
テーブルBに主キーは必要になるよ。
368:NAME IS NULL
11/02/26 11:18:19.70
複数存在するのに一意に特定する必要のない属性って、想像しにくいんだが。
それってたとえばどんなもの？
もしかして、BのエンティティキーをAと独立に持つかどうかという話じゃないのか？
369:NAME IS NULL
11/02/26 12:04:19.62
>>368
想像しにくいというのが理解しがたいのだけれど、要望とあれば。
たとえばエンティティAが楽曲や書籍のような著作物であるとする。
この場合、作者(作曲家/作詞家/著者/原作者/翻訳者..etc)は属性であり、
ある著作物に複数の作者が関わることがあるから、複数の属性になる。
370:NAME IS NULL
11/02/26 12:23:57.65
いや、問題は「一意に特定する必要がない」ということの方なんだが。
作曲家と作詞家、あるいは作曲家が2人いてもそれらは個々に特定
できなきゃならんのが普通だろ。
主キーを持たないということは、仮に同じ曲に同姓同名の作曲家が
2人いたとして、それを区別する術がないということだ。
371:NAME IS NULL
11/02/26 12:32:11.67
>>370
>それらは個々に特定できなきゃならんのが普通だろ。
特定する/しないという判断は、与えられた問題(要求仕様)によって変わる。
「普通だろ」というのは設計者の勝手な意図(思いつき)にすぎない。
もしも特定しなくてもいいという問題であるのもかかわらず一意性を作り込んだのなら、
それは過剰な設計(設計ミス)ということになる。
372:371
11/02/26 12:35:49.91
>>371を一部訂正する。
X: もしも特定しなくてもいいという問題であるのもかかわらず
O: もしも特定しないという問題であるのもかかわらず
373:NAME IS NULL
11/02/26 12:40:50.21
別に本人が必要ないと思ってるんならいいんじゃない？
こんな頭の固いやつにいくら言っても無駄。宗教と同じ
374:NAME IS NULL
11/02/26 12:48:42.38
あらゆるテーブルには主キーが存在しなければならないという考え方が、「頭の固い」発想だと思う。
どちらにせよ、人格攻撃に走ることしかできないのなら、漏れは議論から降りるよ。
375:NAME IS NULL
11/02/26 12:53:18.72
だからさ、そんなもの見たことがないからどんな例があるか聞いてみたんだが？
RDBでは主キーがないテーブルも許されるが、設計論としてはリレーショナル
モデルにおいて主キーがないなんてことはありえないし。
376:NAME IS NULL
11/02/26 13:02:13.25
>>371
ん？しかし>>346では「エンティティA無しにエンティティBが存在しうるか否かで決める」と言っているが？
377:NAME IS NULL
11/02/26 18:27:05.81
あまり読んでないけど、
AなしにBが存在し得ない状況では外部キーが主キーと同じ意味を成すといいたいのかな。
そんなことないけど。
378:NAME IS NULL
11/02/26 19:18:11.77
>>375
>だからさ、そんなもの見たことがないからどんな例があるか聞いてみたんだが？
重複を許す(=一意性を保証しない)属性テーブルというのは、普通に存在するよ。
なるべく分かりやすい例を挙げたつもりだし、重複の可否(=一意性の保証/無保証)を決めるのは、
DB設計者ではなく与えられた問題(要求仕様、つまり顧客)であることも書いた。
ここまで説明してもなお、自分は見たことが無い/経験した事が無いので想像がつかないと
言われたら、自分としてはショボーンとするしかない。
>RDBでは主キーがないテーブルも許されるが、設計論としてはリレーショナル
>モデルにおいて主キーがないなんてことはありえないし。
まず、関係論理/関係代数の世界においては、タプルに一意性が存在することを仮定しているから、
タプルの重複はありえない。ただし、残念ながらリレーショナルモデルというのは、
タプルの重複を許す多重集合(マルチセットまたはバッグ)なんだ。だからタプルの重複はありえるし、
従って一意性は必ずしも保証されない。必要であれば明示的な一意性制約の宣言が必要になる。
次に、RDB実装における主キー(プライマリキー)と、リレーショナルモデルにおける主キー
(行の一意性を保証する候補キーの集合)とを混同して理解しているように見える。
379:NAME IS NULL
11/02/26 19:24:09.00
（>>378の続き）
たとえば>>365の(2)でテーブルBに一意性が必要であるならば、設定した外部キーと候補キー
(例えば作者名カラム)との組(くみ, タプル)に対してUNIQUE制約を設定するのが正しいDB設計。
この場合、外部キーと候補キーの組を「主キーとみなす」。(「主キーを設定する」とは言わない。)
>>364のようにテーブルBへ主キー(プライマリキー)を設定した場合には、RDB実装における
テーブルの一意性は保証されても、リレーショナルモデルにおける一意性(作者名の非重複保証)は
実現できないから、誤ったDB設計であると思う。
380:378
11/02/26 20:12:53.64
>>326,327
個別にはレスしないが、二人とも「単体での存在性(エンティティなのか？属性なのか？)」と
「主キーの有無(タブルの一意性を保証するのか？しないのか？)」を混同してるように見える。
381:378
11/02/26 20:15:43.69
アンカをミスった。
>>326,327は間違いだ。>>376,377に訂正する。
382:NAME IS NULL
11/02/26 20:18:00.38
>>378
そういう一般論を言ったら、Aに関係なくBが存在する場合だって
必ずしも主キーは必要ないってなるんじゃね？
383:NAME IS NULL
11/02/26 20:25:44.02
>>380
それを混同したのが>>346だと思うんだが。
384:378
11/02/26 20:36:57.54
>>382
それでも良いと思う。どこに(普通か普通じゃないかという)境界線を引くか、という話になるね。
>>383
えーと、>>346で書いた「主キーを設定する」という表現は、すべてDB実装における
主キー(プライマリーキー)のことだよ。それが読み取れないということは、やっぱり混同してるんだね。
385:NAME IS NULL
11/02/26 20:54:52.06
つまり「主キー」という言葉には2種類の意味があって、自分が意図していたのは
違う方の意味だとｗ
>>379では「設定する」と「みなす」なんて言い換えまでしてご苦労なこったな。
386:NAME IS NULL
11/02/26 21:41:24.92
小難しい表現の割にはどうでもいい話だったな
387:378
11/02/26 21:44:24.81
>>385
えーと、困ったな。言葉の「使い分け」はしてるけど、「言い換え」はしていないつもりだよ。
「言い換え」とは、同じ事柄を別の方法で表現するという意味だよね。
>>346のテーブルAは、RDB実装における主キー(プライマリキー)とリレーショナルモデルにおける
主キー(一意性)が一致しているから「主キーを設定する」という表現をしても誤解されることはない。
それに対して、>>379のテーブルBはリレーショナルモデルにおける主キー(一意性)は存在しているけど
RDB実装における主キー(プライマリキー)は存在しないから、誤解の無いように「主キーとみなす」と
表現方法を「使い分けた」。
日本語って難しいね。
388:378
11/02/26 21:55:30.25
>>386
>>379では、「>>363のDB設計は誤りであり>>379が正しいDB設計である」と
言い切っちまっているんだけど、これはそのまま放置しといていいのかな？
それとも、これすら「どうでもいい話」なのかな？
「いいや、....だから>>364が正しい」とか「自分ならこうする」というような
反論/異論を期待してたんだけど....。
389:NAME IS NULL
11/02/26 22:09:32.49
彼の言う「主キー」と、「主キーを設定する」という用語は
一般的なSEやプログラマがRDBMS上でのテーブル設計をする際のそれと
意味合いが違うってことです
一般的なRDBMS上のテーブル設計では、そのテーブルの行を個別に識別できる項目（の組み合わせ）を
システム的に指定することを主キーを設定するといい、その指定された項目を主キーと呼びます
そういう意味では、行を識別必要があるする全てのテーブルにおいて、主キーを設定することが推奨されます
つまり、全てのテーブルに主キーがあるべきであると言う主張が成り立つわけです
390:NAME IS NULL
11/02/26 22:11:18.60
もうどうでもいい。
Ｔ字形の論理編ぐらい、どうでもいい。
391:378
11/02/26 22:14:41.27
いけね、また間違えた。
X:「>>363のDB設計は誤りであり
O:「>>364のDB設計は誤りであり
392:NAME IS NULL
11/02/26 22:19:21.49
もともと「設定する」と「みなす」を別の意味で使っていたのなら、>>346のテーブルAも
「設定する」と「みなす」場合両方があるわけだろ？
それを誤解がないからと勝手に片方だけ書いたら逆に誤解するわ。
じゃあ聞くけど、もう一度言葉の定義を明確にして>>346を正しく書き直したらどうなるの？
393:386
11/02/26 22:48:50.20
>>388
たとえば伝票と明細のケースでいえば
明細テーブルでは行を一意に識別する主キーはいらないってのがお前の立場なんだろ？
それで要件満たせるんなら別に問題ないと思うけど、
普通は明細の各行単位で修正入れたいケースとか必ず出てくるから、
現時点で必要ないように見えても必ず主キーは設定するように俺はする。
それがサロゲートキーなのか複合キーなのかは別にどっちでもいい。
ただ、現時点での要件を満たせるんなら後で修正すればいいだけだから、
別にお前のやり方でも俺はかまわない。
お前みたいなやつを説得するのは経験的に難しいとわかってるから、
機能的に不具合が出ないんなら議論なんかせずに迎合する。
要するにどっちでもいいし、どうでもいい。
394:NAME IS NULL
11/02/26 23:01:47.25
>>387
モデルの一意性は存在してるけど実装のプライマリーキーが存在しない状態ってなんだよそれ。
つか、そもそも設計段階でそんなもん考慮するのか？
395:378
11/02/26 23:28:17.16
>>389
つまり、一般的なSE/PGのRDB設計とは>>375が言うところの設計論としての
リレーショナルモデルとは意味合いが違うってことなんだな。
だから、>>379のような「主キーとみなす」という表現は普通じゃないってことか。
うん、よく分かった。これからは注意しよう。
ところで、>>364では
>子の主キーも設定する。親への外部キーはNOT NULLで参照する。そんだけ。
とあるのだけれど、この「主キーも設定する」という表現は、自分は
単純に「プライマリキーを設定する」という意味であると(勘違いして)解釈しました。
でも、これは>>389によれば「適切な候補キー(たとえば作者名カラム)と外部キーとの
組合せに対し個別に指定できるよう主キーとして(UNIQUE制約を)システム的に指定する」と
解釈すべきなのかな？
分かっている人には当たり前なのかもしれないけど、>>344,363のような初心者に対して
「主キーも設定する」という短い一文からそのような推測を期待するのは、
ヒジョーに厳しすぎるんじゃないかと思うんですが、いかがですか？（自分も勘違いしたし....。）
いや、それすら「一般的なSE/PGのRDB設計」なら普通なのかな？
396:378
11/02/26 23:29:45.71
>>392
>>346を書き直してみた。これなら誤解はしないかな？
>>>344
>テーブルA,Bの関連が 1..N(Nは0以上) の基本を以下に書くよ。
>
>(1) テーブルAにプライマリキーを設定し、テーブルBには(テーブルAを参照する)外部キーを設定する。
>(2) 次にテーブルBにプライマリキーが必要か否かは、エンティティA無しにエンティティBが存在しうるか
> 否かで決める。ここで、もし存在しえないのなら、テーブルBは(エンティティではなく)属性を
> 表現することになるから、テーブルBへのプライマリキーの設定は不要になる。
>(3) 最後に(エンティティまたは属性)Bの一意性について検討する。もしBに一意性が必要とされるなら、
> (1)で設定した外部キーと適切な候補キー(たとえば作者カラム)との複合キーをリレーショナルモデル上の
> 主キーであるとみなし、その複合キーに対してUNIQUE制約を設定する。
>
> （以下は同文なので省略）
397:378
11/02/27 00:12:42.89
>>393
いいや、その伝票と明細のケースで言えば、明細テーブルの各行は普通にエンティティだと思う。
だからリレーショナルモデルにおける主キー(一意性)は存在するよ。ただし、RDB実装における
主キー(プライマリキー)は設定せず、(明細テーブルを参照する)外部キーと候補キーとなる
行番号カラムとの組(から成る複合キー)をリレーショナルモデルにおける主キーとみなすという
違いはあるかもしれないけどね。
このケースで属性となるのは、ある行を構成する各桁の値だ。ここで、(>>365で書いたように)
行エンティティがその値を「ただ一つだけ(only one)」持つのなら、その値は行エンティティの
カラム(フィールド)として表現する。ここまでは問題無いと思う。意見が分かれるのはこの先だ。
もしも行エンティティがその値を「いくつか持つ(zero or more)」のなら、その値は
属性テーブルとして表現するものとし、属性テーブルには(行テーブルを参照する)外部キーのみを
設定し、プライマリキーは設定しない。更に、もしも与えられた問題下でその値に一意性が
必要であるのなら(=必要な場合に限り)、外部キーと値の組を主キーとみなしてUNIQUE制約を設定する。
具体的な例を挙げれば、値引きオプション、つまり「論理値の集合」で値を表現するケースになる。
ある行が商品を表現するとして、その商品に対する様々な値引き(優待顧客値引き/個別値引き...etc)を
0個以上の任意の組合せで表現することになるだろう。
この場合、>>393であれば、どのようにDB設計をしますか？やっぱり値引きテーブルにも
プライマリキーを設定するのかな。もちろんそれでも(AP開発に苦労はしても)要求仕様を
満たせるだろうから、どっちでもいいし、どうでもいいんだけどね。
398:NAME IS NULL
11/02/27 00:15:40.50
>>396
ふむ。「設定」が>>389の意味だとするならば、言っていることはだいたいわかる。
＃本当は「存在しうる」とか「エンティティ」と「属性」の違いなんかは明確ではないが、
＃ここではそれを措いても特に問題ない。
その上で反論だ。
(1)1:Nならば無条件でBに外部キーを設定することになっているが、こここそ、Bが
Aから独立して存在するかどうかで変わる部分だろう？そうでなきゃ、対応するAの
レコードが存在するBの外部キーはNULLになってしまう。
(2)一意性が必要かどうかは要件で決定されるって自分で書いていなかったか？
自分は必要ないケースはめったにないと思っているが、どちらにしても、エンティティ
ABの関係とは関係がない。
(3)ここは言葉の問題。候補キーは(1)の外部キーを含む場合と含まない場合が
あるが、どちらにしてもそのまま主キーになり得る。だから、外部キーを含まない
候補キーとの複合キーなどというものは考えなくていい。
399:389
11/02/27 00:22:38.04
>>395
>「主キーも設定する」という短い一文からそのような推測を期待するのは、
>ヒジョーに厳しすぎるんじゃないかと
「一般的なSE/PGのRDB設計」ならそう思うのが普通だと思うが
純粋な設計と言うよりは、実装方法論だがな
だからあえてRDB設計とかいう言葉じゃなくて、RDBMS上のテーブル設計って言葉をつかったんだ
400:NAME IS NULL
11/02/27 01:01:50.65
>>397
なんか例がおかしくない？優待値引きとか個別値引きとかあるのになんで論理値なの？
それはそれとして、値引きテーブルに一意性が必要ない(=同じ値引きが複数存在してもよい)
と言うことであればそれはそれでありだと思うが、特定の値引きを削除するとか変更するなんて
要件があった場合は一意性が必要となる。
一方で、ここに1商品1レコードの在庫テーブルがあったとする。これはここで言う「属性」には
当たらないと思うが、一意性の要否については上の値引きテーブルと変わらない。
つまり、一意性の要否を判断する上で「エンティティ」か「属性」かは関係ない。
401:378
11/02/27 01:49:22.13
>>398
(1) AとBが 1:N の関係であるなら、N側であるBから見ると1側であるAは必ず「ただ一つだけ(only one)」
存在しているはずだと思います。だから、Bの外部キーがNULLになるケースが想像できないのですが？
(2) まず(2)では(一意性ではなく)存在性について述べているので、自分には論旨が不明です。
ただし一意性については指摘のとおり、(存在性と同様に)その必要性を決めるのは要件(要求仕様)です。
この点については、>>396への追加記述が漏れていました。
(3) この候補キーというのは、>>364の「子の主キーも設定する」というところのプライマリキーを
指しているのですか？もしそうであり、なおかつプライマリキーが人工キーである、
たとえば hoge_id のようにデータ型が自動インクリメントされる整数(つまり)であるなら、
自動的に一意性は保証されるから複合キーは考えなくていいでしょう。
自分は(なるべく)人工キーは作らず複合キーで実装する立場ですが、それはまた別の話です。
402:386
11/02/27 02:16:30.65
>>397
値引きオプションだって修正や削除の必要が発生する可能性はあるから、
当然主キーつけるに決まってるよ。
そもそも実務的には値引き伝票切るケースが多いけどな。
その例えはお前の主張したいことからして全く適切じゃない。
もっとちゃんとした例を出せ。
> プライマリキーを設定するのかな。もちろんそれでも(AP開発に苦労はしても)要求仕様を
> 満たせるだろうから、どっちでもいいし、どうでもいいんだけどね。
お前、いつの時代の人間なの？
最近のアプリケーションフレームワークなら、むしろプライマリキーをつけないほうが
特殊な処理過ぎて苦労するだろうが。
403:NAME IS NULL
11/02/27 03:53:37.69
軽い実例を出してくれたほうが伝わりやすいことは業務をやってればわかることだと思うんだけど、
いつまで文字でがんばるのか。
404:NAME IS NULL
11/02/27 07:35:09.08
>>401
(1)確かに、1:0..Nと書いていたな。それを前提としているならばここはその通り。
(2)この文章は存在性を述べているわけではなく、存在性を条件に一意性の要否を
述べているんだろ？その上で、前提が(1)の通りであるならばBは常にAなしに存在
し得ないわけで、その条件は意味がないことになる。つまり「(2)Bにはプライマリー
キーは不要」とだけ書いても同じこと。
(3)やっぱり具体例がないと伝わらないか。
例えばテーブルBが{X,Y,Z}だとして、XがAへの外部キーだとしよう。
ここで候補キーが{X,Y}の場合、それをそのまま主キーとすることができる。
また、候補キーが{Y,Z}だとした場合であっても、主キーをXとの複合キー{X,Y,Z}と
する必要はない。
つまり、「外部キーと候補キーの複合キー」はいずれの場合でも必要ない。
候補キーの定義からして自明のはずなんだが。
405:NAME IS NULL
11/02/27 10:13:02.26
うざいから、ER図付きでやってくれ
406:NAME IS NULL
11/02/27 10:17:07.66
もともとの話は>>346に対する>>364の反論から始まってるんでしょ？
例えばブログの記事にタグ付けするような場合、
記事テーブル（記事IDがPRIMARY KEY）と
タグテーブル（記事IDがFOREIGN KEY）を作るとして、
364氏はタグテーブルでは何をPRIMARY KEYにするんだろう？
「子の主キーも設定する。親への外部キーはNOT NULLで参照する。」
と言っているからサロゲートキーを作るって話なんだろうな。
それだけの話だった（ように見える）のに、
以降の議論はただ話を難しくしてるだけのような。
407:NAME IS NULL
11/02/27 11:23:29.66
なぜサロゲート？タグテーブルには候補キーが存在しない前提なの？
408:406
11/02/27 11:37:17.75
どういう候補キーがあると思う？
記事IDとタグの組み合わせを主キーにするってのは考えられるけど
それだと「親への外部キーはNOT NULLで参照する」っていうのを
わざわざ書く必要がない。（主キーなら必ずNOT NULLだから。）
わざわざ書いてるってことは364氏の言ってる主キーには
外部キーを含んでないっていう前提があるんでしょ？
（あくまで推測ね。俺は364氏じゃないから。）
409:NAME IS NULL
11/02/27 13:07:55.88
>>364の真意は知らんが、「主キーに外部キーを含めない」と限定していたようには
俺には読めなかったな。含んでいようがいまいがNOT NULLということだろ？
1. わざわざNOT NULLと書いたから主キーには含まないんだろう
2. だとすると候補キーもないんだろう
3. じゃあ何をPRIMARY KEYにするんだろう？
4. たぶんサロゲートキーを作るんだな
3.の疑問を持った時点で自分の推測を疑えよって話だな。
410:406
11/02/27 13:22:03.68
うん、まあ、そうかもしれんしそうじゃないかもしれん。
どっちにしろ、364氏の真意が分からんことには議論はできないよね。
411:NAME IS NULL
11/02/28 15:56:49.49
364だけど、
>>406
「タグテーブル」が記事に対するタグ付けを表す(記事ID, タグID)、かつ
タグの順序に意味はないとして、同じタグを同じ記事に複数回付けられ
ないのであれば(普通の仕様だと思う)主キーは(記事ID, タグID)。
「[これはすごい][これはすごい][これはすごい]...」みたいに、同じ記事
に同一タグを複数回認める酔狂な仕様なのであればサロゲートキーも
必要。
後者は純粋に関係モデル的にはそもそもこのようなキーがないとデータ
を表現出来ない(setだから)。SQL的にはsetではなくbagだから無くても
表現できるけど、大抵は無いと更新時に填る。
>「子の主キーも設定する。親への外部キーはNOT NULLで参照する。」
>と言っているからサロゲートキーを作るって話なんだろうな。
いや全然。そんな話じゃない。
外部キー参照は仮に主キーを参照していてもNULLは入れられる。
「子単体は存在しない」、すなわち必ず親を持つのであれば明示的に
NOT NULLは宣言する必要がある。
>>409
>含んでいようがいまいがNOT NULLということだろ？
正解。
412:NAME IS NULL
11/02/28 16:15:31.13
もひとつ、>>346に聞きたいのは、>>346のルールとか、そのあと
改正した>>396のルールとか、これ教科書か何かに書かれたものなの?
であれば参考までにリファレンスを示してくれると嬉しい。
413:406
11/02/28 18:47:49.98
つまり、>>364の
「子の主キーも設定する。親への外部キーはNOT NULLで参照する。」
は以下の意味だってことだろうから、俺は特に異論はない。
「子の主キーも設定する。
ただし、要件によってはサロゲートキーとすることもあり得る。
親への外部キーはNOT NULLで参照する。
ただし、子の主キーが親への外部キーを含む複合キーである場合は、
明示的にNOT NULLを指定する必要はない。」
346氏（=378氏？）は、単にサロゲートキー否定派なんじゃない？
414:NAME IS NULL
11/02/28 19:49:10.77
>>413
そゆこと。ただし以下の下りはちょびっと。
>ただし、子の主キーが親への外部キーを含む複合キーである場合は、
>明示的にNOT NULLを指定する必要はない。
必要ないし意味的にはダブるかもしれないけど、それでも明示的に
指定するかな。ごくごく個人的には、単に作法として。
テーブル定義を読んでも、parent_id *** NOT NULLと直接書いて
あった方がparent_idの取り得る値の制限としては解りやすいし。
>346氏（=378氏？）は、単にサロゲートキー否定派なんじゃない？
よくわからんす。自然キーでも人工キーでも、必要な場面で正しく
使えばどっちでもよいです。
415:NAME IS NULL
11/03/01 00:15:51.62
「弱実体」でググると>>346が言いたかったことと、どこが間違っていたかがわかるかも。
416:NAME IS NULL
11/03/01 01:34:29.60
>>396
> (2) もし存在しえないのなら、テーブルBは(エンティティではなく)属性を
> 表現することになるから、テーブルBへのプライマリキーの設定は不要
逆にエンティティA無しにエンティティBが存在しうるとすればどう
するの? プライマリーキー定義するの? どう決めるの?
> (3) 候補キー(たとえば作者カラム)
それは部分キーだ。候補キーじゃない。他のレスでも間違っている。
言葉遣いの問題だが、関係モデルの超基本だ。
> (3) その複合キーに対してUNIQUE制約を設定する。
なんでUNIQUE制約? PRIMARY KEY制約だとダメなのか? だってその
「複合キー」はテーブルB中の行を一意に選択出来るんでしょ? 主キー
の資格十分じゃん。
素のUNIQUE制約はNULL許可するけど、それでも良いの?
417:NAME IS NULL
11/03/01 01:43:38.21
>>397
> 具体的な例を挙げれば、値引きオプション、つまり「論理値の集合」で値を
> 表現するケースになる。ある行が商品を表現するとして、その商品に対する
> 様々な値引き(優待顧客値引き/個別値引き...etc)を 0個以上の任意の組合せで
> 表現することになるだろう。
関係従属性(商品, 値引きオプション) -> 適用可能[true or false]が存在。
なので値引きテーブルは(商品ID, 値引きオプションID, 適用可能)。
主キーは(商品ID, 値引きオプションID), 商品ID・値引きオプションIDに
外部キー制約。ちなみにBCNF。完璧じゃん。
主キーつけるのに何を悩む必要があるのか、それが解らない。
418:NAME IS NULL
11/03/01 02:10:41.89
>>378氏は一生懸命頑張って主キーがいるいらないの説明しているけど、
まず純粋にスキーマ設計の立場からいうと各テーブルの候補キーを特定
しておくことはマストだよね。でないと正規化が出来ん。
次に正規化が完了した関係スキーマをSQLで実装するときには候補キーに
対応する属性やその組に適切な制約をつけておくことは作法だよね。
でないとデータの整合性をアプリケーションレベルで保証する必要がある。
次に、それでも更新時のパフォーマンスの問題などで制約を外したい事は
無いわけじゃないよね。でも基本的にキーに対する制約を外すとテーブル
中の各行をアトミックに更新出来ることをDB側で保証できなくなる。
なのでその部分はアプリ側で制約するとか、更新の対象や単位を詳細に
見極めて判断したりする必要がある。
ましてや>>344は初心者だといっているのだから、教科書通りER図など
から主キーも含めたテーブル定義を導出する方法で良いじゃないか。
419:NAME IS NULL
11/03/01 03:10:14.37
みんな教科書通りにやろうとしてるぜ
みてる教科書の分野が微妙に違うんだがな
420:NAME IS NULL
11/03/01 04:11:06.16
>>417
関係従属性 -> 関数従属性。
関係モデルの超基本だ・・・釣ってくる・・・
421:デフォルトの名無しさん
11/03/04 00:09:48.83 nwTUgCQG
話をサロゲートキーの話題に戻すが、
①商品マスタの商品コードが変わったときの話だが、
サロゲートキーにしておけば、コードの付け替えが楽。
②トランザクションにてその時点のマスタ値を保障する方が安全
つまりトランザクションには、商品ＩＤ、商品コード、商品名等を
すべて保持する。
①と②は明らかに同時に成り立たないわけだが、
この矛盾はみんなどうしてる？
あと、階層関係があるマスタ、たとえば事業部マスタと部門マスタで
事業部と部門の紐付けが変更されうる。部門の名称変更がある等の理由で、
適用期間をおのおの持った場合、サロゲートキー（事業部ＩＤ）
だけでリレーションさせると、事業部マスタの世代が増えたタイミングで、
リレーションが破綻するわけだが、どうしたらいいんだろ。
422:NAME IS NULL
11/03/04 00:38:25.10
> ①と②は明らかに同時に成り立たないわけだが、
> この矛盾はみんなどうしてる？
矛盾なんかしてません。
馬鹿じゃないの？
> 適用期間をおのおの持った場合、サロゲートキー（事業部ＩＤ）
> だけでリレーションさせると、事業部マスタの世代が増えたタイミングで、
> リレーションが破綻するわけだが、どうしたらいいんだろ。
どういうシチュエーションでどういう設計をしたら破綻するのか
全然イメージがわきません。
多分サロゲートキーじゃなくてお前の頭が悪いんだと思うよ。
423:NAME IS NULL
11/03/04 00:55:03.15
>>421
サロゲートキーの使い回しをせず、商品コードの書き換えもマスタ
への追記で対応すれば(2)は本来不要なんじゃないのかな。
424:NAME IS NULL
11/03/04 01:36:28.45
まず、この例で言うなら、商品コードが変わった場合
過去に登録されたトランザクションデータをどうしたいかを考えろよ
過去データを塗り変えたいなら１が便利
過去データはそのまま保持したいなら２が便利
それだけの話だろ
違う要件に対する解決案をならべて同時に成り立たないって当然だろ
425:NAME IS NULL
11/03/04 01:39:40.34
履歴とリアルタイムデータの区別が付いてないっぽいな
426:NAME IS NULL
11/03/04 01:57:35.75
>>424
2にしてもトランザクションデータに追記する際に商品コードとか
商品名などを商品マスタの内容からコピペしているのであれば結局
1で対応出来るのだが。
商品マスタは基本追記で、最新フラグとか削除フラグとか付けて
古い商品レコードも全て保持するのは案外一般的だと思うけど。
427:NAME IS NULL
11/03/04 20:05:10.85
サロゲートキーでよくわからないところがあるんだが
本来pkになるはずだった項目の制約はどうすんの？
前に張られたこのURLの例では、制約について一切触れてないから、そんな制約張りませんってことなのか・・・？
URLﾘﾝｸ(gihyo.jp)
428:NAME IS NULL
11/03/04 20:14:23.32
制約つければよくね。
429:NAME IS NULL
11/03/04 20:25:51.61
NOT NULLとUNIQUEでいいじゃん
430:NAME IS NULL
11/03/04 20:28:03.50
>>428
もともとpkにする予定だった項目には、例外なくuniqueを張りたいんだけど
>>427の例ならどうするべきですか？
431:NAME IS NULL
11/03/04 20:35:13.01
>>427
場合によるとしか言いようがない。
挙げられた例だともともと主キーだったitem_noにUNIQUE制約とか
は付けられないよね。同じitem_noを使い回すので。
沢山の属性を組み合わせた複合キーをシンプルなサロゲートキーで
置き換えるような場合は、主キーこそサロゲートキーにしたとはいえ
元々の複合キーも未だに候補キー、つまりキーに含まれる属性値の
組み合わせはユニークなはずなので、UNIQUE制約を付けた方が良い。
432:NAME IS NULL
11/03/04 20:36:53.99
>>430
item_no（商品ID）とitem_name（商品名）の組み合わせに対して
UNIQUEだろうね
しかし>>427の例って商品ID自体が自然キーじゃないよな
433:NAME IS NULL
11/03/04 20:55:19.98
>>427のように、同じitem_noを使い回すのであればテーブルには更に
最新フラグとか削除フラグをつけることが多いと思う。
[id(サロゲートキー), item_no, item_name, deleted]みたいな感じで。
で、上記の例の場合は削除フラグdeletedがfalse、つまり現在有効な
行の中でitem_noのダブりがあると困るわけなのだけど、この制約を
書くのはちょっと面倒くさい。フラグ値を工夫するとか一般制約を
使うとかすれば書けるけど。
実際はアプリケーションレベルでタブりを事前確認するロジックを
書くことが多いんじゃないのかな。
434:NAME IS NULL
11/03/04 21:06:10.73
>>431
＞つまりキーに含まれる属性値の組み合わせはユニークなはずなので、UNIQUE制約を付けた方が良い。
この部分がよくわからないんですが、もうちょっとスキルが低い人にもわかるようにお願いできませんか？
>>432
名称もunique制約に含めるって、普通に行われることですか？
見たことが無いのでちょっと抵抗があるんですが。
それから、>>427の例の商品NOは、人口キーのようなどうでもいい文字列ってわけじゃなく
お客さんのなんらかの都合により使いまわされる事がある、お客さんも把握してる文字列なわけですから
自然キーの典型的な例だと思うんですが、違うんでしょうか？
>>433
変なデータができあがっちゃうとまずいんで
私が見たことのあるDBでは2重に重複チェックしてました。
具体的には、プログラム側でマスタを更新するまえにDBに問い合わせてチェック→重複してるようならweb画面にエラーを出す
プログラム側のチェックを通ったあとも、unique制約により、DB側でチェックが行われ、これも通れば更新されるといった仕組みでした。
おそらく削除フラグを付けたほうがいいというのは、期間でなくフラグを参照することで
select文を発行するときの負荷が減るというのが目的ですよね？
重複チェックはなかなかミスが出るようなところじゃないから、アプリ側できっちりやれってことでしょうか？
435:NAME IS NULL
11/03/04 21:30:12.87
>>434
プライマリキーのカラム数が5個ぐらいあって、Joinがしんどくてしんどくてしょうがないという理由から
ただの連番のカラムを作って、それをキーとするようにしてみた
という状態であれば、もともとの5カラムにユニーク制約つけたままで問題ないよ
436:NAME IS NULL
11/03/04 21:32:21.28
>>432
それがUNIQUEになるなんてただの思いこみなんじゃないかって思う
437:NAME IS NULL
11/03/04 21:35:44.50
>>435
すごくわかりやすい、ありがとう。
効果は開発効率のアップと、select文のコストが少し減るって感じかな？
その目的でサロゲートキーを使う場合
全てのテーブルにサロゲートキーを追加するんじゃなくて
pkの項目が多くなりそうなテーブルにだけ追加するのが良さそうですね。
サロゲートキーを使用するテーブルの場合、例外なく最初の列に「PK_テーブル名」というカラムを作り
それをサロゲートキーにするというルールで設計すれば、アプリチームの混乱も防げて良さそうですね。
438:NAME IS NULL
11/03/04 21:41:20.76
>>434
例えば月給テーブル(社員ID, 年, 月, 給料)を考えてみる。
主キーは(社員ID, 年, 月)ね。
で、理由はともあれ誰かさんが属性3つの複合キーなんて非効率的だ!
サロゲートキーにしろ! と叫んだとする。で、サロゲートキーSIDを追加して
月給テーブル(SID, 社員ID, 年, 月, 給料)、主キーSIDにしましたと。
で、このテーブルをよく見てみると、確かにSIDはキーですが、元々の主キー
(社員ID, 年, 月)もテーブル内の行を一意に特定出来るキーなんですね。
というか一意に特定出来ないと困る。でないと同じ社員が同じ年・月に複数回
給料もらえちゃいます。
関係モデルでは一つのテーブルが複数の「候補キー」を持つことがあります。
この場合はSIDと(社員ID, 年, 月)の二つの候補キーがあります。
その中から「主キー」を一つだけ選ぶわけですが、だからといって残った他の
候補キーがキーでなくなるわけではありません。それらも引き続いてキーです。
なので上記の例だと候補キー(社員ID, 年, 月)にUNIQUE制約を付けておく
必要があります。
439:NAME IS NULL
11/03/04 22:00:25.24
>>434
>おそらく削除フラグを付けたほうがいいというのは、期間でなく
>フラグを参照することでselect文を発行するときの負荷が減ると
>いうのが目的ですよね？
例えばサロゲートキーを使った商品マスタテーブルを使って実際に
トランザクションデータを書き込むとき、伝票に書かれた商品IDから
サロゲートキーを逆引きする必要があります。
しかし>>427のテーブルの場合、商品ID001からサロゲートキーを
逆引きすると二つサロゲートキーの値が出てきます。これはで困る。
なのでフラグを付けて現在も有効なレコードだけから検索するように
する必要があります。
もちろん特別にフラグを設けずに、例えば有効期間を表す列に「現在も
有効」を表す特別な値(>>427の例だと"9999")が仕様として定義されて
いる場合はこれを使って絞り込んでもよいわけです。
ただこの手の終了フラグを使った場合、商品IDのタブりを防ぐ制約は
やや凝った記述になりがちで、となると現状PRIMARY KEYなど基本
どころ除けばDBMS毎に書ける制約の表現力がバラバラなのが難しい。
MySQLなんてCheck制約は書けてもガン無視するとか、そんな仕様。
なんでアプリ側でチェックするロジックを書くことも多い気がします。
440:NAME IS NULL
11/03/04 22:26:37.03
>>438
丁寧な説明ありがとう。
この板はIDが無いみたいなんで、どのレスをした人がどのレスを返してくれてるのかわからないけど
>>435と>>438は同じ事ですよね？
>>439
MySQLでcheck制約がきかないのは初めて知りました・・・なんと恐ろしい。
>>427の場合は、トランザクションテーブルに書き込む商品の情報は
商品IDじゃなくてsrg_key（サロゲートキー）じゃないですか？
>>427の例の仕様ではこうなってるはず
・マスタのpkはサロゲートキーを使用する。
・トランザクションテーブルの外部参照をする列に格納するキーは、参照先のサロゲートキーを入れる。
・過去に入力された名称は、その時点で入力された名称をマスタから取得する。
・unique制約は付けない。
サロゲートキーの一つの利点である、pkに指定する項目が1つになるという部分は理解できました。
どこのページを見てもあんまり紹介されてませんが
unique制約が付けづらいというのはサロゲートキーのデメリットとして覚えておいた方が良さそうですね。
441:デフォルトの名無しさん
11/03/04 22:32:56.51
商品IDがダブらないなら本質的にサロゲートキーは不要かと…
やばいのは商品IDというか商品コードがメーカーによって使いまわされて、
ある製造日より別商品に割り当てられたが、
販売店の在庫管理としては商品コードと入荷日でしか
管理していなかったため、同一商品コードの違う製品が混在してしまって
何を販売したのか管理できず混乱するなどですよね。
442:NAME IS NULL
11/03/04 22:45:47.53
>>441
得意先のマスタなんかは在庫とかって概念がないからどうゆうふうに設計してもなんとかなりそうなもんだけど
商品に関しては商品IDを使いまわす可能性があるならサロゲートキーは必須になるのか
443:NAME IS NULL
11/03/04 22:50:32.51
すごーーーーく根本的な話になるんだけど
商品IDの使い回しを行いたい時ってどうゆう時？
得意先や部署はわかる。
合併やら統合やらあるもんね。
商品IDはわからん。
444:デフォルトの名無しさん
11/03/04 23:00:00.52
桁数だろう？
どれだけ必要になるかわからないからって
たとえば２０桁のコード体系をあらかじめ用意するのかってこと。
覚えられん…
445:NAME IS NULL
11/03/04 23:10:09.40
>>443
古いシステムならコードのMAXが5桁とか普通に有り得るだろう。
446:NAME IS NULL
11/03/04 23:18:26.31
えー・・・
447:NAME IS NULL
11/03/05 00:12:24.71
くるくる回る商品IDなんてよくある。
ある時点においてユニークであれば、それで現場は回っていくんだよ。
なもんで、こっちとしてはサロゲートキーを作って、商品IDガン無視する。
たとえ今はいらなくとも、商品IDで検索したいってなったときに困らないように、
ある時点で有効な商品IDがどれかを特定できる情報を保持しておく。
448:NAME IS NULL
11/03/05 00:39:28.99
俺の場合、
自社に決定権がないコード体系のマスタ（商品など）は、サロゲートキー
自社に決定権があるコード体系のマスタ（得意先マスタ）はナチュラルキー
ジャーナルのヘッダはサロゲートキー、
ジャーナルの明細はヘッダのＩＤ＋明細番号の複合主キー
とすることが多いが、これって古臭い？
449:NAME IS NULL
11/03/05 01:22:17.28
雑誌コードなんか桁が足りなくて新規発番が出来なくなって使い回してるよな
450:NAME IS NULL
11/03/05 01:28:21.09
そうゆうことか。
周辺システムが古くて桁数が少ないので
商品IDを使いまわさずを得ないと。
>>441みたいな場合ってどうなるの？
頻繁に商品IDが付け替えられて、古いほうの在庫も残る可能性がある。
同じ商品IDで、商品そのものも名称もまったく違う商品が存在する。
Web画面で商品を入力するためのボタンがあって、ポップアップで検索ボックスみたいのが出てきて
IDで検索すると同じ商品が複数出てくる。
それを選択してもらう。
Webの入力画面でコードを手打ち入力した場合の動作は？
ajaxとかで名称ひっぱりたいとこだけど、複数出てきた場合は新しい方を出したりするのかな？
なんにせよ恐ろしい・・・
こうゆう運用ならサロゲートキーは必須だ・・・
451:NAME IS NULL
11/03/05 02:15:11.10
>>448
その得意先マスタのキーって得意先IDみたいなの、つまりサロゲーとキーでは？
ナチュラルキーになりうるのってなんだろうとぐぐってみたところ、
上場企業限定ならISINコードというものがあるようだけど、これなのかなぁ
>>449
休刊して番号温存だね。あるある。
>>450
客から見て、在庫も含めると異なる商品に対して同じ商品IDがついているけれども、
業務を滞りなく行えているのであれば、何も悩む必要はないよね。
こちらとしてはサロゲートキーで処理をしてしまえばいいだけだよー
452:NAME IS NULL
11/03/05 02:17:08.29
>>450
加えて、商品IDでの検索結果が複数出てきたなら複数出せばいいんだよ。
それで業務がまわっているということが不思議だなぁと思うことはあれど、
それを正としなければいけないしねｗ
453:NAME IS NULL
11/03/05 02:30:08.03
>>451
>上場企業限定ならISINコードというものがあるようだけど、これなのかなぁ
>>448の言う「自社に決定権があるコード体系」というのは、
そういった業界標準コード体系を意味しているのではなく、
業務の中で自然に発生する自社特有のコードを指していると思う。
たとえば、紙の受注伝票に記入する得意先コードや受注商品コードというのは、
自社特有の(自社で決定できる)自然キーである可能性が高い。
逆に、発注伝票に記入する発注商品コードというのは、
(自社では決定できないから)人工キーとせざるを得ない可能性が高い。
454:NAME IS NULL
11/03/05 16:14:51.45
お前ら、商品ID商品ID言ってるけど、使いまわした時点でIDとしての役割を果たしてないだろうが
商品コードを使いまわす、が正しい用語だ
455:NAME IS NULL
11/03/05 17:59:31.77
まぁ目安だよな。あくまでも、自分が定義したエンティティに対してそのコードが
一意であるがどうかで判断すべきであって。
・よそで定義されたコード→一意でない「可能性がある」
・自分で定義するコード→当然一意に「できる」
極端な話、実際の商品の品種と商品コードの一意性が一致しない場合であっても、
「商品」ではなく「商品コード」エンティティを作る分には商品コードをそのままキーと
してもぜんぜんかまわないわけだ。
456:NAME IS NULL
11/03/07 20:06:48.91
>>453
＞自社特有の(自社で決定できる)自然キーである可能性が高い。
純粋な意味では、自然キーではないよね。ｗ
457:NAME IS NULL
11/03/07 20:11:28.00 OIEGkLgo
>>440
＞MySQLでcheck制約がきかないのは初めて知りました・・・なんと恐ろしい。
こわくないよ？
つーか、それっておいしいの？
MySQLしか使わないオレには、よく
わからん話なんだよな。
458:NAME IS NULL
11/03/07 20:53:11.82
>>456
システムの外で定義されるのが自然キーだろ？コードが人工的かどうかじゃなくて。
そんなこといったら、人名とか市町村名なんてどっちか判断つかん。
459:NAME IS NULL
11/03/08 05:36:45.40
>>457
知らない者にとっちゃ恐ろしいだろ。
定義できるのにまさか動かないとは思わないだろうし。
460:NAME IS NULL
11/03/09 01:13:08.54
>>454
このスレでのID、コードの使い分けって一般的に通用するものなの？
いや、自分もそういうふうに使い分けてるんだけど、他の人がそんな風に気にしてるの見たことがないので。
461:NAME IS NULL
11/03/09 01:47:19.22
>>460
基本的には普遍でユニークな社員番号(商品ID)と、変更可能な姓名(商品コード)、
みたいな形で一般人も接してはいる。
462:NAME IS NULL
11/03/09 15:48:40.12
>>460
まあ、大概の人は混同してる。このスレでも混同してる人もいるしな
一般の人にとって、コード振ってあるのに別にIDとるのは無駄に思えるんじゃね
463:NAME IS NULL
11/03/09 20:21:29.21
「混同」っていうと、まるで使い分けないのがおかしいみたいだな。
2行目をみるとそれぞれ別物のなにかを指しているというのはわかるんだが…
464:NAME IS NULL
11/03/10 06:07:06.59
IDでもコードでも俺はどっちでもいいな。
使い分けてないプロジェクトがあっても、sql書く時に項目名間違えづらいなぁ程度にしか思わない。
465:NAME IS NULL
11/03/10 09:17:01.62
>>458
システムの外で「独立して」定義されるのが
自然キーだろ？
顧客コードなんかデータベース以外に
ほとんど用途がないんだから。
466:NAME IS NULL
11/03/10 15:38:23.73
>>463
ID=コードなシステムもまあよくある
というか、IDとコード別にもつシステムの方が少ないと思うけど
IDとコードもつシステムの例はコード使いまわされるようなやつとか
「その他」とか「一般小口」とかのコードもってるシステムとか
IDっていう用語の意味を考えると、厳密に区別できないとIDじゃないからな
467:NAME IS NULL
11/03/10 22:58:24.84
>>465
この場合の「独立して」ってどういうことを意味しているのかな？
ここで挙げられた顧客コードってのは、「システムの外で定義されるけれども独立してない」例？
468:NAME IS NULL
11/03/11 04:29:35.90
独立していない可能性がある、または随時変更される可能性があるコードなんじゃない？
客から見えるコードだと、コードを振りなおしたい要求って結構くるよね
469:NAME IS NULL
11/03/11 07:32:25.94
>>465
>顧客コードなんかデータベース以外に
>ほとんど用途がないんだから。
ええぇっ！！、それが常識なの？
自分のいる世界とは別の異次元な世界の住人さんらしい.... hahaha
470:NAME IS NULL
11/03/11 11:13:05.74
「データベース」の意味をどう捉えてるかによるだろうな
471:NAME IS NULL
11/03/11 11:34:03.00
「データベース」でくくるとさすがにちょっと狭いと思うぞ
ほとんど「情報処理」とか「システム化」と同じぐらいまで解釈を広げればまあ納得しなくはないが
472:NAME IS NULL
11/03/11 13:15:03.35
台帳をデータベースと呼ぶかどうか
473:NAME IS NULL
11/03/11 13:18:57.55
>>469
そんな反応しなくてもｗ
そこだと、顧客コードは恒久的に変わらないことが前提で、顧客コードで会話等がされてるんでしょ。
その業務であればそのコードはIDであり、自然キーといっていいと思うよ。
474:NAME IS NULL
11/03/13 03:34:25.71
どのスレが適当か探してみたんですが、スレ立てるまでもない質問スレが見つからなかったので、ここで質問させて下さい。
病院で働いているんですが、今、上司からの依頼で、内視鏡検査の画像をデータベース化する作業をしています。
現在のシステムに以降する前の約２年分、件数にして4000件ぐらいのデータです。
データ形式ですが、約３ヶ月分ずつのデータがDVDにまとまっていて、DVDの中に入っている.exeファイルを起動して閲覧する、というものを、何とか一つのデータベースにまとめたいと悩んでいます。
各データは一件あたり数十枚で、たとえば34枚だとすると、フォルダ名00001、その中にjpeg画像00001から00034が３４枚格納されていて、つぎの件はフォルダ名00035となり、その中にまた画像一枚ずつに数字でファイル名がふってある形でした。
閲覧ソフトに患者名かIDか検査日を入力すると、画像が閲覧できます。
DVDに入っているのは画像フォルダ、恐らく画像とひも付けしたログファイルのフォルダ、あと閲覧ソフトです。
こういったデータを、Windows上で現在のシステムに移植するには、(オリンパスの出入り業者に確認した話ですが)一件一件検査オーダーを立てて、画像を指定する必要があるとのことでした。
自動でデータを読み出して全ての過去データDVDをデータベース化するか、現在のシステムに移植するには、どういうソフトを使えば可能でしょうか？
軽く調べたところ、SQLとやらいうスクリプトの話がでてきましたが、ド素人なので厳しいかと正直諦めかけてますorz
よろしくお願いします。
475:NAME IS NULL
11/03/13 03:48:10.98
>>474
多分この内容だと情報が足りなすぎて誰もアドバイス出来ないと思う。
ファイルの格納の仕方は「なんだそれ」という感じではあるけれども
サルベージ出来ないわけでもない。多分ネックは、
>恐らく画像とひも付けしたログファイルのフォルダ
の中身と
>Windows上で現在のシステムに移植するには
の「現在のシステム」が分からないと、どうにもならないかと。
ただ間違ってもログファイルの抜粋をこのスレに貼り付けたりは
しないでね。
いずれにしても出来合いのソフトで出来そうな作業じゃない。
専用のマイグレーションのためのプログラムを書く必要はある。
476:NAME IS NULL
11/03/13 04:30:03.11
>>475
レスありがとうございます。
やはり専用のプログラムが必要ですよね…
現在のシステムは、内視鏡サーバーに全て検査内容が直接スタックされるもので、オリンパスのsolemio というものです。
検査一件一件のデータをログから指定して、画面上の場所指定でオートクリック、ログ入力、画像指定が出来るソフトというと、オンラインゲームのチートソフトくらいしか思い付かず、それにしたってログを読み出すプログラムが別に必要になりそうな予感はしていました。
ちなみにログの抜粋がアウトなのは個人情報の関係ですか？
477:NAME IS NULL
11/03/13 04:37:50.27
>>476
医療情報流出～匿名掲示板でアドバイスを装って診察データを入手か～
・・・なんてニュースになりたくないでしょw
オリンパスにデータインポーター提供してもらうしかないんじゃない
のかなぁ
478:NAME IS NULL
11/03/13 05:08:53.69
>>474
画像の格納方法に規則性があるなら、画像を取り出すことは出来るかもしらんが、
「患者名かIDか検査日を入力すると～」がネック。おそらくこの他にも情報があるんだろうけど、これらのサルベージ方法が問題。
フォルダの中にテキストで埋めこまれてるとか言う間抜けな作りなら個人PGでも解析出来るだろうけど、さすがにそんなことはないだろうな・・。
そもそも元システムのライセンス的にどうかとかなりかねないし。
逆に解析を諦めるなら、最終手段で人がPC2台使って手入力でやれば出来る(つまり出入り業者の言う、「一件一件検査オーダーを立てて、画像を指定する」)。
この最終手段の可能性コミで、オリンパスに見積もってもらうのがベストだと思う。ただ人海戦術は安くないけどね。
479:NAME IS NULL
11/03/13 06:48:05.90
>>474
ざっと読んでみて、まず基本的な課題を挙げてみる。
(1) ストレージ管理
4000件のデータで各データが数十枚のDVDに格納されているというデータ量が膨大なケースだけど、
それらコンテンツのカタログ(目録)だけをデータベースすればいいのか(= カタログDB化)？あるいは
すべてのコンテンツをストレージ(要はハードディスク)内に格納するのか(= 画像DB化)？という判断。
もし前者であればソフトウェア(アプリケーション開発)だけ対応できるけど、
後者の要求を叶えるとすれば専用のストレージハードウェア導入も検討対象になる。
(2) 遺産データのデータ形式仕様
DVDに格納されている過去データについて、そのデータ形式仕様を把握する必要性があるという課題。
データ形式仕様には、(a) DVDボリューム構成、(b) DVD内のディレクトリ/ファイル構成、
(c) ログファイルのデータ構造などがある。この課題を、より具体的な副課題に分解してみる。
(2-1) その遺産データの作成者から仕様書を入手
作成した外部の業者(あるいは院内の担当者？)に問い合わせて入手できるのが理想。
もし入手不可であれば、自力で分析する、いわゆるリバースエンジニアリングという作業が必要。
(2-2) 入手した仕様書と(DVDに格納された)実データに一貫性があるかを検証
理想的には、すべての実データが仕様書に従って作成されていれば、
(相対的に)単純なスクリプト(プログラミング)でデータ移行処理が可能になる。
最悪なのは、手作業でDVDボリューム名/ディレクトリ名などを決めて焼いていたケース。
(2-3) ログファイルのデータ構造について機械可読性を確認
理想的なのは、XMLのような形式的なテキスト形式で保存されている場合。
もしも独自のバイナリ形式であれば、(2-1)のデータ形式仕様書の入手が必須になる。
最悪なのはフリーなテキスト形式のケースで、一件ずつ手作業で編集しなければならなくなる。
(3) 新規アプリケーション開発の必要性
理想的には、(2)の作業を経て準正規化(機械処理可能化)された中間データを、現行の(OLYMPUS?)
システムへ移行する(相対的に単純な)変換プログラムを作成することで、課題が解決できるケース。
もしもそれが不可であると判断されたなら、その中間データを元に新規DBの開発を検討する。
その場合には、どのようにDBを設計すべきか？という、このスレ住人向きの話題にようやく辿り着く。
480:479
11/03/13 07:23:59.19
>>479の課題(3)で新規DB開発を決定した場合に限定される話だけど、
医療関係者が(外部の業者に頼らずに)自力でデータベース化を図るとしたら、
FileMaker Pro というDBアプリケーションがよく知られている。
FileMaker Pro は、Microsoft製であればAccessに相当するデスクトップDBソフトだけど、
SQLを憶える必要は無いし、テーブル設計/画面デザインからスクリプト作成まで
すべてGUIで操作できるから、簡易なDBであれば専門家でなくても開発できるのでお勧め。
（個人的にはシステム分析初期段階のラピッドプロトタイピングに活用している。）
たとえば以下の医療画像管理アプリはソースも公開されている。
・マイコミジャーナル：ファイルメーカ選手権（第一回）月間優秀賞：患者画像記録
URLﾘﾝｸ(journal.mycom.co.jp)
FileMaker Proは試用版が無償で利用できるから、まずダウンロードして触ってみるのがいい。
質問等はビジネスsoft板に専用のスレがあるから、そちらへドーゾ。
481:NAME IS NULL
11/03/13 16:43:53.66 UrDSEA55
「はてな」や楽天のポイント履歴を見ていて思ったのですが、
ああいう頻繁にレコードの追加が発生するコミュニティサイトって
1テーブルのフィールド構成をどうしているのでしょうか？
単純に「日付｜ポイント数｜対象ユーザID｜対象動作ID」
で分けてるだけでしょうか？
でも、そう考えると、ユーザ数×履歴数で倍々に増えていくので
万単位の会員数があるサイトでは、ポイント履歴テーブルに
レコードが溜まりすぎるのではないか？と言う懸念があります。
ポイントというお金と変わらないものですから、
「○件まで保存。後は削除」と言うことはなかなか出来ないと思いますし・・・
482:NAME IS NULL
11/03/13 17:03:45.55
ヒント：それらのケースでは厳密なACIDは要求されない。
（もちろん楽天の商品注文処理には厳密なACIDは要求される。）
483:NAME IS NULL
11/03/18 16:34:48.59 N3L942K+
ショッピングサイトでのDB設計について
・注文テーブル、
・会員テーブル
があります。
会員が注文した場合は会員IDを外部キーとして注文テーブルに入れればいいのですが、
会員じゃない人からも注文が入るので、
注文テーブルに会員テーブルと同じようなフィールド（名前、送り先住所など）を入れて、
注文レコードに、会員ID（外部キー）が無い（NULLの)場合は、同じ注文レコードの名前や住所を参照しようと思っています。
もう１つは、会員テーブルと同じような、非会員テーブルをつくり、
会員じゃない人の住所情報などはそこに入れようという方法です。
後者の方が個人的にきれいな設計だと思うのですが、
この場合注文テーブルに入れる外部キーをどうするかがまた問題になって困っています（外部キーが非会員IDなのか会員IDなのかわからなくなる）。
これを解決するために、
非会員注文テーブル、
会員注文テーブル
と２つに分けることも考えていますが、
ここまですると逆に注文テーブルが２つになってしまうのできれいじゃなくなる気がします。
どうするのが一番良いでしょうか
484:NAME IS NULL
11/03/18 16:40:17.60
無駄すぎ
注文テーブルと会員テーブルだけでいいですがな
485:NAME IS NULL
11/03/18 17:21:13.97
>>483
まず最初にモデル分析について。
前者は論外。注文テーブルでは注文に関する情報だけを定義すべき。
残る後者について、「会員の人」と「会員じゃない人」という概念は、
人に関する集合を意味するわけだけど、これら両方を包含した全体集合を考えなさい。
たとえば「取引先」という概念は一般に両者を包含するからよく用いられる。
あるいは全体集合を「会員」として位置付けて、部分集合を「正会員(会員の人)」と
「会員候補(会員じゃない人)」とに分割するという、逆の発想でもかまわない。
次に実装についてだけど、これもいくつかの方法がある。
たとえばモデル分析で全体集合を「取引先」とし部分集合を「会員」および「非会員」とした場合、
テーブルとしては「取引先テーブル」だけを定義し、そのフィールドとして会員区分コードを設ける方法。
あるいは各集合に対応する３個のテーブルを定義する方法もある。この場合、「会員テーブル」と
「非会員テーブル」には外部キーとして(取引先テーブルを参照する)取引先IDを設けることになる。
どちらの方法を選ぶにしても、注文テーブルの外部キーは取引先IDだけになるから、課題は解決される。
486:NAME IS NULL
11/03/18 17:51:34.01
>>483
会員が自分の住所以外を送り先として注文することはないのかな?
487:NAME IS NULL
11/03/18 18:02:59.08
>>485
前者は論外、とも言えないんじゃないのかなぁ。
会員IDがNULLの時だけ名前や住所の値を参照するという運用には
とても疑問があるけれども。
483は取引後に会員の名前が住所や変更される可能性と、その場合
も過去の個別の注文に関してはその当時の住所や名前を保存して
おく必要性(普通は必要だと思うけど)を考えるべきだと思う。
その場合には注文テーブルにも名前や住所などのカラムを作って
注文毎に会員情報から転記する方法と、少し前に散々議論された
会員情報をサロゲートキー使って管理する方法がある。
488:NAME IS NULL
11/03/18 18:55:00.36 vy9E5dGG
論理キー(複合キー)があるのに、わざわざID列を主キーに作るの勘弁してくれ。
489:NAME IS NULL
11/03/18 20:32:06.47
単にSingle Table Inheritanceの典型的なケースではないの？
この辺を参考にすれば
URLﾘﾝｸ(capsctrl.que.jp)
490:NAME IS NULL
11/03/18 21:45:08.46 vy9E5dGG
典型的なプログラマー脳orパッケージ屋さんか？
491:NAME IS NULL
11/03/18 22:02:10.77
ではDB屋さん的な回答どうぞ。
492:NAME IS NULL
11/03/18 22:16:11.36
・注文テーブル
・顧客テーブル
・会員テーブル
に分ければ良いだけじゃん。
注文テーブルの顧客IDと顧客テーブルのIDをJOINして
顧客テーブルのIDと会員テーブルのIDをJOINする。
会員テーブルには、ID/パスワードなど、ログイン専用のデータだけを保存する。
こうすれば会員じゃない人は顧客テーブルの参照で済むし、
会員なら会員テーブルまで参照すれば良いだけのこと。
493:NAME IS NULL
11/03/18 22:26:40.26
・注文テーブル (送り先の名前・住所入り)
・会員テーブル (会員の名前・住所入り)
かな。送り先の名前や住所は会員IDではなく注文IDに関数従属
するものだから、別のテーブルに分ける理由がない。
もちろん会員テーブルを過去の更新分も含めてサロゲートキーで
管理して、非会員の情報についても別の顧客テーブルなんちゃら
に分ける方法もあるけれども、無駄にスキーマが複雑になる。
判断は会員/非会員の注文の割合とか(非会員の注文が例外的か)
とかにも依存するけれども、単に注文毎に送り先を保存したい
場合は上のやり方が一番シンプルで良いと思うんだけど。
494:NAME IS NULL
11/03/18 22:29:31.66 N3L942K+
>>484
会員テーブルに、非会員フラグなどのフィールドを入れるということですね？
>>487
> 483は取引後に会員の名前が住所や変更される可能性と、その場合
> も過去の個別の注文に関してはその当時の住所や名前を保存して
> おく必要性(普通は必要だと思うけど)を考えるべきだと思う。
それは全然考えてなかったですね・・・たしかに必要かも。
ということは、
>>492
の方法が一番良さそうですかね？
この>>492の顧客テーブルというのは、注文の住所や名前情報などがはいるんですよね？
注文レコードの数＝顧客レコードという認識ですが正しいでしょうか
495:NAME IS NULL
11/03/18 22:33:01.55 N3L942K+
>>493
この方法も良さそうですね
496:NAME IS NULL
11/03/18 22:42:31.73
>>494
・注文テーブル → 注文日時、ステータス、商品合計金額
・（注文商品テーブル） → 注文した商品のIDと価格
・顧客テーブル → 名前や住所
・会員テーブル → ログインIDやパスワード
こう考えてみたらどうだろう
497:NAME IS NULL
11/03/18 22:53:33.73
>>490
？
めちゃくちゃDB設計の話だと思うけど
498:NAME IS NULL
11/03/18 23:00:42.16 N3L942K+
>>493の方法でいいかなと思っているのですが、
>>493の方法と比べて>>496の方法（顧客テーブルをはさむ）のメリットはなにがありますか？
499:NAME IS NULL
11/03/19 00:18:10.77
>>498
>>493の方法の場合、例えば会員から注文があった場合には会員テーブル
から会員の名前や住所を送り先として注文テーブルに転記する必要がある。
会員の名前や住所はそうそう変わらないだろうから、同じ情報がテーブル
中に繰り返し現れるわけで、そういう意味では冗長でストレージの無駄。
>>496の場合は、これがない。
ただ>>496の方法で会員テーブルの結合に会員IDを使ってしまうと、ある
会員の名前や住所が変更になると過去の注文分に関しても送り先の情報が
変更されてしまう。注文履歴の正しい管理という意味でこれは拙い。
なのでこういう場合は会員テーブルに代理キーを立てて結合条件にはこれを
用い、会員情報を変更する場合も古い行はそのまま残して新しい行を会員
テーブルに追加する方法で対応する場合が多い。
言葉だと説明し難いので、過去ログを参照するかサロゲートキーで検索して
欲しい。
いずれにしても、会員/非会員の注文頻度の割合(非会員の注文も多い場合は
>>493のデメリットは相対的に小さくなる)、会員情報の更新頻度、あと
は注文データの件数によると思う。
ストレージの無駄さえ許容できれば>>493は一番シンプルな解だと思う。
500:NAME IS NULL
11/03/19 00:27:12.05
そうか。顧客情報が変更になると注文情報も変更になるから
>>496だと整合性がとれなくなるよな。
>>493の方法は重複が出るけど、「過去○ヶ月のデータまで保存」
みたいな感じで、期限切れのデータは削除するかバックアップすれば
レコードの肥大化も極力抑えられる。
501:NAME IS NULL
11/03/19 01:53:20.02
>>497
しかし>>489は回答にすらなっていない。
要件についてツッコミも考察も入れず「○○パターンで出来るよね～」
なんて真っ先にのたまうのは典型的なプログラマ脳だ。手元の技術しか
見えていない。
502:NAME IS NULL
11/03/19 06:59:20.11
「住所」が顧客の現住所(連絡先)なのか配送先なのか、はたまた配送先の
デフォルト値なのか、そういう分析がしっかりされないまま設計に入っても
議論がワヤになるといういい例だな。
503:483
11/03/19 13:14:35.62 jv8AI/hU
みなさんありがとうございました。助かりました。
会員の注文時の送り先住所は、
会員の住所が変わっても、変えてはいけないというのは盲点でした。
>>493の方法でいこうと思います。
これなら注文毎の住所が保存され、
会員の住所も保存できそうです。
会員の注文のときは、会員テーブルから住所をコピーして注文テーブルへ。
非会員の注文は、そのまま記載された住所を注文テーブルへ格納する。
という実装でいきたいと思います。
504:NAME IS NULL
11/03/19 13:40:41.51
>>502
それは設計しながらでいいんじゃねーの？
仕様書作りながら「これはこういう可能性があるからこうしよう」
みたいな意見が生まれるじゃん。483のやりとり見ても生まれてるわけだし。
505:483
11/03/19 14:55:37.30 jv8AI/hU
まてよ、
>>493
> ・注文テーブル (送り先の名前・住所入り)
> ・会員テーブル (会員の名前・住所入り)
この方法だと、例えば新たに「電話番号２」カラムを追加したいときに、
２つのテーブルをいじらないといけないので、保守性の面であまり良いと言えないかもしれませんね。。。
なので、
・テーブルX
名前、住所などを入れるテーブル（名前が思いつかない。顧客情報テーブル？）
をつくって、
注文テーブルや、
会員テーブルからはテーブルXのIDを外部キーとして保存するという方法を考えました
（それが>>492の方法でしょうか？）
これなら新しい項目が増えても、テーブルXを１つ編集すればいいだけなので解決しそうです。
実装方法は>>503の方法と基本的に同じで、
新たに注文が発生した場合は、
・会員の場合
テーブルXに保存されている会員情報を、
新たにテーブルXのレコードとしてコピーして、このIDを注文レコードの外部キーとする
・非会員の場合
テーブルXに入力値を保存
このような形でつくろうと思います。
またご意見をくださいますでしょうか。
>>504のおっしゃるとおり、一人で開発しているので、
つくりながら仕様も決めていくような方式をとっているので、小出しになっていたら申し訳ないです
506:483
11/03/19 15:04:27.95 jv8AI/hU
まとめると、
- 注文テーブル
・テーブルXのID（外部キー）
- 会員テーブル
・テーブルXのID（外部キー）
- テーブルX
・名前
・住所
・電話番号
：
：
この、テーブルXで名前住所などはすべて管理して、
あらたに会員が「届け先住所２」を追加したい場合は、
テーブルXに新しいレコードを追加して、そのIDを
会員テーブルの「届け先住所２」カラムに外部キーとして保存する、といった形になります。
507:NAME IS NULL
11/03/19 16:00:36.14
そもそも規模によっては住所２が必要ない場合あるぞ。
小規模、顧客1000人以下程度ならいらないと思うけどな。
必要な時に追加したら良いんだよ。
508:NAME IS NULL
11/03/19 16:18:47.06
会員と非会員の注文比はどれぐらい?
非会員の注文数が多いようだと住所項目等を別テーブルに
切り出すメリットはかなり減るよ。
509:483
11/03/19 17:23:23.64 jv8AI/hU
>>508
現行のショップは会員という概念がなかったので、
今回会員を実装してどれぐらい会員になるかは未知数ですね。
ただ、非会員で買い物をするメリットというはあんまり無いので、
（会員になってもパスワードという入力項目が増えるだけ／会員になると今後の住所入力不要）
会員になる人が多くなると予想はしています。
ただ本当に具体的な比率は未知数です。
510:NAME IS NULL
11/03/19 18:10:41.88
会員になる人が多いか否かは商品によるんじゃね？
Amazonのように購入ペースが多いなら会員登録するだろうけど、
電化製品や服とかは、会員登録しなくても買いそうだけどな。
511:NAME IS NULL
11/03/19 18:12:40.61
>>509
まず、
・会員情報に書かれる住所や名前や電話番号
・注文票に書かれる送り先の住所や名前や電話番号
ははっきり区別して考えた方が良いと思うよ。
例えば会員情報としては複数の住所や電話番号を持つことも
あるかも知れない。でもそれを全て注文票に転記する必要が
あるかというと、そうでもないと思う。
書かれている「新たに電話番号２カラムを追加したいときに」
の場合も、会員テーブルは変更する必要はあるかもしれない
けど、注文票にまで複数の電話番号を書き込む必要があるか?
というのは一度精査してみた方が良いと思う。
512:483
11/03/19 20:12:44.29 jv8AI/hU
>>511
たしかに。
やっぱり>>493がシンプルで良さそうだなぁ。
ぶれまくりですが、とりあえず先に進んでみようと思います。
また問題が発見してから考え直します。
みなさんありがとうございました。
513:NAME IS NULL
11/03/19 21:26:29.97
プログラマ脳はどこへ行った?
514:NAME IS NULL
11/03/20 22:16:51.93 77T4BkwY
エンティティとか主キーの概念がなくて
なんでも１テーブルに押し込む、キーはID列のみみたいなのはマジ勘弁
515:NAME IS NULL
11/03/20 22:26:24.40
>>514
大福帳テーブルは意外と重宝しますよ。
516:NAME IS NULL
11/03/20 23:11:01.39
>>515
うん。する。
517:NAME IS NULL
11/03/21 08:13:31.36
NoSQLの設計はまさにそんなかんじじゃない？
518:NAME IS NULL
11/03/23 04:59:34.66
.NETのコンポーネントの制限で複合キーを諦めざるを得ない
519:NAME IS NULL
11/03/23 23:09:03.86 MVHfXd/l
複合キーは無いわ
全テーブルにid int auto_increment でおｋ
520:NAME IS NULL
11/03/23 23:27:16.79 pi71qtr7
まさにプログラム脳
521:NAME IS NULL
11/03/24 01:02:41.70
>>519
つけるべきUNIQUE制約を忘れるなよ。
つけなければならない理由も。
522:NAME IS NULL
11/03/24 14:48:10.96
>>519
MySQL脳か。
523:NAME IS NULL
11/03/24 22:24:42.09 G0Glp4Mc
今一緒にデータ移行の仕事してる人は業務的には複合キーのデータでも
キー値を１つにマージした列をわざわざ作ってるんだよなあ。
なんでもJOINするときにマージした列でJOINした方が早いとかw
複合キーでもINDEX張ったりすれば遅くないですよって言っても信じてくれない。
524:NAME IS NULL
11/03/25 04:20:43.76
複合キーでもサロゲートでもいいが、キー値のマージは一番アホ設計だと思うｗ
525:NAME IS NULL
11/03/25 04:42:34.88
とりあえず日時型をキーに追加するアホが身近にいるので困る
526:NAME IS NULL
11/03/25 04:51:01.91
正規化崩しもそうだけど、解っていない人ほど「この方が速い」とか
キリッとのたまうんだよなぁ。
527:NAME IS NULL
11/03/26 12:30:09.50
会社マスタ
CompanyID(PK) , CompanyName
01 A社
02 B社
03 C社
支社マスタ
CompanyID(PK) , BranchID(PK) , BranchName
01 01 本社
01 02 埼玉支社
01 03 神奈川支社
(略)
例示した支社マスタみたいな複合キーが使えない場合、
どういうキーを振るのが普通なの？
CompanyID+BranchIDの連結でやってるけどダメ？
528:NAME IS NULL
11/03/26 17:27:46.83
ダメってことはないけど、CompanyIDとBranchIDを残してunique制約付けるなら
サロゲートキーは別に本来のキーと関係ある値にする必要はない。
529:NAME IS NULL
11/03/26 19:35:25.40
>>527
なぜ複合キーが使えないのかわからん
その例なら、CompanyIDとBranchIDの複合キーじゃないのか？
その例なら単にBranchIDを支社マスタ内で一意になるように振れば良いだけだと思うけど
530:NAME IS NULL
11/03/26 22:15:51.71 Ib5l6n2v
Companyコードはどこにあるの？
531:NAME IS NULL
11/03/26 23:17:25.27 U28l837d
>>527
システム以外の都合でIDが決まる場合が少ない確率ながらある
（ID=1を本社にしたいとか、支社IDを使い回すとか）から、
やっぱり複合キーじゃなくて
全テーブルにIDを振るのがいいと思うんだがなぁ
なんでこのスレの人は否定するのかね
532:NAME IS NULL
11/03/26 23:50:53.54
>>531
いや、普通に脳みそ足りなさそうな発想だから否定されて当然。
別に誰も代理キーを絶対に使うななんて言っていないでしょ。
要件をスキーマ設計に落とす過程で必要になった時に用法に注意
して使えば良いだけの話。
そのあたりをすっ飛ばしてトップダウンに「全テーブルにID振る」
なんて単細胞なアイデアを持ち出すから叩かれる。
533:NAME IS NULL
11/03/27 05:15:34.98
支社マスタ
BranchID(PK) , BranchName
0101 本社
0102 埼玉支社
0103 神奈川支社
複合キーが使えないケースならこうせざるを得ないだろ
無関係なサロゲートキーでどうやって会社マスタとの紐付けを取る気だ
534:NAME IS NULL
11/03/27 07:04:25.57
サロゲートキーを使うならこうだろ。
BranchKey not null,
CompanyID not null,
BranchID not null,
primary key ( BranchKey ),
unique( CompanyID, BranchID )
「複合キーが使えない」というのが複数カラムのUNIQUEも使えないという
意味なら別だが。
535:NAME IS NULL
11/03/27 15:12:06.00
複合キーが使えないってのがどういうことかわからんが
おそらく
CompanyID(PK) , BranchID(PK) , BranchName
01 01 本社
02 01 本社
みたいなことを想定してるんだと思うが、それなら
支社マスタって書いてるテーブルが、支社のマスタと
会社と支社のリレーション持ってるテーブルを兼用してるのが間違いだろ
536:NAME IS NULL
11/03/27 15:41:43.57
それのどこが間違いなのかわからん。
537:NAME IS NULL
11/03/27 15:45:16.49
多分どっちでもいいんだよ。
どっちかしか駄目という人が間違ってる
538:NAME IS NULL
11/03/27 16:19:08.97
>支社マスタって書いてるテーブルが、支社のマスタと
>会社と支社のリレーション持ってるテーブルを兼用してるのが間違いだろ
なんで間違いなん？
539:NAME IS NULL
11/03/27 17:25:52.72
>>535
それが間違いだとして、テーブルを分けたとしても、その場合
会社支社リレーションのテーブルで同じ問題が起こる
そこが間違ってるかどうかは本質じゃない
じゃあ本質は何かっていうと
>複合キーが使えない場合、どういうキーを振るのが普通なの？
ってことだ
複合キーが使えない理由がよくわからんが、複合キーがダメなら代理キー作るしかないわな
代理キーの値をどうするかだが、ぶっちゃけ一意になれば何でも良いわけで
システム的に一意な連番振る機能があれば、それが使われることが多い
その場合は一意であることをシステム側で保障できるから
CompanyID+BranchIDの連結とかでもいいけど、その場合、それが一意かどうか
自分でチェックしないと保障されない
まあどっちにしろ要件的にCompanyID+BranchIDで一意チェックは必要だと思うから
この二つで主キーにしとけばシステム的に一意性が担保されるわけだが
540:NAME IS NULL
11/03/27 19:55:32.48
たいていの場合CompanyID+BranchIDが一意になるとは思うが
仮にCompanyIDないしBranchIDを変更することになった場合
キー値も変更しないと気持ち悪いことになる
541:NAME IS NULL
11/03/27 20:09:12.32
連番使った場合はCompanyIDとBranchIDから代理キーの値を得るのに
支社テーブル上で逆引きをする必要があるけれども、CompanyIDと
BranchIDの連結をキーにした場合はアドホックに文字列処理でキーの
値が手に入るという利点は一応あるw
ただそういう設計や運用はあまり見ないよなぁ。やはり勘所は複合キー
が使えないという理由がよく分からん事だと思う。
ORMマッパー使っているからとか、DBMSの実装上の制約とか、上司の
オッサンが決めてしまったコーディング規則でそうなっているとか、
理由ごとに必要とされる答えも微妙に違う気がする。
542:NAME IS NULL
11/03/27 20:17:45.17
>上司のオッサンが決めてしまったコーディング規則でそうなっているとか
これに500点
543:NAME IS NULL
11/03/28 02:42:35.68
いや、単純にコンボボックスのデータソースに出来ないからだよ
544:NAME IS NULL
11/03/28 02:51:30.55
CompanyIDを先に選択させりゃいいだろ
545:NAME IS NULL
11/03/29 11:09:24.60 1gjc3MDS
>>532
無知で悪いけど、
「全テーブルにID振る」
これのデメリットってなにがあるの？
546:NAME IS NULL
11/03/29 13:14:53.99
>>545
何の解決にもなっていないから。
連番をカラムとして追加してそれをテーブルの主キーにしたところで
「要件によって決まる」候補キーは歴然として存在するわけであって
そこに制約をつけたりアプリケーションのロジックを書いたりしないと
結局はデータの整合性は保たれないから。
「全テーブルにID振る」は実装上の方法論にすぎず、その前段階として
要件の分析をすっ飛ばすことは出来ない
ちゃんと分析をやった上で全テーブルに代理キー振るのなら、いいん
じゃない? ただその場合は当然分析の結果として必要な代理キーと共に
冗長な代理キーも見えてくるはずで、その評価は出来るよね。
547:NAME IS NULL
11/03/29 16:32:09.66
もう少し馬鹿にもわかりやすく答えてくれ
548:NAME IS NULL
11/03/29 17:11:30.69
全テーブルにID振ること自体は「無駄」以外にデメリット無いよ。
OracleのROWID疑似列みたいな例もあるわけだし。
ただそれを無批判に主キーとして用いるのにはデメリットというか
危険性がある。例えば自然キーが存在するのを忘れてUNIQUE制約
を付け忘れたため危険な重複タプルが発生したりとか、変更の可能性
が無い自然キーに対しても代理キーを用いることでトランザクション
表の更新時に自然キーから代理キーの値を得る無駄な逆引きが必要に
なったりとか。
代理キーを持ち込むことで検索はともかく更新は一般的に複雑に
なりやすい。
個人的には要件の見落としを防ぐ意味でも、まず初めに自然キーを
主体にしたスキーマ設計に落として、そこから必要に応じて代理キー
を導入するのが一番安全だと思う。
何度も言うけれども、自然キーはまず要件から決まるものだから。
549:NAME IS NULL
11/03/29 17:54:47.01
＞表の更新時に自然キーから代理キーの値を得る無駄な逆引きが必要
いや別にいらんだろ
自然キーのユニークネスが保証されてるなら
550:NAME IS NULL
11/03/29 22:02:11.24
外部キーとして持つ場合なんかの話だろ
551:NAME IS NULL
11/03/30 01:03:54.95
CREATE TABLE tablename (keyid VARBINARY(50) , columnid VARBINARY(50) , value BLOB , PRYMARY KEY(keyid , columnid));
ですべてことたりる
552:NAME IS NULL
11/03/30 01:56:16.14
その分アプリのロジックで苦労するわけだけれどもね。
553:NAME IS NULL
11/03/30 18:31:30.02
>>551
ガリレオ・ガリレイ
554:NAME IS NULL
11/03/30 23:04:14.47
このスレと
【より良い】データモデリング【モデルを】
ｽﾚﾘﾝｸ(db板)
こっちのスレって何が違うの？
上流の作業の違いがいまいちよくわからん
モデリング後に設計？設計後にモデリング？
555:NAME IS NULL
11/03/30 23:57:39.00 1ro9g/Hl
住所の項目ってどうしてるよ？
都道府県と住所１と住所２（マンション名など）
って分け方が多いみたいだけど、
都道府県以外分ける必要ないよね
556:NAME IS NULL
11/03/31 00:09:50.64
>>555
たとえばタックシールや送り状を作成する業務を考えると
住所が適当な長さで２行になってる方が都合がいいだろ
業務要件で住所が２行必要ならDB上も２項目でもつのは普通
つまり分ける必要があるかどうかは要件次第
557:NAME IS NULL
11/03/31 00:18:34.96 P2ST+s4H
２行かどうかなんてアプリケーション側の問題なんじゃ？
558:NAME IS NULL
11/03/31 00:40:24.56
要件に二行で折り返すことが含まれているのであれば、どこで
折り返すのか区切りが解らないと困るじゃん。
改行入りの文字列を住所として突っ込むのもありだけど、住所と
マンション名その他に分けて二つのカラムに分けて入れることが
多いと思う。
559:NAME IS NULL
11/03/31 00:40:37.54
アプリケーション側の問題？
データモデルが常にそれらから独立していられるわけでもないだろう。
560:NAME IS NULL
11/03/31 01:27:27.86
>>555
+--id--+--henji--+--syugo--+--dousi--|
| １ | YES | I | DO |
+----------------------------------+
561:NAME IS NULL
11/03/31 20:36:43.35 WO6NrX3S
>>555
> 住所の項目ってどうしてるよ？
郵便番号が取得できるなら郵便番号DBを利用する
できないなら総務省の地域コードを使う
コード変換できない番地以下は各レコードに持たせる
最低でもこうしないと話にならない
562:NAME IS NULL
11/03/31 20:53:20.54
DB的には住所をコード化するのが先決だわな
2行でタックシール(ｷﾘｯ)とか馬鹿じゃねえの
563:NAME IS NULL
11/03/31 21:52:14.51
単に土地住所と建物住所じゃないの？
564:NAME IS NULL
11/03/31 22:57:25.26
タックシールの馬鹿を見るだけで、全角英数は馬鹿という定説が正しいことがよく分かる
565:NAME IS NULL
11/04/01 00:06:20.96
DB的には氏名をコード化するのが先決だわな
566:NAME IS NULL
11/04/01 00:35:02.02
「コード化する」ってなに？
567:NAME IS NULL
11/04/01 00:42:28.28
たっくんおかえり
568:NAME IS NULL
11/04/01 00:48:36.32
(国)、都道府県、市町村、町域、建物その他で分けるだろ
569:NAME IS NULL
11/04/01 07:05:20.44 QNKMILe9
郵便番号検索とかどうしてる？
新しい市町村増えたり、メンテが面倒そうなんだけど
570:NAME IS NULL
11/04/01 07:09:15.74
そうだよ。
だから郵便番号検索機能が仕様にある場合はメンテ分も見越して金額が跳ね上がらないといけない。
現実は「簡単でしょ？付けてよ」でプロジェクト終わり。
571:NAME IS NULL
11/04/01 07:25:43.06
要件確認せずに、「だろ」って決め付けてもねぇ。
地番は？住居表示はどうすべきだと思ってるの？
572:NAME IS NULL
11/04/01 10:02:49.85
初心者ですDBの勉強もかねて、簡単なユーザ登録のできるBlogサイト作成しようと思っています。
日記のデータを保存するテーブルについて質問なのですが、一般的(他のサイトなど)に日記を保存している
テーブルというのは、1つのテーブルで全ユーザの日記のデータを保存しているのでしょうか？
例えば一般的には、ユーザID,日付,日記本文,(その他省略)という構造なのでしょうか？
この場合、ユーザ数が増えれば相当なデータサイズになり、1ユーザの日記を数日分、selectするのに時間が
かかるような気がします。(この辺が初心者で、時間がかかるのかもよくわかってないのですが・・・)
573:NAME IS NULL
11/04/01 11:09:31.44
まぁそのためのデータベースだ
適切な設定なら100万レコードからでも一瞬で目的のレコードを探せるよ
574:NAME IS NULL
11/04/01 22:51:49.57
それだと、日記が一日ごとにしか書けないな。
575:NAME IS NULL
11/04/01 22:54:03.22
適当な質問には適当な回答しか無いだろ
576:NAME IS NULL
11/04/02 02:10:35.17
お前ら、こういうDB設計の要件定義って、
仕事でやる場合どのくらい時間かける？最低1ヶ月はかかるよね
577:NAME IS NULL
11/04/02 02:18:13.66 SR6eBDqn
>>570
そういう情報ってどっかにAPI公開されてないのかな
もしくはデータが簡単にダウンロードできたり
578:NAME IS NULL
11/04/02 02:41:31.19
>>577
データは郵便局サイトに
コンポーネントもググれば簡単に見つかる
大概↑データを使用する前提
579:NAME IS NULL
11/04/02 09:09:49.55
つーか、ろくすっぽ調べず「郵便番号メンテが面倒」とか、「住所は二行でタックシールだ！」
とかその手の足りない子を見ると、正規化だのサロゲートキーだのを熱く語る前に、他にやるべき
ことあんじゃねえのって感じだな
580:NAME IS NULL
11/04/02 12:53:38.07
なんか、面倒だな
581:NAME IS NULL
11/04/03 15:32:48.21
それでも地球はまわっている
582:NAME IS NULL
11/04/03 17:10:43.94
そして原発は冷却中である
583:NAME IS NULL
11/04/03 23:20:21.80
>>568
そんなの、実データ使った解析でいかようにもできる。
客が入力したままの文字列を一つだけ保持しておけば、あとは正規化した住所を都度アプリ側で吐き出せばいい。
584:NAME IS NULL
11/04/04 00:39:15.82
>>583
アプリに全部任せてDBは設計もクソもなくていいって聞こえるが・・・
585:NAME IS NULL
11/04/04 00:47:44.84
座標保持するのが流行り
586:NAME IS NULL
11/04/04 06:56:16.69
>>585
ダイレクトメールという文化はやがて滅びるから
企業の視点では、住所や所在地情報の地位は
低下し続けるに違いない。
587:NAME IS NULL
11/04/04 07:51:03.48
>客が入力したままの文字列を一つだけ保持
こんなこと書いてるエセ設計者の言うことは無視でよろし
588:NAME IS NULL
11/04/04 19:32:50.57
エセというか、ただの馬鹿だろ
せっかく公共団体の統一コードがあるのに文字列で持たせるとか正気か？
どうせAccessあたりで糞アプリ作ってる底辺プログラマだろけど
589:NAME IS NULL
11/04/04 20:51:35.27
DM用や顧客用のデータなんだろ？
正規化用のデータを、持しても客が使うデータは、たとえ間違っていても入力のママで使うんだよ。
現場も知らない馬鹿が教科書通りに設計すると回らないから気をつけろw
590:NAME IS NULL
11/04/04 22:22:53.14
正規化と言いたいだけの中小企業Access使いとか、底辺を見ても何の参考にもならないし、
時間の無駄だから、まともな知能を持った人は郵便番号DBや地方公共団体コードを使いましょー
591:NAME IS NULL
11/04/04 22:23:08.98
馬鹿にしてるつもりなのかな？拙い日本語使って煽られてもねぇ・・・
592:NAME IS NULL
11/04/04 22:54:36.58
ハンマーを持った子供には何でも釘に見える
地方公共団体コードなんて覚えたての子供は、「住所」と出てきたらコードを
使わなきゃ気が済まないんだよ。
593:NAME IS NULL
11/04/04 23:40:02.69
まあ、要件も確認せずに何とかコードでOKとか言うやつは
まともな知能を持ってないってのは解る
あと底辺の人ほど他人を底辺だって決めつけるよな
バカっていうやつがバカ的な感じ
594:NAME IS NULL
11/04/04 23:46:14.17
たっくんおかえり
595:NAME IS NULL
11/04/05 00:53:48.93
>>590
名寄せのロジックの一部には郵便番号DBも使うが、あくまでも一部。
おまえ、日本全国の何百万という重複する住所の名寄せなんてしたことないだろ。
したことがあれば、あんな不完全なデータを錦の御旗にドヤ顔出来る訳がない。
596:NAME IS NULL
11/04/05 07:29:40.55
>日本全国の何百万という重複する住所
具体例どぞ
597:NAME IS NULL
11/04/05 07:33:04.51
>>596
どこそこ区の青葉台となになに市の青葉台で一例。
この組合わせを合計するとそんな数になりそう。
598:NAME IS NULL
11/04/05 08:24:56.02
>>597
そういうのは都道府県が違うので重複とは言わない
もっと例示するにふさわしい具体例を挙げるよろし
599:NAME IS NULL
11/04/05 08:53:52.43
>>596
数十万単位のユーザーが十数年にわたって複数回入力する住所の名寄せだよ。
当然ユーザーからしてみれば同じ住所でも入力パターンは間違いも含め多岐に渡り、市町村合併や郵便番号も変わるからね。
600:599
11/04/05 09:10:15.59
他にも英語表記やカタカナ、ひらがな表記も含む。
市区町村の区分も守られておらず(特に町と村。そもそものインターフェースが郡で区切ってたりする)、都道府県が空白なんてざら。
複数のインターフェース、複数の時代を経た巨大な住所データなんて蓋を開ければこんなもん。
入力時に住所が正規化される単一のシステムならなんの問題もないけど、そうでない上記のようなデータなら、住所は一旦すべて連結し、解析掛けるのが正確で早い。
601:NAME IS NULL
11/04/05 09:13:12.42
だからコードにしておけば手入力を解析だ名寄せだとかキチガイじみた発想にならんのだって
ためしに通販サイトかなんか見てみろよ
大抵、プルダウンから選択か、郵便番号から選択だろが
逆に手入力のメリットがあるなら出してみろや
602:599
11/04/05 09:24:48.43
>>601
日本語分かるか？
入力時に正規化出来るなら問題ないがと書いてるだろ。
新規で開発するような話をしてるんじゃなくて、手書きも含め、複数のインターフェースが存在することが前提のデータ処理の話をしているんだが。
603:599
11/04/05 09:28:14.95
>>601
そして、コード化の一番のデメリットは過去の住所はにたいおうしづらい
604:599
11/04/05 09:37:39.53
>>601
失礼、途中で送信してしまった。
コード化のデメリットは過去のデータに対応しづらいという事。購入、決済データぐらいじゃそこまで気にする事はないし、下手すればそもそもの住所の正規化すら要らないケースが多いけど、
過去にさかのぼる名寄せみたいに、コード化よりも解析のほうが現実てきなケースがある事を知っておいて損はない。
605:NAME IS NULL
11/04/05 18:49:22.35 Ge8zwV8y
>>602
> >>601
> 日本語分かるか？
> 入力時に正規化出来るなら問題ないがと書いてるだろ。
名無しIDなしでお前のレスがどれだかわかるわけねーだろw
つーか、DB設計の話をしてるのに名寄せだ解析だとか言い出すから、
頓珍漢に拍車がかかるんだっての
データ移行が要件なら、その解析とやらに使う労力を変換に割り振れよww
言ってることが支離滅裂だっつーのw
606:NAME IS NULL
11/04/05 19:31:24.00
>>605
要するに何の話をしているんだい。
607:599
11/04/05 20:05:05.66
>>605
わざわざ599と入れてるのも分からない馬鹿かw
だから、DB構造としては、住所は一つまのカラムしかもってない(まあ郵便番号くらいは持つが)と言う事だよ。
一応、入力時は分割されてるが、それを連結したものが正式なデータとしてつかわれる。
正規家した住所は複数のカラムを持つが、それは都度都度の最新住所を吐きだすワークテーブル扱い。
高言う実例もあるんだよ。
608:NAME IS NULL
11/04/05 20:20:17.47 Ge8zwV8y
>>606
・住所をまんまの文字列で持つメリットは全くない
・文字列を保持して解析とか言ってるのは池沼
・名寄せとかいきなり言い出してるのは馬鹿(同じやつだろうけど)
・タックシール(ｷﾘｯ
ちなみに文字列解析が現実的とか、噴飯ものの物を知らない子
みたいだけど、世の中にはコンバータってのが売っていてだな、
それで変換できないのは、対象外にするか、客先マターにするか、
その辺は契約にもよるけど、少なくとも俺らが住所と関わるって
のはそういうもんなの
いくら底辺プログラマで単価が安くても、アホな設計の尻拭いに
工数かけて解析とかありえねーよw
コンバータ買ってもらえって
とここまで書いたらタックシールが性懲りもなく現れた
もはや解読困難で相手にすんの面倒くさいから、他の人に任せる
といことで逃亡
609:NAME IS NULL
11/04/05 20:22:29.70
大変だなぁ。で、設計の話はどこ？
610:599
11/04/05 20:50:16.33
>>608
コンバーターは、それぞれの企業が自社で使う必要があって開発したものなことも知らないのか。
どんだけ小さな現場しか知らないんだよw
入力データを正規化して保持して、オリジナルを破棄出来るなら苦労はないんだよ。
自分の知らないしくみがあることは恥でもなんでもないのに、実例紹介してるのに信じないなら勝手にしろw
611:NAME IS NULL
11/04/05 20:50:39.64
変換ソフトの稟議書作成じゃね？
612:NAME IS NULL
11/04/05 20:53:18.81
>>610
設計の話しないなら帰れよ。
613:NAME IS NULL
11/04/05 21:00:32.80 r6xQc+hf
コンバータってこれか
URLﾘﾝｸ(www.addressmatch.jp)
昔住んでいた埼玉県大宮市高鼻町で検索したら、一発で変換できた！
オラ良いこと知ったぞ
でももう埼玉は住みたくない
614:NAME IS NULL
11/04/05 21:20:38.76
正直、なぜこんなのでこの人たちがここまで熱くなれるのか疑問ではある