DB設計を語るスレ 3

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 2chのread.cgiへ]
Update time : 05/18 01:59 / Filesize : 232 KB / Number-of Response : 717
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

DB設計を語るスレ 3

1 名前：NAME IS NULL [2010/03/26(金) 15:39:21 ID:WShq9Pbx]: 引き続き語れ！！

前スレ
DB設計を語るスレ２
pc11.2ch.net/test/read.cgi/db/1223458453/

過去スレ
DB設計を語るスレ
pc11.2ch.net/test/read.cgi/db/1166540159/
2 名前：NAME IS NULL mailto:sage [2010/04/07(水) 09:27:33 ID:???]: またサロゲート厨か
3 名前：NAME IS NULL mailto:sage [2010/04/14(水) 19:34:41 ID:???]: T字形ERマスターの俺様が華麗に2ゲット!
4 名前：NAME IS NULL mailto:sage [2010/04/17(土) 02:43:18 ID:???]: 有給と勤怠の管理システム作ってるけど、
有給の設計むずいな。前年度の繰越とか
5 名前：NAME IS NULL mailto:sage [2010/04/17(土) 18:26:32 ID:???]: 社員　今年残　前年残
A　　　　　20　　　15
B　　　　　5　　　　9

で消化するとき今年残から先に減らせばいいだけ
繰越は単に今年残→前年残、今年残→規定リストからセットで済む
6 名前：NAME IS NULL mailto:sage [2010/04/18(日) 17:34:12 ID:???]: なにそのくそせっけい
7 名前：NAME IS NULL mailto:sage [2010/04/18(日) 22:26:32 ID:???]: どうしろと
8 名前：NAME IS NULL [2010/04/21(水) 00:38:45 ID:GuWbcNTa]: 簡単なのでいいから勤怠管理の設計載ってるサイト教えて下さい
9 名前：NAME IS NULL mailto:sage [2010/04/21(水) 14:58:34 ID:???]: 俺だったら、年次ごとに与えられた日数と消化した日数は別々に保存する。
計算結果だけ保存するのは、俺の感が駄目だと言ってる。
10 名前：NAME IS NULL mailto:sage [2010/04/22(木) 03:22:06 ID:???]: 有給テーブル
取得日
日数

勤怠テーブル
日付
出勤時間
退社時間
勤怠区分

勤怠区分テーブル
勤怠区分

有休残計算はストアドとかで
11 名前：NAME IS NULL mailto:sage [2010/04/30(金) 13:54:02 ID:???]: T字型マスターの俺様、なんとか言ってやってください！
12 名前：NAME IS NULL mailto:sage [2010/05/04(火) 21:11:32 ID:???]: 自分達に無い物を作ろうとするから、どう設計すれば良いのか見えないんじゃね?
13 名前：NAME IS NULL mailto:sage [2010/05/06(木) 17:59:31 ID:???]: 有休テーブル
+社員ID
+年次（っぽいもの）
+付与日数

有休実績テーブル
+社員ID
+年次（っぽいもの）
+消化日数

有休実績テーブル（案２）
+社員ID
+取得開始年月日
+取得終了年月日

今現在の有休残はストアドとかで
14 名前：NAME IS NULL mailto:sage [2010/05/06(木) 23:53:16 ID:???]: >>13
有給実績テーブルの消化日数って、有給テーブルにくっつけたらダメなの？なんでわけてんの？
15 名前：NAME IS NULL mailto:sage [2010/05/07(金) 00:51:45 ID:???]: 13じゃないのに勝手に答えるけど、
それだと付与・消化の属性を追加して使い分けるとか
あるいはrowそのものを書き換える必要が出てくるじゃない

テーブルで分けといた方が分かりやすいと思うな
休んだ日数を細切れでブっこんでおいて、全体の消化日数はID＆年次でselectしてsum取ればいいし
16 名前：NAME IS NULL mailto:sage [2010/05/07(金) 10:15:44 ID:???]: >>14
有給の付与が年度の開始時にしか起こらないって脳内ルールを作ってないか？
17 名前：NAME IS NULL mailto:sage [2010/05/07(金) 12:14:53 ID:???]: つまりそれは回りまわって>>12に帰結するわけだな（涙
18 名前：NAME IS NULL mailto:sage [2010/05/07(金) 20:15:10 ID:???]: 有効期限があるポイントを管理しなきゃならんのだわ。
やっぱり1ポイント1レコードかしら？

それとも「何月何日に100ポイント取得」「何月何日に30ポイント消費」みたいな、
ログ記録かしら。

教えてちょんまげ。
19 名前：NAME IS NULL mailto:sage [2010/05/07(金) 21:11:50 ID:???]: 直したのかよ
有給ないやつにも分かるように直したのかよ
20 名前：NAME IS NULL mailto:sage [2010/05/08(土) 06:31:21 ID:???]: >>16
有給は半年前倒しで全社員一斉に与えても
いいんだよ。でなければ、入社日から計算。
入社半年で、0.5年度。一年半で1.5年度。
年度は入社何年目かって事でしょ。西暦
じゃないよ。この年度単位でないと、
繰越計算しにくいと思う。だから、年度に
与えた日数と消化した日数持たせていい。

>>15
なんかいまいちその利点がイメージできない。消化日数を持たせた時点で、集計
してrowをその都度更新していくのは
当たり前だし。それに、本当にsumなんか
で繰越の計算できんの？
21 名前：13 mailto:sage [2010/05/10(月) 11:33:11 ID:???]: 実際に消化した実績日数だけで良いシステムなら、同一テーブルでもいいけど、
大抵は、事前に申請が必要だし、その申請こみで今現在の残日数を求める必要が
あったりする。つまり、大抵は（案２）みたいなテーブルが必要になるだろうってこと。
22 名前：NAME IS NULL mailto:sage [2010/05/17(月) 23:44:56 ID:???]: そういえば最近は時間単位で年休取得できる会社もあるよな。
23 名前：NAME IS NULL mailto:sage [2010/05/18(火) 00:21:58 ID:???]: 時間単位はややこしい。日単位なら
その日の勤怠区分で処理できるのに。
例えば、10時出勤でも遅刻でないとか、
しかし、そのその日の勤務時間は一時間
マイナスで、有給で一時間補充とか、考えるだけで鬱になる
24 名前：NAME IS NULL mailto:sage [2010/06/15(火) 00:30:24 ID:???]: 簡単相互リンク集みたいなのを作ってまして
初めてDBをまともに使うのですが、こんな設計で問題ないでしょうか?

仕組みとしては、
・ひとつのUserIDに複数のサイトを登録可能
・申請が承認されると表示される
・相手にはUserIDは秘匿。

UserTable
---------------------
UserID　|　Mail　　　　　　　　　| 　Password 　 | 自分のSiteIDs　　　　 |　承認待ち　　　　　　　　　　　　 | 申請中
---------------------
u2145　　| test@gmail.com 　| 　 1234　　　　　| s3265,s2664, 　　　　　 | s3526(相手) to s3265(自分), 　　| s3265(自分) to s4377(相手)

SiteTable
---------------------
SiteID | UserID | URL　　　　　　　　　| Title　　　　| ビットフラグ　　　　　　　　| ジャンル　　　　 | 紹介文　　　　　| リンクしているSiteIDs
---------------------
s3265 | u2145　| google.com/ | Google　　| 未認証,リンク切れ,etc　　 | 検索/リンク集 | 検索サイトです。 | s6325,s2355,s2362,s2355,

(未認証は、本人のサイトか未確認の意味。仮登録後、数時間未認証の場合テーブルから削除します。別のテーブル作ったほうがいいのかな)

リンク集生成時にURLとタイトルを取得する為に複数のSiteIDを問い合わせるので、心配なのですが
普段はHTMLファイルを生成して追加/削除するときにHTMLファイルを更新する感じにすれば問題ないでしょうか?
アドバイスよろしくお願いします。
25 名前：NAME IS NULL mailto:sage [2010/06/15(火) 01:58:11 ID:???]: >>24
ユーザー毎にテーブル作った方がいい
26 名前：NAME IS NULL mailto:sage [2010/06/15(火) 06:01:44 ID:???]: to に笑った
27 名前：NAME IS NULL mailto:sage [2010/06/15(火) 06:15:29 ID:???]: 「s3265,s2664」とかなってるのはカラムの中にカンマ区切りにするって意味？
そんなんDB使う意味ないぞ。テキストデータで持ってた方がマシなレベル。
それに静的データ（マスタ）と動的ステータスは完全に分けた方がいいがごっちゃになってる
それと未認証とリンク切れとか意味が全く違うものを一緒にしちゃいかん。

>>25
ユーザが増えたらcreate table発行か？ありえん。
28 名前：24 mailto:sage [2010/06/15(火) 06:42:19 ID:???]: レスありがとうこざいます。

>>27

カンマ区切りでした。。SQL側でひとつのカラムに複数の値を管理できるのでしょうか?
よければヒントの検索ワード教えてもらえませんかTT
(カラムにレヒードを追加できるのでしょうか!?)

ビットフラグでカラム減らそうとしてました。
素直にtrue/falseでそれぞれカラムあったほうがいいんでしょうか?

静的と動的はこの場合、頻繁に書き換わるSiteIDが動的?ですかね
UserTableの申請中などの情報は新しいテーブルに作ってみます。
29 名前：NAME IS NULL mailto:sage [2010/06/15(火) 07:01:33 ID:???]: ＞カラムに複数の値を管理
配列を入れられるDBもあるけど検索に使いづらくなるのでまずやらない。
そういう場合、RDBは複数レコードで管理する。もちろん行数は多くなるが管理や検索速度のバランスだからしゃーない。

んで、テーブルだが、ちょっと要件いまいちわかってなくて考察適当だがこんな感じだと思うぞ。
UserMasterTable (UserID(PK)|Mail|Password)
SiteMasterTable (SiteID(PK)|サイトのUserID|URL|ジャンル|紹介文|リンク切れフラグ|未認証フラグ)
SiteLinkStatusTable (リンク元SiteID(PK)|リンク先SiteID(PK)|ステータス(未承認/承認済/削除)|更新日時)

SiteLinkStatusTableは申請時１レコード、承認されて相互リンクになると２レコードになる。
未認証→認証を行うのは管理者でいいの？
30 名前：NAME IS NULL mailto:sage [2010/06/15(火) 07:19:50 ID:???]: >>29
すごく具体的ありがとうこざいます> <

なるほど、こんなテーブルになるのですか!
素人考えで一つのテーブルに纏めすぎてたんですね ; ;

認証は管理者ですね。リンク切れは定期的に確認する感じです。

ちょっと私には複雑すぎてSQL質疑応答スレで聞くことになると思いますが
とりあえず寝てから作成してみます。
31 名前：NAME IS NULL mailto:sage [2010/06/15(火) 16:32:38 ID:???]: 未認証とリンク切れは一緒でいいんじゃまいか
認証されてなければリンク切れとは判定しないだろうし
0 = 正常 / 1 = 未認証 / 2 = リンク切れ
とでもすれば
32 名前：NAME IS NULL mailto:sage [2010/06/15(火) 17:42:05 ID:???]: まあ、なんにせよ要件次第ではあるが

>>29
>仮登録後、数時間未認証の場合テーブルから削除します
なので、サイトマスターに最低限、申請（仮登録）日時いるだろうな
そうなると本登録日とか、ほかにも項目ほしくなるだろうけど

>>31
・未認証で承認しようとしたらリンクが切れてました
・承認してたんだけど、ある日リンクが切れました
の二つを区別して記録したいなら分けておかないとだめじゃね
もしくは別途サイト登録履歴みたいなテーブルもたせるか
33 名前：24 mailto:sage [2010/06/15(火) 18:22:47 ID:???]: 皆様ありがとうこざいます

作ろうとしてるのは、ユーザーのサイトにphpファイル(名前と設置場所固定)を設置させて被リンク効果を出す感じなのですが
phpファイル自体は、
$SiteID = 235455;
$fp = fopen("ttp://www.mydomain.com/site/$SiteID.html", "rb") or die ("Cannot open");
fpassthru($fp);
こんな感じでURLを取得して表示してるだけです。

後出しなのですが
未認証は、phpファイルが設置されていない状態で
リンク切れは、トップページからそのphpファイルにリンクされてない状態です。
相互リンク中に未認証/リンク切れになった場合は、一定時間後にSiteLinkStatusTableからサイト事消す感じになります。

そして後から気づいたのですが、リンク申請にメッセージを添えられる予定だったので
新たにMessageBoxTableを作ってみました。(メッセージボックスはユーザーが自由に消去できる予定)

UserMasterTable (UserID(PK)|Mail|Password|メールを受け取るか)
SiteMasterTable (SiteID(PK)|サイトのUserID|URL|タイトル|紹介文|ジャンル|ページランク|バックリンク|ステータス(未認証/リンク切れ/正常)|ステータスが変わった日時)
SiteLinkStatusTable (リンク元SiteID(PK)|リンク先SiteID(PK)|更新日時)
MessageBoxTable ( ユニークID(PK) | 差出人SiteID | 宛先SiteID | タイトル | 本文 | フラグ(リンク申請/リンク不成立/削除報告) | 日時 )

UserIDとSiteIDは登録時間のUNIXタイムスタンプを使おうかと思ってます。
34 名前：NAME IS NULL mailto:sage [2010/06/15(火) 19:08:29 ID:???]: UNIXタイムスタンプはダメだ
DATETIME型でカラム作った方がいいぞ
35 名前：NAME IS NULL [2010/06/15(火) 20:37:55 ID:NSd5kCf1]: 在庫調査のDBを作ろうとしてるのですが、
差分データのようにしないとデータ多すぎて一ヶ月もしないうちに大変な事になってしまいそうです。
エリア、店名、商品名、価格、個数、調査時間
最低限保持しないといけないのが上記項目で
同じ店でも同じ商品名でも陳列が別なら別登録になります。（ヤフオクで同じ商品が同じ価格でずらっと並んでるような）
調査1回につき、20～30エリア、1～100店、商品1～100点、個数1～100程度になるので単純にDBに登録すると1回で最大時30万行になってしまいます。
これを3時間ごとに調査となると、1ヶ月で数千万行になってしまって現実的ではありません。
なので調査ごとの変化は1割にも満たないので差分の登録の仕方や利用の仕方を勉強したいのですが、
そのような設計例の載ってる本やサイトをご存知ないでしょうか？
36 名前：NAME IS NULL mailto:sage [2010/06/15(火) 21:05:10 ID:???]: 差分ってか
ようは在庫変動のトランザクションを持ってりゃいいだけの
話のように思うが
37 名前：NAME IS NULL [2010/06/15(火) 21:52:45 ID:NSd5kCf1]: すいませんもう少し詳しく教えていただけませんか？
単に今の在庫がわかればいいってわけではなくて、
調査日のその時間にどこにどんな値段で在庫がいくらかあったか、店自体開いてたか開いてなかったかなどの
そのままの情報を保持したいので、
在庫変動したら値を変えるだけってわけではないのですが、そういう意味でもしおっしゃられていたのならすみません。
38 名前：NAME IS NULL mailto:sage [2010/06/15(火) 22:16:17 ID:???]: もし本当にそのままの情報を保持する必要があるなら
30万件だろうがそのまま持っとくほうがいいだろう
ただし、それを保存している間に在庫が動く可能性があるから
その瞬間の在庫という一貫性は保てないぞ

ただし、たとえば保存期間を三日とかにしておく等の制限をつける

三時間おきのデータを数年も保持しとかないといけないとかいうなら
要件を見直すべきかと
39 名前：NAME IS NULL mailto:sage [2010/06/15(火) 22:32:03 ID:???]: 取ったデータで何をするかじゃないかな。
例えばWeb画面でセミリアルタイムで変動をグラフで見せたい（計算させたい）のだったら１クリック５時間のクソアプリになるが、
月に１回バッチで在庫変動情報の帳票を作りたいだけなら全部突っ込んで１億レコードになっても何ら問題ない。
40 名前：NAME IS NULL mailto:sage [2010/06/15(火) 22:35:20 ID:???]: >>33
てか「（申請に添える）メッセージ」が「（サイト間の）リンク申請情報」を持ってるっておかしくなってるじゃん。
41 名前：24 mailto:sage [2010/06/15(火) 23:25:43 ID:???]: >>40
おかしいですか?
SiteLinkStatusTableにメッセージを置くのもおかしいので
MessageBoxTableにリンク申請情報を持たせてしまえば楽かなぁと
(メッセージ消したらリンク拒否みたいに)
42 名前：NAME IS NULL mailto:sage [2010/06/16(水) 01:34:09 ID:???]: UserID MEDIUMINT NOT NULL AUTO_INCREMENT
SiteID MEDIUMINT NOT NULL AUTO_INCREMENT
43 名前：NAME IS NULL [2010/06/16(水) 10:58:42 ID:1LUS1Pf+]: >>38
要件見直すことにします。
>>39
そのクソアプリに近い感じなのでリアルタイムなものと、日間月間変動情報なものとわけて考えて見ます。
44 名前：NAME IS NULL mailto:sage [2010/06/18(金) 18:45:41 ID:???]: これ見てよ↓
livedoor.blogimg.jp/tekepo/imgs/3/4/3414dfca.jpg
ばらまこうぜ！
45 名前：NAME IS NULL [2010/06/26(土) 08:48:25 ID:HzXxnfag]: 最近DBの勉強をし始めたのですが
通し番号　社員ID 社員名　製品ID　製品名　登録日時
のような列があった場合、通し番号　社員ID　製品ID　登録日時のテーブルと他2つに正規化できますが、
検索するときに必ず名を利用する場合（社員名、製品名、登録日時を取り出すのがメインの利用方法）、
サブクエリが増える分検索が遅くなると思うのですが
こういった場合でもテーブルって分けるべきなんでしょうか？
社員ID、製品IDを利用する事はほとんどありません。
正規化するとDB容量は節約できますが、利用時の負荷が増大するのでデメリットに感じます。
それともサブクエリ増えてたとしても、列が少なくDB容量が小さくなるようにした方が速くなるでしょうか？
46 名前：NAME IS NULL [2010/06/26(土) 09:23:29 ID:Y5TEab6Q]: やってみないと判らないと言われればそれまでだけど、

そんなに心配しないとイケないほど検索が遅くなる？負荷が増える？
47 名前：NAME IS NULL mailto:sage [2010/06/26(土) 09:52:42 ID:???]: 初心者なら型通りにやれ。
パフォーマンスを気にするなら、テーブル設計に手を入れるのはSQLチューニングで
改善の余地があるかどうか自分で判断できるようになってからだ。
48 名前：NAME IS NULL mailto:sage [2010/06/26(土) 10:06:21 ID:???]: >>45
パフォーマンスのための非正規化なんてのは最後の最後の最後の手段。
社員数が1000万～1億人もいるならそれもありかもなー、なレベル。
考えるのがムダとはいわないが、悩むのはムダ。
49 名前：NAME IS NULL [2010/06/26(土) 10:12:29 ID:HzXxnfag]: 最終手段なんですね・・・
まずは基本どおりの設計を覚えて経験していくことにします。ありがとうございました。
50 名前：NAME IS NULL mailto:sage [2010/07/02(金) 08:29:18 ID:???]: >>48
プロフを参照したところこの方、銀歯を作る仕事（ﾌﾟｯ）をなさっていたそうで（苦笑）
道理で、物作りの厳しさ、商売の難しさどれを取っても何一つ理解しておらず、突っ込み所満載なわけです
しかも過去形である所を見ると景気に関係なく黙ってても患者が来る、
病気や虫歯を直す商売でさえ勤まらなかったということでは（笑）
銀歯と金型では要求される精度も品質もまるで違います
質問者が何を作りたいのかが明らかにされていないため分かりませんが
趣味のようなもの、とおっしゃるなら趣味の掲示板で相談されたらいかがでしょうか
その分野の同好の士が良い方法をご存じかもしれませんから
もちろん、趣味の世界といえども技術は只で教えてもらえるほど甘い物じゃないという事をお忘れなく
51 名前：NAME IS NULL mailto:sage [2010/07/02(金) 12:07:01 ID:???]: どこの誤爆？妙に番号だけあってて笑える。
52 名前：NAME IS NULL [2010/07/03(土) 11:43:06 ID:magiIcce]: enumを使うか、マスタ化するかについて。
www.developer0000.jp/2008/11/08/3163/
blogs.wankuma.com/ognac/archive/2009/09/07/180928.aspx

全部をマスタ化すると無駄な感じがするのは確かだけど、
表示順や表示名、ロジック分岐フラグなどのパラメータをもてる。
マスタ化しておくことでアプリ内のswitch文を減らすことができる場合
も多々あるので、基本的にはマスタ化が好きなんだけどどう思う？
53 名前：NAME IS NULL [2010/07/08(木) 04:33:44 ID:mgDV/kGB]: 英語⇔日本語
みたいな対応表を作る時のようにどちらも主キーになるような場合は
どちらかを主キーにしてもう片方もインデックスする感じになるんでしょうか？
54 名前：NAME IS NULL mailto:sage [2010/07/08(木) 05:47:39 ID:???]: 別の連番のキーをつけた方がいいんじゃない？
55 名前：NAME IS NULL [2010/07/08(木) 16:50:07 ID:mgDV/kGB]: >>54
ＩＤ　日本語　英語で全部ユニークインデックスってことですか？
ＩＤは使う予定ないのですが将来に備えてということでしょうか。
56 名前：NAME IS NULL mailto:sage [2010/07/08(木) 17:37:37 ID:???]: 日本語と英語はユニークである必要無いんじゃない？
確実に1対1なの？
57 名前：NAME IS NULL [2010/07/08(木) 18:05:55 ID:mgDV/kGB]: >>56
確実に１対１です。かぶることはありません。
商品名の日本語⇔英語⇔中国語⇔ドイツ語とあるとして
日本語から英語、ドイツ語から中国語みたいに検索したいんです。
58 名前：NAME IS NULL mailto:sage [2010/07/08(木) 18:36:57 ID:???]: かぶらないって空欄も無いってことか
でも連番のidあったほうがいい気がするなあ
検索対象の項目はそれぞれインデックス作ればいいし
59 名前：NAME IS NULL mailto:sage [2010/07/08(木) 19:50:03 ID:???]: create table Locale(
LocaleID int,
Language char(3),
Message nvarchar(100)
)
select jpn.Message, eng.Message
from Locale as jpn
inner join Locale as eng
on jpn.LocaleID = eng.LocaleID
and eng.Language = 'eng'
and jpn.Language = 'jpn'
60 名前：NAME IS NULL mailto:sage [2010/07/08(木) 19:57:54 ID:???]: 商品名の対訳表なら、商品の主キー＋言語コードで主キーにするな、俺なら
61 名前：NAME IS NULL [2010/07/08(木) 20:48:47 ID:mgDV/kGB]: >>59 >>60
なるほど。これなら言語増えても列増やさなくて済むんですね。
こういうの自己結合って言うんですね。
自己結合って知らなかったので調べてみます。
いま全く知らない状態だと select Message, Language from Locale where LocaleID = 3
の方が速いんじゃないの？とか
行数増えると結合してるから遅くなるんじゃないの？とか思ってたりします。
62 名前：NAME IS NULL mailto:sage [2010/07/08(木) 21:24:44 ID:???]: 自己結合知らんような初心者がパフォーマンス考えるとかムダだから
63 名前：NAME IS NULL [2010/07/08(木) 23:34:03 ID:mgDV/kGB]: >>62
はい。ベテランの方々が提示したものが初心者の私が考えるより確実にいい設計だと思うので、
そのまま使おうと思います。
64 名前：NAME IS NULL mailto:sage [2010/07/09(金) 00:55:58 ID:???]: create table locale (
localeid int,
jpn nvarchar(100),
eng nvarchar(100),
doitu nvarchar(100),
china nvarchar(100)
)
65 名前：NAME IS NULL mailto:sage [2010/07/09(金) 01:07:19 ID:???]: ↑
メンテしやすい
66 名前：NAME IS NULL mailto:sage [2010/07/09(金) 01:15:13 ID:???]: それはないわ
67 名前：NAME IS NULL mailto:sage [2010/07/09(金) 01:27:27 ID:???]: 俺はその形大好きだがｗ
68 名前：NAME IS NULL mailto:sage [2010/07/09(金) 01:38:57 ID:???]: >>66
なんでないと思うのかな。必ず全部の言語のデータを一対一で作るという前提なら、ありだろ。
69 名前：NAME IS NULL mailto:sage [2010/07/09(金) 03:42:13 ID:???]: だってdoituだよ？
70 名前：NAME IS NULL mailto:sage [2010/07/09(金) 11:37:32 ID:???]: >>66
将来にわたって言語の追加変更削除がないことが担保されるならありだと思うが
71 名前：NAME IS NULL mailto:sage [2010/07/10(土) 00:23:34 ID:???]: add columnしとけ。
72 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2010/07/10(土) 10:24:04 ID:???]: >>64
要件変更時に悲惨なことになりそうな予感しかしない。
73 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2010/07/11(日) 10:24:03 ID:???]: chinaだけちゃんとしたフルネーム
74 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2010/07/11(日) 10:25:47 ID:???]: あ、フルネームって前に付くあれは無しで
75 名前：NAME IS NULL mailto:sage [2010/07/12(月) 22:21:49 ID:???]: ごく基本的なテーブル設計の話なんですが。

例えば「プレイヤーは複数の村を所持、村は複数の家を所持する」場合って

こういうのが↓依存リレーションで
playerテーブル：primary(player_id), player_name, ...
villageテーブル：primary(player_id, villege_no), village_name, ...
houseテーブル：primary(player_id, villege_no, house_no), house_name, ...

こういうのが↓非依存リレーションって言うんですよね？
playerテーブル：player_id(primary), player_name, ...
villageテーブル：village_id(primary), player_id(foreign), village_name, ...
houseテーブル：house_id(primary), village_id(foreign), house_name, ...

どちらを採択すべきか、っていうのは何を基準に考えたらいいんでしょう？
（もしくはどちらでもない別のがあるとか）
雑談程度に前者の設計について話してたら「２０年前の設計だろ」なんて言われてしまって
ちょっと気になっています。（その人は言い捨てて消えてしまったので聞けない）

またそれぞれのメリットデメリットなんかもあれば教えて頂きたい
（もしくは参考URLでも）。わりと調べたつもりなんですがイマイチいいのがHitせず。
76 名前：NAME IS NULL mailto:sage [2010/07/12(月) 22:27:59 ID:???]: 実際に両方で作ってみたらいいじゃん。
どっちもhouse_name village_nameを何度も書くはめになることに気づくよ。

それでもいいんだ！っていうなら1テーブルで作っちゃえばいいと思う。
「いちいち」player village houseを分ける必要ないでしょ。
77 名前：75 mailto:sage [2010/07/12(月) 22:29:29 ID:???]: あ、各テーブルの関係は1:Nです。情報後出しで申し訳ない。

あと設計のケースとして一個忘れてた、
player, player_villege, villege, villege_house, house　と作るケース。
なんて呼ぶのかわかりませんが。

一応自分の考えを書いておくと、
1:Nで、それこそ子の存在が親の存在に依存する場合は依存リレーション、そうでなきゃ非依存
ってだけの話かと考えているのですが。古いとかじゃなくて。

↑に追加で書いたのは、N:Nのときに使う、と。
（逆に言うと1:Nのときに使うメリットは特に無いと思う）
78 名前：NAME IS NULL mailto:sage [2010/07/12(月) 22:32:53 ID:???]: ごめん見落としていた。
>>75の後者って、一つの村は一つのユーザしか所有できないという制限になると思うけど
それはそういう仕様？
ならそれでもいい。

前者は正規化すべき対象がある(かつ、それが煩雑になりすぎない)のに
やらないというところが20年前なんじゃないかな。
79 名前：75 mailto:sage [2010/07/12(月) 22:45:14 ID:???]: >>78
そこは（遅れましたが）1:Nなので仕様です。

前者のほうが、「家IDから所有プレイヤーを逆引きするのが楽」だとか、
「親が存在しないのに子が存在しうる」といったデメリットがありますが
それでも後者にすべき？

今挙げた二つのデメリットは、最悪冗長なカラムを持つとか、
制約をしっかり設定すればいい話だけど…
パフォーマンスとしては前者の方がいいような気がするのですが。

…いや、それこそ両方組んで実データぶっこんでテストしなきゃわからないか。
結局どちらが是かは要件次第、なのかなぁ。
80 名前：NAME IS NULL mailto:sage [2010/07/12(月) 23:07:09 ID:???]: 1:Nなら前者にする必要がないんじゃ？
> villageテーブル：primary(player_id, villege_no), village_name, ...
に、unique(village_no)をつけて1:Nであるとアピールしてもいいけど。

「親が存在しないのに子が存在しうる」
これを避けたいなら外部キー制約でいけると思う。

パフォーマンスはこの情報だけだと環境によるとしかいえないかと。

あと、誰も所有していない村や家はどうなるの？
81 名前：75 mailto:sage [2010/07/12(月) 23:25:03 ID:???]: あれ、俺疲れてんのかな…

よく考えたら子があるのに親がないリスクは前者も後者も同じですよね。
とにかくこれは制約でどうにでもなると。

誰も所有してない村や家は存在してはいけないので削除…いや、
件数がかなり多い（数千万レベル）のでdelete_flag式にするから制約できないや。
そこはPGの責任でしっかり組むことにします。

やっぱり前者に拘る理由は「逆引きが楽」くらい？
indexによる検索性能…も正しくIndex作れば同じ？か？
だんだん「そもそも依存リレーションの存在価値って何」って考えになってきた。

ちなみに質問では親ー子ー孫の３層にしましたが実装は４層。
前者にするとキー長が長くなって検索にはむしろ不利なのか？
82 名前：NAME IS NULL mailto:sage [2010/07/12(月) 23:35:48 ID:???]: 後者は外部キー制約あるんだから、家があるなら村はあるはずだし、
村があるならプレイヤーはいるはずになっているよ。

キーが長くなるというか、インデックスが肥大化するんでないかね。
そのへん詳しくないけど。

依存リレーションという言葉も知らなくてなんだかごめん。
83 名前：NAME IS NULL mailto:sage [2010/07/12(月) 23:42:05 ID:???]: で、今依存、非依存について調べたわけですが、

前者は存在しないplayer_idをvillageに登録できるし、
villageがなくともplayerを登録できるので、互いに非依存

後者は>>82で書いたように、playerがいなければvillageに
登録できないが、villageがなくともplayerは登録できるため、
villageはplayerに依存し、playerはvillageに非依存である

ということなんじゃないのかなーと。
84 名前：NAME IS NULL mailto:sage [2010/07/13(火) 00:03:57 ID:???]: PG的には村や家に確実にユニークなIDが振られてる方が楽だと思うが。逆引きするにしても。
「前者のvillege_noやhouse_noも実はユニークなんです(ｷﾘｯ」なら糞設計と呼ばれても仕方ないと思うけど。
85 名前：NAME IS NULL mailto:sage [2010/07/13(火) 00:16:17 ID:???]: どう考えても後者の設計だな。前者のが古いかどうかは知らないが、親子関係が変更になった時に主キーに触らないといけないのが気持ち悪い。
86 名前：75 mailto:sage [2010/07/13(火) 00:47:25 ID:???]: うーむ…。よし、ここは経験と思って、後者で実装することにします。
すでに前者で組んでる最中の、取り返しが付かない段階のシステムがあるので、
違いを肌で感じることにします。

ありがとう御座いました。肌で感じたあとブログにでもまとめようと思います。
87 名前：NAME IS NULL mailto:sage [2010/07/13(火) 00:52:30 ID:???]: てかもっと新しい（？）というか安全なのは、「プレイヤー-村」関連テーブルと「村-家」関連テーブルを別途作ることじゃないかね。
88 名前：75 mailto:sage [2010/07/13(火) 00:58:41 ID:???]: >>87
それが>>77で追加したやつのことなんですけど、
N:Nならそうせざるを得ないとして、
1:Nでもそこまでします？

その形にすると、子要素１件の増減につき必ず２テーブル触らないといけないので
パフォーマンスが気になります。

1:Nなので、「プレイヤー村」関連テーブルと「村」テーブルの
件数って完全一致で、「なんのために２テーブルに別れてんだ？」って考えてしまうのですが。
89 名前：NAME IS NULL mailto:sage [2010/07/13(火) 01:16:13 ID:???]: その程度でパフォーマンスが気になるほど更新が頻繁なのか？
90 名前：75 mailto:sage [2010/07/13(火) 01:30:31 ID:???]: 更新はそれなりに頻繁、件数が億単位を想定。
パフォーマンスのために多少の開発効率を落とすのも辞さないレベル。
91 名前：NAME IS NULL mailto:sage [2010/07/13(火) 01:34:22 ID:???]: んな条件を後出しすんじゃねぇよｗｗｗ
億単位レコードのテーブルは非正規化されてる方が普通なくらいだろｗ
92 名前：75 mailto:sage [2010/07/13(火) 01:41:34 ID:???]: で、ですよね。すいません。

それを先に出すべきとか言うところに頭がピンと来ない人間が
億単位システムのDB設計をしているという…。
93 名前：NAME IS NULL mailto:sage [2010/07/13(火) 01:43:50 ID:???]: ていうかそれ何のDB？
94 名前：75 mailto:sage [2010/07/13(火) 01:53:46 ID:???]: MySQLです。

まぁ最初はよほど負荷が見えてるところ意外は基本的に正規形で考えて
後から発覚した負荷について非正規形にする感じで考えてる。
95 名前：NAME IS NULL mailto:sage [2010/07/13(火) 02:29:42 ID:???]: それがもしモバゲとかグリーとかブラゲならDB以外にも抑えておかないといけない点がいくつかあるんだけど
その辺は大丈夫なのかね。
96 名前：75 mailto:sage [2010/07/13(火) 02:37:20 ID:???]: そのへんは肯定も否定もしないでおくけど
memcache使うとか基幹システムAPIは極力叩かないとかは抑えてるつもり。
まぁスレ違いにもなって申し訳ないのであくまでDB設計の話を、と。
ご忠告感謝。
97 名前：NAME IS NULL mailto:sage [2010/07/13(火) 02:46:23 ID:???]: そっか。それなら、だいじょうぶかな。DBも分散を検討してね。
うまく行くことを願っているよ。
98 名前：75 mailto:sage [2010/07/13(火) 03:59:17 ID:???]: MASTER、SLAVEの分散もありました、忘れてました。
あとコネクションを極力短く、少なくとか。状況次第じゃいったん切るとか。

で、報告までに。
「複合キー」とか「サロゲートキー」とかでググりまくったら、
「古い」なんて言われたのもぼんやりと納得できてきました。

階層構造に複合キーを使うなんてのは２秒で否定されるレベル、
といった感じが伝わってきました。
（それでも「必ずしも」ではない、ケースバイケースなんだろうけど）

取り返しがつく今のうちに修正に入ることにします…。
99 名前：NAME IS NULL mailto:sage [2010/07/13(火) 10:25:55 ID:???]: 今どき複合キーはないわ。
オブジェクト指向とかORM(Object Relational Mapping)とか考えるとサロゲートキー一択っしょ。

あと、１：Nなら関連テーブルは不要だね。
100 名前：NAME IS NULL mailto:sage [2010/07/13(火) 11:55:11 ID:???]: 俺なら前者にはしない。
なぜなら、playerが所有しない村も（今は無くとも）存在するだろう（かもしれない）し、家も同様。
また、所有者が変更になるとき、pkeyの更新になるのはいただけない。
101 名前：NAME IS NULL mailto:sage [2010/07/13(火) 22:17:58 ID:???]: 複合キーとサロゲートキーって、
具体的にどう違うの？
102 名前：NAME IS NULL mailto:sage [2010/07/13(火) 23:08:29 ID:???]: サロゲートは完全なキーであるためだけのキー。
103 名前：NAME IS NULL mailto:sage [2010/07/14(水) 13:04:15 ID:???]: >>102
単独か複合かは関係ないんですね？
ユニークと同じ意味と思っていい？
104 名前：NAME IS NULL mailto:sage [2010/07/14(水) 13:13:29 ID:???]: >>103
何で調べないの？
Wikipediaでもある程度わかるのに。
ja.wikipedia.org/wiki/%E4%B8%BB%E3%82%AD%E3%83%BC
105 名前：NAME IS NULL mailto:sage [2010/07/14(水) 22:43:21 ID:???]: サロゲートキーは「本当はいらないはずだけど、どうしても作らなければいけない」
というイメージがあります。
ダミー列がprimary keyのような感じ。
106 名前：NAME IS NULL mailto:sage [2010/07/14(水) 22:52:25 ID:???]: 祇園精舎の鐘の声
諸行無常の響きあり

沙羅双樹の花の色
盛者必衰の理をあらわす

おごれる人も久しからず
ただ春の世の夢のごとし

たけき者も遂には滅びぬ
偏に風の前の塵に同じ

サロゲートキー、それは自然キーの否定。
107 名前：NAME IS NULL mailto:sage [2010/07/15(木) 09:22:23 ID:???]: >>105
あんたの感想はわかった。それで？
108 名前：NAME IS NULL mailto:sage [2010/07/15(木) 11:02:19 ID:???]: いやまぁ合ってるよ
業務要件上はいらないけど、システム要件上は必要なので
ダミー（ユニークネスを保証する以外に意味のない）列を追加するわけだから
109 名前：NAME IS NULL mailto:sage [2010/07/15(木) 11:14:09 ID:???]: まーた始まった
110 名前：NAME IS NULL mailto:sage [2010/07/15(木) 21:21:24 ID:???]: >>107
ごめんなさい。
111 名前：NAME IS NULL mailto:sage [2010/07/18(日) 09:49:29 ID:???]: >>109
ん？まーた始まったって？

私は初めて書き込みますが、サロゲートキーは一つのデータベースで必要な部分と不必要な部分があります
必要な部分では必ず適用します
不要な部分では使用しません
何故必要な部分で使用するかというと使用しなかった時に大変困ったという経験則に基づくものです
不要な部分というのはデータベースごとで違うでしょうが、使用しなくても大して困らなかったという経験則に基づくものです
つまり必要無いと思う人は使わなければ良いし必要だと思う人は使えば良いだけじゃないでしょうか
112 名前：NAME IS NULL mailto:sage [2010/07/18(日) 14:00:29 ID:???]: >>111
「必要なとき使う、不要なとき使わない、その基準は経験則」
そんな情報をネット上のフォーラムに残すことに何の意味がある？誰の参考になる？

どうせならその経験則を少しでも、ほんの一部でも噛み砕いて置いていってくれないか。
113 名前：NAME IS NULL mailto:sage [2010/07/18(日) 14:31:12 ID:???]: >>111ではないが、RDB的なサロゲートキーってのはその名のとおり長大な
複合キーなど取り回しに難がある場合に代理として用いるものだろ。どのくらいで
「難がある」かはケースバイケース。
ただし、>>108の言うような「ユニークネスを保証する以外に意味のない」キー
というのは本来のサロゲートキーとは違って、OODBのIDのようなもの。
こいつらはデータモデルがそもそも違うんで、ごっちゃに議論すると発散する。
114 名前：NAME IS NULL mailto:sage [2010/07/18(日) 15:17:40 ID:???]: 顧客が決める気持ち悪いコードに対して
それと１対１になるように一見意味のなさそうなIDを振りなおすのがサロゲートキー。
（あとから仕様変更によって、１対１じゃなくなる可能性があるが）

単にテーブル設計の都合上の複合キーに対してIDを振りなおすのは
ちょっとわけが違うということか。
115 名前：NAME IS NULL mailto:sage [2010/07/18(日) 15:58:36 ID:???]: いや、どっちかっつーとサロゲートキーというのは後者。
また、前者で1:1でなくなる仕様変更というのは、RDB的には「そんな仕様変更があったら
従属関係が変わってるからテーブル定義を変更せずに済むとは限らんだろ」となる。
これが有効なのは、OOあるいはER的に「オブジェクト/エンティティ境界はそれが持つ
属性やその関係よりも安定である」という前提でそのように設計した場合の話。
116 名前：NAME IS NULL mailto:sage [2010/07/18(日) 17:20:37 ID:???]: サロゲートキーが必要／不必要で論じると、
複合キーを認めないという前提でないかぎり、すべて不必要だと思うが

ただ単に取り扱いが楽かどうかだけの問題以外に必要性があるなら教えてほしい
117 名前：NAME IS NULL mailto:sage [2010/08/07(土) 07:48:37 ID:???]: ニコニコ動画とかのタグ付けって
ひとつのカラムに空白区切りとかで押しこむのが普通なんでしょうか?
118 名前：NAME IS NULL mailto:sage [2010/08/07(土) 09:52:59 ID:???]: >>117
動画テーブルと、タグテーブルの間でN:Mの関連を構築すればいいんじゃないの？
119 名前：NAME IS NULL mailto:sage [2010/08/07(土) 16:40:59 ID:???]: >>118
ありがとうございます
勉強してきます > <
120 名前：NAME IS NULL mailto:sage [2010/08/07(土) 20:29:49 ID:???]: q.hatena.ne.jp/1152280193
仕事でやってるとこんな風に考えられるのか・・・
アマだとまったく思いつかない; ;
121 名前：NAME IS NULL mailto:sage [2010/08/07(土) 22:56:44 ID:???]: 実際の仕事ではpopular_tagsとtagsテーブルは合算されるよ
なるべくテーブル数は減らして結合処理のボトルネックを減らした方が後々いいからね
122 名前：NAME IS NULL mailto:sage [2010/08/08(日) 16:59:01 ID:???]: 減らす為にpopular_tagsを作ってるんじゃ。。
123 名前：NAME IS NULL mailto:sage [2010/08/09(月) 00:27:37 ID:???]: え？
124 名前：NAME IS NULL mailto:sage [2010/08/09(月) 12:04:21 ID:???]: 数学
125 名前：NAME IS NULL mailto:sage [2010/08/09(月) 22:23:38 ID:???]: >>121
>なるべくテーブル数は減らして結合処理のボトルネックを減らした方が後々いいからね
やめてくれ
126 名前：NAME IS NULL mailto:sage [2010/08/09(月) 22:36:39 ID:???]: 初心者は結合すると遅くなると本気で信じてる奴いるからな。
127 名前：NAME IS NULL mailto:sage [2010/08/10(火) 02:41:55 ID:???]: ド素人が第三正規化にこだわるのをよく見るな
128 名前：NAME IS NULL mailto:sage [2010/08/10(火) 11:17:30 ID:???]: > 結合処理のボトルネック
SQL書けない馬鹿の言い訳
129 名前：NAME IS NULL mailto:sage [2010/08/10(火) 12:42:16 ID:???]: あるあるｗ
130 名前：NAME IS NULL mailto:sage [2010/08/10(火) 13:30:12 ID:???]: >>120
相変わらずhatenaはレベルの低い回答が多いな
131 名前：NAME IS NULL mailto:sage [2010/08/10(火) 14:07:34 ID:???]: SQL書けない人にJOINさせると開発工数のボトルネックになる(笑)
132 名前：NAME IS NULL mailto:sage [2010/08/10(火) 15:46:06 ID:???]: >>120をよく読まずに>>121が反応してるので話がかみ合ってないだけじゃね？
popular_tagsはタグの種類じゃなくて集計用のテーブル。
目的は精度や時系列の一貫性を求められないが頻繁に参照されるデータの取り扱いのためであって、
正規化やそれを崩した場合のＪＯＩＮのパフォーマンス云々は関係ない。
133 名前：NAME IS NULL mailto:sage [2010/08/10(火) 18:31:51 ID:???]: 集計のためのカウントアップの前にjoinする必要がある
結果を表示する時もjoinする必要がある
結論：無駄

おｋ？
134 名前：NAME IS NULL mailto:sage [2010/08/10(火) 19:00:09 ID:???]: >>133
だからさ、どういう仕組みのシステムを想定してるかで変わってくるのだから、
その辺を明確にしないと話がかみ合わない。
それぞれ違うものを想定して結論だけをあーだこーだ言っても仕方ないだろ。
135 名前：NAME IS NULL mailto:sage [2010/08/10(火) 19:22:10 ID:???]: あのさ、普通に考えてみなよ
カウントアップの時はユーザがタグを入力した時
そのタグ名を判定しつつカウントアップしないといけない
つまりjoinまたは過剰なクエリ発行を伴う

結果表示も同じ
タグ名無しで表示される事何てまずない

システムによっても糞もないだろ
id指定でカウントアップする事例ってあるのか？
id表示させて満足させる集計表示ってあるのか？
まともなシステムならねぇだろ

たのむから億単位のレコードを扱ってから物申してくれ
こんな設計をする奴は経験が浅い
136 名前：NAME IS NULL mailto:sage [2010/08/10(火) 19:28:19 ID:???]: >>135
じゃ一つシナリオを挙げよう。
popular_tagsテーブルはいらない。tagsをgroup byすれば済む。
ただこれを人気タグの一覧を表示するごとにクエリするとコストが高い。
それで１０分おき位にgroup byのクエリを行い、popular_tagsテーブルにキャッシュしておく。
場合によってはRDBではなくアプリケーションサーバー内のメモリにキャッシュしてても良い。
137 名前：NAME IS NULL mailto:sage [2010/08/10(火) 22:25:31 ID:???]: >>121
>実際の仕事ではpopular_tagsとtagsテーブルは合算されるよ
合算って何？
138 名前：NAME IS NULL mailto:sage [2010/08/11(水) 00:04:59 ID:???]: >>135
ずれてない？
139 名前：NAME IS NULL mailto:sage [2010/08/12(木) 16:56:53 ID:???]: 所与の条件は、タグは自由入力形式で１つのコンテンツに対して複数付けられるってことだよね。
人気タグに関しては検索数（参照数）が多いのか、付けた数が多いのか明確にされていない。
また集計期間を設けるかどうかやその期間についても明らかにされていない。
検索数の場合はカウントアップが必要になるかもしれないが、
付加数ならば>>136の方法が妥当じゃないかな。
>>135の想定しているものがいまいち分からないが、
それぞれのテーブルが１：１：１でとか考えていて、
タグ名と参照数をわざわざ３テーブルに分けるのは無駄だとか考えているのだろうか。
>>136のはコンテンツとタグが１：ｎ、人気タグテーブルが独立して存在という考え方だろう。
140 名前：NAME IS NULL [2010/10/14(木) 02:48:47 ID:etNKxQCa]: >>127
第三正規化が正確に出来てから言え！！
まずこだわることが大事だぞ。
141 名前：NAME IS NULL mailto:sage [2010/10/14(木) 10:25:29 ID:???]: >>127のはできないやつのいいわけだからｗ
142 名前：NAME IS NULL mailto:sage [2010/10/14(木) 10:45:55 ID:???]: 121みたいな何も知らない馬鹿はおいておいて、人気タグのようなケースはデータ構造というよりアプリ依存の話だから、ごっちゃに話すと混乱するでしょ。

データ構造の話でいえば、ちゃんと正規化して最適化されたデータ構造が保持できていれば、人気タグのような集計系によるJOINも問題なし。
いまどきの商用（とほぼ同等品も含む）RDBMSならストアドにすれば高コストと言ってもたかが知れてる。（タグが毎秒何千とかで追加変更されているとかじゃない限りｗ）
当然、適正に正規化できているデータ構造に冗長なテーブルは存在しない（まぁ、それは理想だがｗ）。

アプリの話で言えば、WEBアプリのネックはページ生成と通信部分だから、サーバサイドのデータ処理よりこちらのほうが普通はデメリットになる。
なので、人気タグやそのとび先をあらかじめ一定時間毎に静的ページ（厳密には静的ページではなくてもそれと同等の負荷のものも含む）を作成するような場合もある。
検索でインデックスと展開先をあらかじめ作っておくパターン。このような場合は、そのページ生成のためのデータをどこかに当然吐き出すわけだが、
それがテーブルなのかHTMLのようなファイルなのか、とにかく出力先の違いだけ。

hatenaの回答者はそれを一緒くたに回答しているので話がややこしくなってる。
143 名前：NAME IS NULL mailto:sage [2010/10/14(木) 14:33:13 ID:???]: ﾅﾝｶﾜﾛﾀｗ
どんだけ一人の書き込みを気にしてんだよｗ
144 名前：NAME IS NULL mailto:sage [2010/10/14(木) 17:27:43 ID:???]: 一人の書き込みに食いつかざるを得ないほど、ネタがないｗ
145 名前：NAME IS NULL mailto:sage [2010/10/14(木) 20:57:41 ID:???]: アクセスコストがストアドで解決できるとかw
146 名前：NAME IS NULL mailto:sage [2010/10/15(金) 00:14:44 ID:???]: >>121は、元コボラーだな。

元コボラーが設計したテーブル設計って酷いのが多いんだわ。
147 名前：NAME IS NULL mailto:sage [2010/10/15(金) 07:39:41 ID:???]: >>145
アクセスコストの話は下段だろjk
148 名前：NAME IS NULL mailto:sage [2010/10/15(金) 09:10:34 ID:???]: 121の人気に嫉妬ｗ
たぶん合ってるから人気なんだろうなｗ
149 名前：NAME IS NULL mailto:sage [2010/10/15(金) 10:19:56 ID:???]: 2ヶ月も前の話題を引っ張るなよ。それにしても>>121大人気だな。
150 名前：NAME IS NULL mailto:sage [2010/10/15(金) 11:14:08 ID:???]: いまどき一般的な規模のRDBでテーブルの結合がボトルネックになる、なんて書いたらそりゃ人気も出るw
151 名前：NAME IS NULL mailto:sage [2010/10/15(金) 21:55:23 ID:???]: >>147
下段って？>>142本人なら解説ｷﾎﾞﾝ
152 名前：NAME IS NULL mailto:sage [2010/10/25(月) 20:01:40 ID:???]: >>146
元コボラーには有償研修のSQL入門程度は行かせた方が良い。
わずかな投資で使いものにならなかった人材が使えるように
なったらもうけもの。

汎用機ではこうだったからだ、、、
と仕事を妨害することも少なくなれば一石二鳥。
153 名前：NAME IS NULL [2010/10/25(月) 21:56:18 ID:G/Enqt3S]: COBOLにOCCURS項目があるといのがCOBOLとSQLの相性が悪いところなんでしょうかね… w

それだけではないでしょうけど
154 名前：NAME IS NULL mailto:sage [2010/10/25(月) 23:29:57 ID:???]: SQLというより、テーブル定義の問題だがな
COBOLのようなISAM編成に向いたテーブル定義と
RDBを前提としたテーブル定義は違うってことだ
155 名前：NAME IS NULL [2010/10/26(火) 22:28:35 ID:BB4To3r1]: ある製品を作る時に使用する部品をDB化したい。

[条件]
1つの製品を作る際に使用する部品の種類は、1個～20個以内。
データの出力時には、固定列数なフォーマットにする。
--

こういう場合も正規化ってする？
クロス集計でしか利用されないデータを正規化するのってすごい非効率な気がするんだがどうなんだろう。

[非正規化]
作成No,製品名,部品1個数1,単価1,部品2,個数2,単価2～部品19,個数19,単価19,部品20,個数20,単価20,合計,作成日,コメント

[正規化]
作成No,製品名,合計,作成日,コメント
部品No,作成No,部品,個数,単価
156 名前：NAME IS NULL mailto:sage [2010/10/27(水) 00:55:32 ID:???]: >>155
将来、部品点数が絶対に増えないといえるのなら、
非正規化でもいいかもね。

将来、部品点数が増えたり、階層化する可能性があるなら、
正規化しといたほうが、後々潰しが効くと思う。
157 名前：155 mailto:sage [2010/10/27(水) 11:38:52 ID:???]: >>156
どうもです。

階層化は考慮外ですが、部品点数が増える事に対しても非正規化の方が
工数的(作成時、実行時ともに)に有利だと思うんだけどなー。

テーブルを修正しなくても良いという点では正規化が優れているが、
それほど加点でもなく、マイナス点の方が多く思える。

Gridに表示させたり、CSVなどで出力したりで毎回毎回別途に集計しなければならないのは面倒くさい。
制限チェックも増えるし、取りだしが必ず2度以上になってしまうからレスポンス的にもだいぶ不利だし…。
皆さんどうしているんだろうか。そういう欠点よりも将来の拡張性の為に正規化をしているのかな。

悩む…。
非正規化はテーブルの見た目がださい所も気になる。
158 名前：NAME IS NULL mailto:sage [2010/10/27(水) 12:22:13 ID:???]: >>155
非正規化の場合、部品のステータスに修正入ったら一括変更でもするつもりか？
データ構造が変わらない（商品を構成する部品の点数や構成が将来的に変わらない）としても、表示するフロントエンド（アプリ）は色々変わったり、
他の場所で使われることがあるから、素直に正規化しておけ。
非正規化されたデータをもとに他の人間がフロントエンド作るのは非常に面倒くさい。

その程度のクロス集計のコストが高くなるというのは、そもそもの設計か実行時のSQLに問題があるだけ。
159 名前：NAME IS NULL mailto:sage [2010/10/27(水) 19:46:30 ID:???]: >>157
＞非正規化はテーブルの見た目がださい所も気になる。
開発者の感覚としては、これにつきる。
その程度のテーブルなら、どんな構成
でも実行速度は変わらんだろ。

捨てコードでもいいから突貫で、と
いうのでなければ、個人的に非正規は
ありえない。
160 名前：158 mailto:sage [2010/10/27(水) 19:54:11 ID:???]: >>157
非難だけしてもなんなので、現実的な方法を。
仮に出力の（クロス集計の）コストが高いというのが問題であるならば、部品構成の変更などが頻繁でない限りは（今回のケースはそうだと思うが）、
部品の変更や修正、追加をトリガーに出力用のデータをテーブルなりファイルなりに吐き出しておけばよい。
最終形でなくても、計算途中のデータを出力しておけば実行速度の問題はなくなるはず。

大手のデジカメの階層化されたPDMで実際にやってる。
161 名前：NAME IS NULL mailto:sage [2010/10/27(水) 23:29:07 ID:???]: なんでこうJOIN一発するだけでレスポンスが"だいぶ"悪くなると思う奴がDB設計とかやってるんだろう。
162 名前：NAME IS NULL mailto:sage [2010/10/28(木) 00:44:53 ID:???]: つかこれ、かならず部品１～２０までを固定で取り扱うというなら
横に１～２０まで並べても非正規化だとはいえない気がする．．．．

が、俺なら絶対実テーブルを部品１～２０まで繰り返したりしない
部品点数が増えたときに非正規化が工数的に有利だと思う考えが理解できん
毎回別途に集計するのがめんどくさいというのも、いまいち理解できん
ビュー使えよ。最近のＤＢＭＳなら>160の言うようなワークテーブル的に
使える実体付きビューを使えるものもあるんだぜ
163 名前：NAME IS NULL [2010/10/28(木) 12:46:48 ID:2nX/Ozle]: テーブル名を日本語で作るのは駄目かな？
164 名前：NAME IS NULL mailto:sage [2010/10/28(木) 20:12:37 ID:???]: 出来るけどやめておけと言われるはず。
日本語が入力出来ない状態でメンテナンスするってなった場合、手段が減る。

特別な理由がない限りASCII文字で作って老いた方が無難。
165 名前：NAME IS NULL mailto:sage [2010/10/28(木) 20:23:31 ID:???]: どっかで、日本語を推奨してる人を見たことがある。
今はO/Rマッパーやらツールやらがいろいろあり、
テーブル名や項目名を直接タイプすることが少なくなったから、
（日本人しか使わないなら）直感的な日本語のほうがいいとか言ってた。

わりと賛同できるのだが、やっぱ怖いもんは怖いよなぁ。
こんなことで変なリスク抱えたくないわ。
166 名前：NAME IS NULL mailto:sage [2010/10/28(木) 21:34:07 ID:???]: >>165
>O/Rマッパーやらツールやらがいろいろあり

色々あるから、むしろ TBL0002345 みたいなテーブル名でも最終的にはさほど困らないと思うんだが。
テーブル名や項目名が直感的に把握できる必要があるものに関してはVIEWなりストアドで作ればいい。
167 名前：NAME IS NULL mailto:sage [2010/10/28(木) 23:42:40 ID:???]: >>165
全く賛同できないんだが。
ていうか、何を言ってるんだ？って感じだ。
そんな奴が近くに居たら、ぶちのめしてやりたい。
168 名前：NAME IS NULL mailto:sage [2010/10/29(金) 07:29:40 ID:???]: >>167
論理的な意見が聞きたい
169 名前：NAME IS NULL mailto:sage [2010/10/29(金) 10:18:23 ID:???]: >>168
>>164の
＞日本語が入力出来ない状態でメンテナンスするってなった場合、手段が減る。
これとか
charset問題とかだろ
170 名前：167 mailto:sage [2010/10/29(金) 22:55:31 ID:???]: >>168
OSやらDBやらアプリやらで、文字コードを統一しないと怖くて使えない。
プログラムを組んでいる最中に、いちいち全角入力モードに変える必要がある。
　　（絶対に、全角スペースをコードに記述してしまってコンパイルエラーとなる頻度が多くなる）
半角と全角の区別がつき難い。
　　（例えば、"1"と"１"はパッと見解らない。）

あと、O/Rマッパーやらツールやらを使うことが出来ない場合のことを考えろ。
171 名前：NAME IS NULL mailto:sage [2010/10/30(土) 05:46:07 ID:???]: コンパイルエラーなんて別に構わないだろ。その場で分かるんだから。
怖いのは潜在的なエラーとしてバグを引き起こすこと。しかも数年後とか、改修時に。
後は抽出条件が実は間違っていた、とか。
172 名前：NAME IS NULL [2010/11/08(月) 11:58:49 ID:wNBEtH7N]: 簡単な人材派遣システムを作りたいのですが、空き人材の抽出方法に悩んでいます。

タスクの開始日と終了日、跳び石や繰り返し設定等を組み合わせて検索するには
どうすればいいのか複雑でまとまりません。
単純にタスクを実稼働日の配列として展開し、日付をフラグで
埋めていくほうが明快で良いのかもしれませんが、その場合のデメリットは
あるのでしょうか？

また各人材が稼働日空き日を保持するのと、先に競合タスクを判定して
従事者を除外するのはどちらが一般的なやり方でしょうか？
173 名前：NAME IS NULL mailto:sage [2010/11/09(火) 00:22:16 ID:???]: 業務で人材派遣システムを覗いたことがある。

人のアサインはアサイン管理テーブルみたいなので運用。
基本はDELETE→INSERT、少しでも期間が被った場合はエラー、
前の予約状況をキャンセルしない限り新しいアサインは不可。
174 名前：NAME IS NULL mailto:sage [2010/11/09(火) 10:36:25 ID:???]: 管理テーブルでDeleteは乱暴なので、更新日時が最新なものをピックアップでよい。案件確定後なり一定期間後にログとして出力してクリーニング。
175 名前：NAME IS NULL [2010/11/10(水) 11:03:03 ID:zzwY8gI+]: >期間が被った場合はエラーについては
どう判定するのでしょうか？

新規側が連続日ならば、
新規期間内に既存開始／終了日のいずれかが無いこと、または
（新規開始前に既存開始があり、かつ新規終了後に既存終了後がある）が無いことで、
競合が無い人物の抽出（または競合するタスクに関わる人物の除外）はできますが、
毎週第二火曜日や、平日土日のみなどの隔日予定が混在するとややこしくなります。

日付に従業フラグを立てる場合は新規開始～終了までの日数分ループを回して
一日ごとに競合判定することが考えられますが、せっかく規則性あるのに
200日なら200個データを持つのは実用的なのかスマートでないのか…（柔軟にはなりますが）。
176 名前：NAME IS NULL mailto:sage [2010/11/10(水) 17:42:59 ID:???]: bitフラグ判定で言いじゃん
db問い合わせも出来るし何が不満なんだ？
177 名前：NAME IS NULL mailto:sage [2010/11/11(木) 10:54:29 ID:???]: 給与計算ソフトで「社会保険料等控除後の額」とか
日本語の述語を使いまくった身としては日本語名を支持したい。

文字コードはUnix系では怖いけど.NETならまず心配ないし。
178 名前：NAME IS NULL mailto:sage [2010/11/11(木) 12:07:30 ID:???]: .NET言語の変数名なら問題おこさないけど
Oracleの列名で日本語はいろいろ問題あるからなぁ
179 名前：NAME IS NULL mailto:sage [2010/11/11(木) 20:08:59 ID:???]: >>155
>[正規化]
>作成No,製品名,合計,作成日,コメント
>部品No,作成No,部品,個数,単価
遅レスだが

[正規化]
T製品：作成No,製品名,合計,作成日,コメント
T使用部品：作成No,部品No,個数
T部品：部品No,部品名,単価

実はこう？
面倒臭いな
180 名前：NAME IS NULL mailto:sage [2010/11/11(木) 23:01:04 ID:???]: .NETもLINQが使えないVS2005あたりで開発すると、正規化は諸刃の剣
181 名前：NAME IS NULL mailto:sage [2010/11/13(土) 22:34:02 ID:???]: >>178
> Oracleの列名で日本語はいろいろ問題あるからなぁ

なんか定期的にこういうやつ出てくるけど、具体的な「問題」とやらは
書かないんだな (w
182 名前：NAME IS NULL mailto:sage [2010/11/14(日) 01:25:17 ID:???]: 最初に入った会社のDB設計は、列名日本語でやってたな。
優秀な人はいたけどガラパゴス状態な感じで、
今になって真似しようとは思わないけど、それなりにちゃんと動いてたよ。
Windowsオンリーの環境だったのが良かったのかもしれんけど
183 名前：NAME IS NULL mailto:sage [2010/11/14(日) 10:30:25 ID:???]: だから、クローズドの環境なら日本語だろうがドイツ語だろうがハングルだろうがサンスクリットだろうが問題ないんだってばさ。
問題がおきれば随時つぶせばいいだけだし。

環境が頻繁に変わったり、他との連携で様々なドライバ使う可能性があったり、フロントエンドがガンガン増産されるような環境なら、
動作保障内でやるのが定石。
184 名前：NAME IS NULL mailto:sage [2010/11/14(日) 13:34:39 ID:???]: それ Oracle の問題じゃねーだろ。

そもそも動作保証云々以前に「環境が頻繁に変わったり、他との連携で
様々なドライバ使う可能性があったり、フロントエンドがガンガン増産
されるような環境なら」日本語なんか使う奴は馬鹿だろ。
185 名前：NAME IS NULL mailto:sage [2010/11/14(日) 23:41:47 ID:???]: >>181
文字コードの問題があるだろ。
日本語にしてしまうことで、文字コードがEUCなのかUTF8なのかSJISなのかを気にする必要が出てくるんだよ。

Windowsならまだしも、UNIX上からSQL文を叩くのに日本語入力することなんてありえねぇわ。
186 名前：NAME IS NULL mailto:sage [2010/11/15(月) 00:27:52 ID:???]: そんなん今時utfやん。
大体おまえんとこは実機で直接SQLたたいてんの？w
187 名前：NAME IS NULL mailto:sage [2010/11/15(月) 08:42:27 ID:???]: >>185
何年前の話をしてるんだ？
188 名前：NAME IS NULL mailto:turi [2010/11/16(火) 02:10:00 ID:???]: わかるわかる。ASCIIのDDLもってけばどんな環境の上でも構築できるよねｗｗｗ
189 名前：NAME IS NULL mailto:sage [2010/11/16(火) 10:57:26 ID:???]: 試さずに聞くが、NLS_LANG=Japanese_Japan.UTF8でDB作れば
「№」とかを列名に含めても問題起こさないのか？
場合によって""で括る必要があったりなかったりで面倒なんだが・・・
190 名前：NAME IS NULL mailto:sage [2010/11/16(火) 19:09:37 ID:???]: 何か問題を起こしそうな文字コードなの？
191 名前：NAME IS NULL mailto:sage [2010/11/16(火) 20:42:16 ID:???]: >>189
問題ない。

と言われれば信じるのか？ｗ
192 名前：NAME IS NULL mailto:sage [2010/11/16(火) 21:32:01 ID:???]: >>191
それ、頭悪いレスの筆頭候補だと思ってる。
193 名前：NAME IS NULL mailto:sage [2010/11/17(水) 01:07:34 ID:???]: >>186
OSはUTF8で、DBはSJISの環境が多いだろが。
勿論、実機でSQL文を叩くことが多いね。
194 名前：NAME IS NULL [2010/11/20(土) 14:12:23 ID:sSrpbL1f]: DBがSJIS
195 名前：NAME IS NULL mailto:sage [2010/11/20(土) 14:47:12 ID:???]: OSがUTF8でわざわざDBをSJISにする理由がないだろｗ
一昔前はOSがEUCでDBがSJISなら結構あったと思うが。
196 名前：NAME IS NULL [2010/11/21(日) 22:27:34 ID:4MhMQRH6]: 得意先別の締日を登録する場合，例えばデータ型をIntとした場合，
月末締めはどのように表現するのがいいのでしょうか？
よく，月末は99として登録するなどのテクニックがありますが，
どのような方法がいいのでしょうか。
197 名前：NAME IS NULL mailto:sage [2010/11/22(月) 20:47:59 ID:???]: ３１でいいと思うんだが
198 名前：NAME IS NULL mailto:sage [2010/11/22(月) 21:18:08 ID:???]: 31だと末尾を指定したかったのか31日を指定したかったのかが読み取れない
199 名前：NAME IS NULL mailto:sage [2010/11/22(月) 21:26:58 ID:???]: 31で十分
なんかの時のbitフラグ使用時もちょうどいいしな
99とか今時あるのか？
200 名前：NAME IS NULL mailto:sage [2010/11/22(月) 21:30:15 ID:???]: それを区別する要件があるなら違う値にすればいい
俺にはそれを区別する要件は思い浮かばない
３１日締めの指定って、２月とか４月とかの締めどうするんだ？
201 名前：NAME IS NULL mailto:sage [2010/11/22(月) 22:01:29 ID:???]: >>200
2月や4月の時に32指定だったら末日だとわかる。
31だとユーザや別システムの入力ミスかもしれない。
202 名前：NAME IS NULL mailto:sage [2010/11/22(月) 22:08:29 ID:???]: 31=月末
入力ミスとかDBでやるならトリガーで見張れよ
基本だろ…
203 名前：NAME IS NULL mailto:sage [2010/11/22(月) 22:34:58 ID:???]: >>201
それは入力ミスってるんだから別問題だろ
そんなの救ってやる必要ないと思われる
たまにそういう仕様外の動作をコードでキャッチしようとする奴がいるけど
問題の切り分けができてない
204 名前：NAME IS NULL mailto:sage [2010/11/22(月) 22:37:36 ID:???]: >>201
入力ミスって、３２でも入力ミスの可能性はあるわけだが？
結局３１でも３２でも、その月の末日で締めるわけだろ
わざわざ３１日締めという、月末締めとは別の状態が必要か？
それを正しく区別する設計というなら、指定日ごと締めと、月ごと（月末）締めの
締め区分みたいなものを別途用意するのが正解だろうな
205 名前：196 [2010/11/23(火) 22:38:58 ID:wQ8I8TMH]: 多くのレス有難うございます。31を月末締めとすればいいようですね。
206 名前：NAME IS NULL mailto:sage [2010/11/24(水) 00:22:54 ID:???]: >>205
いやー、仕様を確認したほうがいいと思うぞー
そもそも２９日締めとかって設定も入るようにする気か？
その場合２月とかどーすんだよｗ
本当は１日と１５日と末しかねーんだろ？
もしくは日付＋例外条件とかなってたら日にちで保存はヤバイかもしんないんだぞ
俺が前までいた会社は月の最期の営業日が締め日（技術者向けの）だったぞ
ただし、四半期の月じゃねーときは次の月のはじめの営業日までがセーフ・・・とかそんなんだ
複雑だろ？ｗ

もっと実務について詳しい担当と話合えよｗ
こーゆーのってディスプレイといくらにらめっこしててもダメだと思うぜ
207 名前：NAME IS NULL mailto:sage [2010/11/24(水) 00:39:33 ID:???]: それ、締め日じゃない何かと勘違いしてないか？
セーフとかなんだそれ。
208 名前：NAME IS NULL mailto:sage [2010/11/24(水) 05:20:01 ID:???]: 仕様を確認した方がいいのは確かにそうだが
>206の話は締め基準日と、稼働日とか絡んだ実際の締日は別ってだけの話だ
今問題にしてるのは、締め基準日が月末の場合にどう保持するってだけの話
そっから実際の締め日をどう算出するかはまた別の話
209 名前：NAME IS NULL mailto:sage [2010/11/24(水) 17:56:36 ID:???]: 仮に締め日が来月の１日だったときって日付保存ってダメじゃね？って言ってほしいの？
210 名前：NAME IS NULL mailto:sage [2010/11/24(水) 18:09:48 ID:???]: >>208
すでに実務として１～３１日って指定のが珍しいのに
これを継続して使うのってどうだろ？
よくある締め日と多少の例外ぐらいはサンプル集めたほうがいいと思うね

１日（先月分）、１５日（先月１６日～今月分）、２５日（先月２６日～今月２５日分）、月末（今月分）

だったら折角１～３１日まで入るようにしてあっても大半が無駄なわけじゃん
もうステータスでいいんじゃないの？
ステータスなら第二金曜日とか対応できるよ
211 名前：NAME IS NULL mailto:sage [2010/11/24(水) 18:21:48 ID:???]: わかった！varchar型にして末日だったら「末日」って登録すればいいんじゃないかな？
212 名前：NAME IS NULL mailto:sage [2010/11/24(水) 18:31:52 ID:???]: もう割り切って、テキストにすれば。
213 名前：NAME IS NULL mailto:sage [2010/11/24(水) 19:52:36 ID:???]: >>211
素直が一番ってのは俺の長年のＰＧ経験で学んだこと
214 名前：NAME IS NULL mailto:sage [2010/11/24(水) 23:03:51 ID:???]: ある売上が何年何月の第何週に起算されたものか、って言うのをシステム上で
表示して欲しいとか言われて、馬鹿正直に作ったら、
お盆期間は必ず8月の1週めに含む、とか、年末年始は～
とか色々なルールがあって結局全部コードに書いて何とかした。
今も動いてるのかなぁ、あのシステム。
215 名前：196 [2010/11/24(水) 23:16:33 ID:vMmyFVn7]: 意外に盛り上がっているので，ちょっと驚いています。

マジレスすると，都度請求なので，単に得意先の締め日がわかればいいだけなので，
あまり複雑には考えていませんでした。確かに，複数の締め日があったり，
締め日が変動するケースもありそうなので，まじめに考えると頭が痛いですね。
216 名前：NAME IS NULL mailto:sage [2010/11/24(水) 23:17:29 ID:???]: 売り上げの起算日とお盆期間がどう関係あるのかよく分からないや。
今年だったら、8/1-8/7がお盆になるとして、8/3の売り上げはそのまま
8月の第一週に起算されたものなんじゃないの？
217 名前：NAME IS NULL mailto:sage [2010/11/24(水) 23:43:33 ID:???]: こういう仕様は日本のSヨの飯のタネだからな。
218 名前：NAME IS NULL mailto:sage [2010/11/25(木) 00:59:50 ID:???]: いやだから8/13～15に立った売上は8月第一週換算とかそんな感じ。
8月12日はお盆期間じゃないから第二週換算だけど、とか。
219 名前：NAME IS NULL mailto:sage [2010/11/25(木) 02:30:12 ID:???]: あ。
お盆期間を8月1週とする、かと勘違いしてたorz
スマンカッター。

>>217
サマータイムとか旧正月とかあるし日本に限らないような気も。
220 名前：NAME IS NULL mailto:sage [2010/11/29(月) 17:50:54 ID:???]: 得意先マスタに訪問履歴1、訪問履歴2、訪問履歴3というカラムが。
何がしたいのか聞いてみたら、1回目の訪問時の内容を～、とのこと。
俺「3回以上訪問したら。。。？」
相手「その辺は運用で何とかします。大抵は3回分保持できれば十分ですので。」
だとさ。
221 名前：NAME IS NULL mailto:sage [2010/11/29(月) 19:39:04 ID:???]: >>220
なんとでもなるのに何を難しく考えているんだろうな？ｗ
素直に訪問履歴ｘＮ回になっても大丈夫なように作ってくれって言えばいいのにｗ
222 名前：NAME IS NULL mailto:sage [2010/11/29(月) 20:59:11 ID:???]: 履歴とかいうから全部残さなくていいのおおおお？と思っちまうけど、要は「初回3回までの訪問日時」だろそれ。
最初の数回の挨拶とか紹介だかの日時のメモ書きであって、4回以上は捨てて問題ないってこと。
RDBとしてはうんこだけど実運用考えればそれはそれでありだろう。
223 名前：NAME IS NULL mailto:sage [2010/11/29(月) 23:16:49 ID:???]: ほんとにメモ的な情報で良ければそれでもいいのだけど、
あとからとんでもなく重要な情報であることが発覚して、
大改修を迫られることになる。
さらに下請けの悲しさか費用は込みこみで；；
224 名前：NAME IS NULL mailto:sage [2010/11/29(月) 23:29:58 ID:???]: 大改修よりも運用で何とかしていたものを移行するのが死にそう。
過去データ登録機能を作って客に入れてもらうかｗ
225 名前：NAME IS NULL mailto:sage [2010/12/02(木) 01:57:55 ID:???]: SQL質疑応答スレから誘導されてきました。
hibari.2ch.net/test/read.cgi/db/1274791771

PHP＋MySQLなんですが、できるだけDBで処理しようと思っています。

お買い上げに応じて、ｎ％分を顧客にポイントを付与します。
これにはキャンペーンが存在して、水曜と日曜はポイント５倍、
７の付く日(7日、17日、27日)もポイント５倍、１日はポイント１０倍などあります。
１日が水曜日の場合は、倍率の大きい、ポイント１０倍が適用されます。
また、たとえば、クリスマス期間12月01日から12月26日まではポイント「さらに」１．５倍、三が日は一律１０倍などもあります。

こんな感じで、キャンペーンの曜日や期間、パーセンテージを自由に設定できるようにしたいです。
来月からは、水曜はポイント１０倍にしよう！なんてのもありえます。

よろしくお願いします。
226 名前：NAME IS NULL mailto:sage [2010/12/02(木) 02:14:52 ID:???]: 追加です。あんまり関係ないかもしれませんが。
先月の購入金額に応じて顧客にグレードがあり、
１万円以上の購入者は基本ポイントがｎ＋１％、
５万円以上の購入者は基本ポイントがｎ＋２％などとなります。
これもDBに格納させたいです。
227 名前：NAME IS NULL mailto:sage [2010/12/02(木) 02:40:04 ID:???]: いや
肝心のなにが聞きたいのかがわからんし
228 名前：NAME IS NULL mailto:sage [2010/12/02(木) 03:51:09 ID:???]: どういったテーブルの設計をすれば最適か伺いたかったのですが。。。
229 名前：NAME IS NULL mailto:sage [2010/12/02(木) 04:02:27 ID:???]: 「倍率が高いほうを優先」と「さらに」の2パターンしかないのかな。
230 名前：NAME IS NULL [2010/12/02(木) 04:08:27 ID:QCxu6itD]: >>225
せめて誘導元の議論ぐらい貼れよ

656 655 [] 2010/12/01(水) 19:43:16 ID:0WLtPE6T Be:
現状、
・日別キャンペーンテーブル
・曜日別キャンペーンテーブル
・期間キャンペーンテーブル
とバラバラに作って、PHPで処理しています。

１か月分のパーセンテージ一覧を作るのに、１日ごとにSQLを複数実行して
かなり重いので、その辺も簡略化できる設計だと助かります。

657 655 [] 2010/12/01(水) 20:21:55 ID:0WLtPE6T Be:
自己レスだけど、こうゆう場合は
カレンダーテーブル(日付、計算済み％をカラムに持つ)を作ってあげて、
各種キャンペーンテーブルを更新するたびに１か月分とかカレンダーテーブルを更新する設計がいいんだろうか？
それだと、売り上げの度に％を取得するのが１回のSQLで済む。
ただし、時間帯別のキャンペーンが作れない(作りにくい)のと、設定忘れなどで、昔の期間にキャンペーンを設定するのが面倒な点が変わらない。。。

658 NAME IS NULL [sage] 2010/12/01(水) 20:43:49 ID:??? Be:
ビュー作れ

660 NAME IS NULL [sage] 2010/12/01(水) 21:01:28 ID:??? Be:
曜日があるからビューはかなりムリゲーだったわ・・。

1,2,3-31の日付だけ持つダミーテーブルを作って指定月の一ヶ月の一覧を取得するSQLをまず作る。
(SQLは多少メンドクサイが)単純な計算なのでこのまま使っても重いとは思えないが、
もし重ければ>>657の通り、月初なりキャンペーンテーブル更新時なりに別テーブルにinsert ～ select すりゃおｋ

661 NAME IS NULL [sage] 2010/12/01(水) 22:05:00 ID:??? Be:
キャンペーンごとのテーブルが必要な理由が分からない
カレンダーだけ作ってバッチ更新でいいだろ

663 NAME IS NULL [sage] 2010/12/01(水) 22:10:19 ID:??? Be:
>>661
そのバッチは何テーブルを見て更新するつもりだ？

665 NAME IS NULL [sage] 2010/12/01(水) 22:28:26 ID:??? Be:
>>663
そんな変なキャンペーンルールなんかバッチ側にもてばいい

666 NAME IS NULL [sage] 2010/12/01(水) 22:48:24 ID:??? Be:
>>665
例えばドトールのような不定期なキャンペーンを展開してるシステムとかどうするんだよ間抜け
毎月バッチリリースすんのかよｗ

667 NAME IS NULL [sage] 2010/12/01(水) 22:55:45 ID:??? Be:
水曜日のパーセンテージ変えようぜってやったら指定日以降の水曜日だけ変わってほしいよねきっと。
今曜日キャンペーンテーブルに期間もたせてるの？ないなら持たせないといけないんだよねぇ。

カレンダー的なメンテナンス画面作るのが楽だと思うなぁ。

668 655 [] 2010/12/02(木) 00:26:41 ID:u5kOJKQ0 Be:
曜日キャンペーンに期間は必要ですねぇ。
いまはまだ付けてないです。
参考にさせていただきます。

それでは、スレ違いだったようなので、別スレにて再度、投稿してきます。
231 名前：NAME IS NULL mailto:sage [2010/12/02(木) 04:43:33 ID:???]: それぞれのキャンペーンで、パーセンテージを「５％に置き換え」「３％加算」「ｎ倍にする」といった種類をつけたいです。

キャンペーンで、決算キャンペーン12月は＋５％、クリスマス期間は「さらに＋５％（計１０％）」「１０％に置き換え」といったような、
期間が重複する場合も、期間の範囲が広いほうから狭いほうに順に計算したいです。
232 名前：NAME IS NULL mailto:sage [2010/12/02(木) 07:16:56 ID:???]: キャンペーンテーブル作って
買い物ごとに適用されたキャンペーンＩＤ入れておけばいいだろ
±Ｘが％なのか○円以上で～なのかは多分ルールが変わるだろうからその辺は
その都度でいいんじゃね？（f(x)の形）
233 名前：NAME IS NULL mailto:sage [2010/12/02(木) 16:41:21 ID:???]: 複数のキャンペーンが適用される場合は？
234 名前：NAME IS NULL mailto:sage [2010/12/02(木) 17:43:45 ID:???]: >>233
>>232に対してのレスだろうか。別途テーブル起こせってことじゃないかと思うんだけど、
そもそもの主眼は適用されるキャンペーンを楽に取得することだからなぁ。
235 名前：NAME IS NULL mailto:sage [2010/12/02(木) 18:33:50 ID:???]: 別テーブルかぁ。
１２月３日になって、「そういえば今月は決算キャンペーンだと発表してたのに、システムの設定忘れてた」
って場合はどうする？
236 名前：NAME IS NULL mailto:sage [2010/12/02(木) 18:50:16 ID:???]: いまキャンペーンテーブルは日別、曜日別、期間別の３つに分かれているわけだけど、
これを１つにまとめちゃうスマートなアイディアは無いの？
237 名前：NAME IS NULL mailto:sage [2010/12/02(木) 18:53:48 ID:???]: まとめればいいじゃん
開始日付,終了日付,キャンペーンID
そういう～別とかいうのは月次処理でやりゃいい
238 名前：NAME IS NULL mailto:sage [2010/12/02(木) 18:55:13 ID:???]: 発表した時点でキャンペーン情報を登録しておくべきだよねぇ。

忘れてた時どうするといわれても、どちらかというと別テーブルで保持したほうがバッチつくりやすそうには思うぐらいで、
めんどくさい作業が待ってることには違いないかな。
239 名前：NAME IS NULL mailto:sage [2010/12/02(木) 18:56:21 ID:???]: このスレ質問者はIDを出す文化がないのか、とおもったけど質問スレじゃなかったな
240 名前：NAME IS NULL mailto:sage [2010/12/02(木) 19:01:35 ID:???]: そもそもDB設計なんざ枯れてるんだから迷う要素なんてないだろ
設計というのも恥ずかしいぐらい簡単
241 名前：NAME IS NULL mailto:sage [2010/12/02(木) 19:22:27 ID:???]: 簡単すぎて書く気にもならないってレスはまだか？
242 名前：NAME IS NULL mailto:sage [2010/12/02(木) 19:23:31 ID:???]: >>233
複数登録できるようにしたらいいんじゃない？っていうしなきゃダメだな
なんのキャンペーンが適用されてこの値段になったのかわからないとか最悪の結果だ
計算によって％だけ出して会計すませりゃいいって問題じゃないだろ
下手したら脱税で訴えられそう
243 名前：NAME IS NULL mailto:sage [2010/12/03(金) 00:26:26 ID:???]: 売り上げテーブル
+ID
+売り上げ金額
+ポイント額

キャンペーン適用テーブル
+売り上げID
+キャンペーンID

みたいな感じ？
244 名前：NAME IS NULL mailto:sage [2010/12/03(金) 01:11:56 ID:???]: しらね
どういうＤＢ作りたいのか詳しく知りたくないからよく読んでない
キャンペーンは確実にその日すべての買い物に適用されるとかなるのか仕様がよくわかってない
タイムサービスとかないんだろか？とか結局なんの統計とりたいの？とかよくわかんねーし
やっぱ、この辺は担当者とお話してちゃんと仕様決めないとね

一般的な～ってないと思うよ
245 名前：NAME IS NULL mailto:sage [2010/12/03(金) 02:02:02 ID:???]: え、今日ポイントどれくらいつくの？ってのを取得しやすい設計を知りたいんじゃないの？
俺はそれに応じたレスをいくつかしてはいるんだけれど。

統計とか何の話だろうって思うわ。
246 名前：NAME IS NULL mailto:sage [2010/12/03(金) 07:27:23 ID:???]: >>245
追記で購入金額に応じたポイントまであるんだから全売上の詳細まで管理したいような感じもするけどね
247 名前：NAME IS NULL mailto:sage [2010/12/03(金) 07:31:51 ID:???]: 買い物客ごとにデータを保持しておいたほうがいいね
実運用では商品によってキャンペーン対象外商品がきっとある（でないと転売屋天国になるからな）

まあ、教科書的な答えだけほしいってんならテキトーでいいと思うけどねｗ
248 名前：NAME IS NULL mailto:sage [2010/12/03(金) 09:57:47 ID:???]: キャンペーン複数適用するのに
たとえばAキャンペーンが1000円引き、
Bキャンペーンが1割引だったとしたら
正価から1000円引いてから1割引するのか、
1割引してから1000円引きなのか、とかも考慮する必要あるし
もっと仕様を詰めないといけないんじゃない？
逆に言えば仕様が固まればおのずとDBは決まると思うけど
249 名前：NAME IS NULL mailto:sage [2010/12/03(金) 09:59:50 ID:???]: ああ、値引じゃなくてポイントか
まぁ話としては変わらんけど
250 名前：225 mailto:sage [2010/12/04(土) 02:47:21 ID:???]: >>248
それもPHPコードで決めうちじゃなくて、
計算順をDBに入れて、利用者が設定できるようにしたいですね。
251 名前：225 mailto:sage [2010/12/04(土) 03:04:53 ID:???]: 例えば、キャンペーンにプライオリティカラムをつけて、
その順番に適用していくとか。
252 名前：NAME IS NULL mailto:sage [2010/12/04(土) 07:05:44 ID:???]: 結局どこで詰まってるんだか。

> １か月分のパーセンテージ一覧を作るのに、１日ごとにSQLを複数実行して
> かなり重いので、その辺も簡略化できる設計だと助かります。
3テーブルあって、月次バッチ処理をしているとして、1日ごとに実行したとしても、90回の抽出と30回の挿入だよね。
なんでそんなのが重くなるんだ？
DB今のままでちょっとチューニングしたら終わるんでないの。
253 名前：NAME IS NULL mailto:sage [2010/12/04(土) 07:58:31 ID:???]: IPアドレスの管理表をおこしたいのですが、IPアドレス毎に、使用者情報、inbound接続ができる
(=開いてる)ポート番号のリストを持たせようと思っています。
使用者情報まではいいのですが、開いてるポート番号の情報はどのように持てばいいでしょうか？

この開いてるポート番号情報は例えば 22,80,443,3024-3054 といった情報になります。
そして、このポート番号情報にからめて「xx番が開いている未使用のアドレス」という検索がで
きるようにしたいと考えています。

扱うIPアドレス数はたかだか1000件も扱えれば充分なのですが、「0-65535(ポート全開)」とい
うアドレスも扱わなければならないので、悩んでいます。

テーブル1(ip_table)
|ID|IPアドレス|使用者情報など|
テーブル2(opned_tcp_port_table)
|ID|ip_table.ID|ポート番号|
と割っておいて、select 時には join してから select する手もありますが、(ポート全開)な
アドレスの扱いがえらいこと(65536行に膨らむ＆opned_tcp_port_tableに65536行分入れておか
ないといけない)になりそうで、ここが悩みのポイントです。
254 名前：NAME IS NULL mailto:sage [2010/12/04(土) 08:18:26 ID:???]: テーブル2
ID ip_table.ID ポート番号下ポート番号上
1 1 0 65535
2 2 22 22
3 2 80 80
4 2 3024 3054

select ip_table.ID from テーブル2 where xx between ポート番号下 and ポート番号上
255 名前：NAME IS NULL mailto:sage [2010/12/04(土) 09:30:17 ID:???]: >>254
between何てのがあったと！
それをip_tableにjoinすれば使いたいポートが開いてるアドレス一覧が取れると。

ありがとうございました。
256 名前：NAME IS NULL mailto:sage [2010/12/04(土) 12:08:16 ID:???]: >>255

開いてる)ポート番号が飛び飛びだったらどうすんの？
257 名前：NAME IS NULL mailto:sage [2010/12/04(土) 12:18:45 ID:???]: 16ビットで表現できるな。
258 名前：NAME IS NULL mailto:sage [2010/12/04(土) 15:10:22 ID:???]: IPアドレスマスタ
IPAddress(PK) , ValidFlag

IPアドレス使用者テーブル
IPAddress(PK),SeqNum(PK),UserAccount,ValidDate,InvalidDate

こんな感じじゃダメなんか
259 名前：NAME IS NULL mailto:sage [2010/12/04(土) 19:14:51 ID:???]: 給与の締め日と支払い日を管理するDB設計は、どういった形がよいでしょうか？

月ごとに25日締め翌月5日払いとか、
週ごとに締めて、翌水曜日払いとか、
２週ごとに締めて、翌水曜日払いとか。

こういった要件を自由にカスタマイズできるようにしたいです。
260 名前：NAME IS NULL mailto:sage [2010/12/04(土) 19:23:23 ID:???]: タイプ：月、週、日
締日
支払日

こんだけ
261 名前：NAME IS NULL mailto:sage [2010/12/04(土) 19:25:38 ID:???]: 二週ごと、とか無理だろ。
DBでやるのは無理だから、ビジネスロジックでやるもんじゃね？
262 名前：NAME IS NULL mailto:sage [2010/12/04(土) 20:02:41 ID:???]: 給与の締め日ってどんな感じで色々かわんのかね？
パッケージ向けってつーことかい
263 名前：NAME IS NULL mailto:sage [2010/12/04(土) 20:31:05 ID:???]: >>256
偶数番号のみ全開とかは泣ける…

>>258
IPアドレスマスタの ValidFlag はもしかして、65536bitのポート開いてる閉じてるフラグ？
264 名前：NAME IS NULL mailto:sage [2010/12/04(土) 20:43:27 ID:???]: >>253
悩むのは6500万件のテーブルが「えらいこと」かどうか確認してからでいいだろ。
265 名前：NAME IS NULL mailto:sage [2010/12/04(土) 20:46:42 ID:???]: 65536bit・・・だめだこりゃ。
266 名前：NAME IS NULL mailto:sage [2010/12/04(土) 22:41:40 ID:???]: >>255
betweenじゃなくても、
ポート番号下 <= xx and xx <= ポート番号上
で同じことになるよ。
267 名前：NAME IS NULL mailto:sage [2010/12/05(日) 08:23:47 ID:???]: >>259
DBに計算式のスクリプトを直接突っ込んでる
268 名前：NAME IS NULL mailto:sage [2010/12/06(月) 01:27:26 ID:???]: >>263
ああ、外部公開用WANじゃなくて、クライアントのIPアドレスの話か
ならLANが前提だろからIPアドレスは主キーには出来ないのでFQDN見るしかない
NICの複数差しも考慮しなくちゃいけない

クライアントマシン公開ポートテーブル
FQDN(PK),NicNum(PK),SeqNum(PK),IPAddress,Protocol,StartPortNum,EndPortNum

ユーザーは別テーブルでFQDNと紐付けて、ポートの重複とか論理整合はストアドで取ればいいんじゃね？
269 名前：NAME IS NULL mailto:sage [2010/12/06(月) 02:57:25 ID:???]: なんだこの展開
270 名前：NAME IS NULL mailto:sage [2010/12/06(月) 10:05:28 ID:???]: しばらく見てなかったらえらい複雑な展開になっているみたいで申し訳ない。
後出しで申し訳ないんだけど、やりたいアプリは/24程度のFWの裏にいるグロー
バルアドレス持ちなネットワークのアドレス管理なのですよ。
FWでアドレス毎にinboundの接続設定が異なっているので、それの管理用アプ
リに、と思った次第。
基本　アドレス、利用者、開いてるポート番号　の要素を管理しておきたくて、
このネットワークの利用者からは「××番が開いてるアドレスなーい？」とか
「全開のアドレス空いてない？」いう問い合わせが多いので、ポートの状況で
検索というのが要件に挙がったと。

ここまででいくつかアイデア頂いてるので、それぞれ試作して検討してみます。
なので一旦closeということで。
271 名前：NAME IS NULL [2010/12/24(金) 18:04:55 ID:CmCii1Ay]: 誘導されました

記事が著者、カテゴリ、タグとそれぞれ多対多の関係になる場合次のどっちが使いやすい、パフォーマンスがいい、ですか（検索など）？
記事の分類が増えることはなく、著者はただの分類でログイン等は持ちません。

記事: id, body
著者: id, name
カテゴリ: id, name
タグ:id, name
著者関係: 著者id, 記事id
カテゴリ関係: カテゴリid, 記事id
タグ関係: タグid, 記事id

記事: id, body
taxo: id, name, type
taxo関係: taxoid, 記事id
※taxo.typeは著者、カテゴリ、タグのいずれか
hibari.2ch.net/test/read.cgi/db/1276247839/888-889
272 名前：NAME IS NULL mailto:sage [2010/12/24(金) 23:16:31 ID:???]: >>271
前者じゃないかな。あと、気持ちの問題だけど、記事idを先頭に持って行きたい
273 名前：NAME IS NULL mailto:sage [2010/12/26(日) 07:58:53 ID:???]: 個人的にば、一つの事象を一つのエンティティとして切り出すほうが好きなので、前者で作って、
著者名、カテゴリ名、タグ名から透過的に検索するために、taxo関係をビューにするかな。
274 名前：271 [2010/12/26(日) 15:36:39 ID:xB/ukp6t]: >>272-273
ありがとうございます。

> taxo関係をビューにするかな。
これのやり方がわからないんで教えてもらっていいですか？
275 名前：NAME IS NULL mailto:sage [2010/12/26(日) 15:56:32 ID:???]: >>274
単にJOINしたSQLをビューにしておくっていう意味以上のものはないと思うぞ
276 名前：NAME IS NULL mailto:sage [2010/12/26(日) 15:58:15 ID:???]: あ、つまり↑の作りの場合のデメリットはテーブルが増えすぎてわけわかんなくなるかも、ってことだから
ビューをあらかじめ作っておこうという嗅覚が働いたという話かと。
277 名前：271 mailto:sage [2010/12/26(日) 16:11:28 ID:???]: テーブル数は気にならないのでとりあえず上で行って見ます。
ありがとうございました。
278 名前：NAME IS NULL [2010/12/29(水) 19:53:07 ID:7r5KYmdf]: テーブルAのある列の値がXのときだけ、テーブルBに対応するレコードが存在する。X以外では存在しない、
っていう制約がある場合、アプリ側だけで制御してる？トリガーとかでDB側でも制御してる？
279 名前：NAME IS NULL mailto:sage [2010/12/29(水) 21:56:30 ID:???]: >>278
その制約が破られたときの金銭的損失、瑕疵として損害賠償請求されたときの想定金額次第
280 名前：NAME IS NULL mailto:sage [2010/12/30(木) 04:15:29 ID:???]: >>278
俺的にはDB側にあんまり制約つけるの好きじゃないんだが
そのDBが一つのアプリ（システム）からしか利用されないならそのアプリで制御する
複数のシステムで共有されるようなDBなら、DB側になんらかの制御を入れる
ぐらいの基準かな
281 名前：NAME IS NULL mailto:sage [2010/12/30(木) 09:39:51 ID:???]: あるDBが複数のアプリから利用された場合を想定して、DB側でも制御、だなぁ。
とあるシステムで、顧客情報をWebアプリからも登録されるし、
オフラインのFaxやハガキからも登録される、っていうシステム見たんだけど、
オンラインからはメールアドレス必須なのに、Faxなんかには入ってなくって、
オンライン側でバグる、みたいなことが立て続けに発生してた。
282 名前：NAME IS NULL mailto:sage [2010/12/30(木) 11:07:18 ID:???]: 個人的には仕様書がないときにバイナリしか残ってないアプリからじゃなにも分からないけど、
DB側に実装しておいてもらえれば、最悪でも仕様だけは知ることが出来るからDB側で実装してほしい。
283 名前：NAME IS NULL mailto:sage [2010/12/30(木) 13:24:19 ID:???]: 新任の後任者が仕様変更で一方のロジックしか直さず
顧客をブチ切れさせるのが通過儀礼となる図
284 名前：NAME IS NULL mailto:sage [2010/12/30(木) 13:27:35 ID:???]: そもそもそんな設計が悪い、とか言い出す奴がそろそろ登場する悪寒。
285 名前：NAME IS NULL [2011/01/01(土) 06:48:29 ID:ZTfqWojz]: ・ユーザ情報テーブル（画像1枚）
・店舗情報テーブル（画像複数）

上のような複数のテーブルに、
それぞれアップロードされた画像の情報を持ちたいんですが、どうするのが一般的/スマートでしょうか。
それぞれ画像が1枚だけなら、そのテーブル自体に画像情報フィールドでもつくればいいのですが、
複数の場合があるので悩んでいます。

自分で思いついたのは、
・画像情報テーブル
を作って
そのテーブルに
foreign_id INT UNSIGNED　/* 外部キー */
forein_type enum('user', 'shop')　/* どのテーブルの外部キーかの値 */
てな感じで、外部キーをもたせつつ、その外部キーがどのテーブルのものかを判断する値も持たせれば
良いかなと思ったのですが、
もっと良い方法ありますか？
286 名前：NAME IS NULL mailto:sage [2011/01/01(土) 10:29:45 ID:???]: >>285
・ユーザ画像テーブル
・店舗画像テーブル
をもっちゃいけないの？
画像テーブル一つにまとめて画像データすべてに対してなんらかの処理をしたいなら
一つにまとめるのもアリだと思うけど・・・
普通はint情報テーブルとかもたないよねｗ・・・
287 名前：NAME IS NULL [2011/01/01(土) 11:30:36 ID:ZTfqWojz]: >>286
それだと、今後別のテーブルにまた画像が必要なときにまた画像テーブルをつくるはめになるので、、、
１つのテーブルに画像情報がまとまっていれば、
そのテーブルに対するモデルさえあれば、
今後どんなテーブルに画像が必要になっても対応できるので、
なるべく１つのテーブルで管理したいんですよね
288 名前：NAME IS NULL mailto:sage [2011/01/01(土) 11:48:57 ID:???]: 画像情報テーブルにユニークなキーがあれば、
それがユーザーのものか店舗のものかは気にしなくていいんじゃない？

何のために、どのテーブルのものかを判断するの？
289 名前：NAME IS NULL [2011/01/01(土) 12:05:43 ID:ZTfqWojz]: >>288
例えば店舗情報を表示するページで店舗画像を取ってくるわけですが、
画像テーブルの外部キーが店舗のIDなのか、ユーザのIDなのかがわからないためです
290 名前：NAME IS NULL mailto:sage [2011/01/01(土) 12:21:08 ID:???]: ダメだこりゃ。
291 名前：NAME IS NULL mailto:sage [2011/01/01(土) 15:40:51 ID:???]: その「画像データ本人」が自分が店舗画像下ユーザ画像なのかを知ってる必要はないよね。
292 名前：NAME IS NULL [2011/01/01(土) 18:42:11 ID:ZTfqWojz]: >>291
すいません、完全に理解できないです・・・。申し訳ない。

画像データが店舗のものかユーザのものか判断するのは
どのテーブルのフィールドが担うんでしょうか？
画像が必要なテーブルに、
画像IDを外部キーとして保持するとしても、
複数画像に対応できない気がしますが、認識が間違ってますか？？
293 名前：NAME IS NULL mailto:sage [2011/01/01(土) 19:00:55 ID:???]: ・画像情報関連テーブル
ユーザか店舗のキー画像のキー

これでなんか問題あるの？
294 名前：NAME IS NULL mailto:sage [2011/01/01(土) 19:04:06 ID:???]: >>292
画像がユーザーあるいは店舗に従属するのであれば、ユーザーと店舗の
テーブルを分けた時点で画像の方も分けなければならない。
どうしても画像テーブルを一つにしたいのであれば、手としては2つある。
・ユーザー・店舗の共通エンティティを用意する
→ただし、ユーザー画像は常に1つ、店舗画像は複数可、などは表現できない
・ユーザー―画像、店舗―画像という連関エンティティを別に用意する。
→場合によっては素直にユーザー画像テーブル、店舗画像テーブルの方が簡単
295 名前：NAME IS NULL [2011/01/01(土) 21:28:19 ID:ZTfqWojz]: >>293
店舗とユーザのIDは別テーブルなので重複する可能性がありますね。わかりづらくてすいません

>>294
> 画像がユーザーあるいは店舗に従属するのであれば、ユーザーと店舗の
> テーブルを分けた時点で画像の方も分けなければならない。
うーんやはりそうかぁ。
素直に
・ユーザ画像テーブル
・店舗画像テーブル
を作ろうかな。

ありがとうございました。
296 名前：NAME IS NULL mailto:sage [2011/01/01(土) 21:36:49 ID:???]: 店舗とユーザのどっちかを判別できるキーにすりゃいいだけだろ
アプリ側からしたらユーザか店舗かはJOIN時に分かりきってるんだから
解決したならもういいけどさ
297 名前：NAME IS NULL mailto:sage [2011/01/02(日) 13:20:56 ID:???]: >>295
教科書的な作り方なら

・ユーザ＆画像関連テーブル（ユーザ識別＋画像ＩＤ）
・店舗＆画像関連テーブル（店舗識別＋画像ＩＤ）

・画像テーブル

の３つが必要
298 名前：NAME IS NULL [2011/01/03(月) 04:07:50 ID:5FnD8U9u]: >>297
あ～こっちのほうがいいですね。
これでいきます！
どうもです
299 名前：NAME IS NULL mailto:sage [2011/01/08(土) 17:11:01 ID:???]: 今Excelに以下のような形でデータを保存しています

A列保存場所 e.g F:\data\～\～
B列ファイル名 e.g [xxxx] dddddd.doc
C列作者名 B列ファイル名のxxxxの部分
D列タイトル名 B列ファイル名のdddddd.docの部分
E列～G列ジャンル D列の作品がどういうジャンルに属しているか
H列コメント

E列～G列のジャンルについては現在最大3つ（別にそれに縛られる必要はないのですが）で、最低限1つは必ずあります。
H列についてはあれば記載

で、勉強も兼ねてテーブル化しようと思っているのですが。

作者テーブル
作者名
読み
ジャンルテーブル
ジャンル
は思いついたのですが、
メインのデータテーブルはどのように持てば？という事で
教えていただけたら m(_ _)m
※データテーブルにはファイルをバイナリで入れる事はせずA列の保存場所を
持っていれば良いと思っています
300 名前：NAME IS NULL mailto:sage [2011/01/08(土) 17:17:20 ID:???]: メインは↓みたいな感じでいいんじゃね？

ID、タイトル名、保存場所、ファイル名、作者ID、ジャンルID、コメント
301 名前：299 mailto:sage [2011/01/08(土) 19:59:44 ID:???]: 有難うございます
まぁそういう形になるのかなぁと。
それで試しに作ってみます。
302 名前：NAME IS NULL mailto:sage [2011/01/09(日) 09:23:28 ID:???]: ・ひとつの「タイトル」は、3つ(?)の「ジャンル」を持つ
・ひとつの「ファイル」に、「タイトル」はひとつ
・ひとつの「タイトル」で、複数の「ファイル」がある
・「タイトル」が同じでも、別のファイルなら、作者名、コメントは別？

タイトル { タイトルID, タイトル名 }
ファイル { ファイルID, タイトルID, 保存場所, ファイル名, 作者ID, コメント }
タイトルジャンル { タイトルID, ジャンルID }
303 名前：299 mailto:sage [2011/01/09(日) 10:28:16 ID:???]: ・ひとつの「タイトル」は、3つ(?)の「ジャンル」を持つ
現在はジャンルを3つにしていますが、3つに限定しないといけない理由は
ないです。ただ最低限1つはかならず持つという事で

・ひとつの「ファイル」に、「タイトル」はひとつ
　　タイトルは1つです

・ひとつの「タイトル」で、複数の「ファイル」がある
・「タイトル」が同じでも、別のファイルなら、作者名、コメントは別？

　複数の作者で同じタイトルという可能性はあります。ただしその場合
ファイルは別々ですが。
304 名前：NAME IS NULL [2011/01/11(火) 17:00:09 ID:3vuTbP2k]: すんごい基本的な事なんだけど、毎回悩む。
たとえば、男、女の様なマスターが欲しいとき、IDはふった方が良いんですかね？

男、女をそのままデータテーブルで保存するようにしても欠点が分からない。
容量の削減にはなるとは思うが、クエリなどでわざわざマスターからリンクしなくてもよい
という利点もあるし。

ただ、マスターテーブルが不恰好な気がするが…。

うーん、、
305 名前：NAME IS NULL mailto:sage [2011/01/11(火) 17:06:04 ID:???]: 最近は性別も更新される可能性のある属性ですｗｗｗ
306 名前：NAME IS NULL mailto:sage [2011/01/11(火) 18:10:31 ID:???]: マスターの方を変えたらジェンダーフリーすぎだろｗ
307 名前：NAME IS NULL mailto:sage [2011/01/11(火) 18:16:12 ID:???]: 性別欄が必須でないデータってのもよくある話で、
男性、女性、中性、（未選択）
くらいはあってもよい気がする。
308 名前：NAME IS NULL mailto:sage [2011/01/11(火) 18:20:43 ID:???]: JISで性別のコードって規定されてなかったか
309 名前：NAME IS NULL mailto:sage [2011/01/11(火) 19:23:54 ID:???]: 男男性 M Male のように表現がいろいろあるから残念な気持ちになりつつ、男と女の2レコードを作っておくといいんじゃないかな
310 名前：NAME IS NULL mailto:sage [2011/01/11(火) 23:41:02 ID:???]: >>304
どっちでもいいんじゃない？
プログラム組んでてもそういう問題ってあるじゃない
311 名前：NAME IS NULL mailto:sage [2011/01/12(水) 10:09:47 ID:???]: >>304
自分の個人的な判断基準は、その値が表示するだけ（帳票に出ればいいだけ）なのか、検索やグルーピングで使うかかな。
後者なら一応IDにしておく。
312 名前：NAME IS NULL mailto:sage [2011/01/12(水) 23:24:06 ID:???]: 二つだから気になるんだ
オカマとオナベもつけておけば気にならない
313 名前：NAME IS NULL mailto:sage [2011/01/12(水) 23:55:36 ID:???]: >>308
JISは廃止された（はず）だけど、ISO/IEC 5218:2004　はまだ生きてるかな。
314 名前：NAME IS NULL mailto:sage [2011/01/13(木) 15:55:10 ID:???]: 外部テーブルにすれば外部キー制約が使えるが生データだと使えない
検索はインデックス張っておけばIDもvarcharも大差ない。
315 名前：NAME IS NULL mailto:sage [2011/01/13(木) 17:26:19 ID:???]: キー＝データになるんだから外部キー制約は使えるんじゃないか？
316 名前：NAME IS NULL mailto:sage [2011/01/14(金) 03:55:41 ID:???]: >>314
チェック制約じゃまずいの？
317 名前：NAME IS NULL mailto:sage [2011/01/14(金) 08:43:52 ID:???]: MySQLはCHECKねえじゃん
318 名前：NAME IS NULL mailto:sage [2011/01/14(金) 11:53:52 ID:???]: MySQL前提だったとは。
319 名前：NAME IS NULL mailto:sage [2011/01/15(土) 12:11:14 ID:???]: 標準はティムポウェアだよ
320 名前：NAME IS NULL mailto:sage [2011/02/09(水) 06:46:45 ID:???]: 目指してる未来が違うｗｗｗｗｗｗ　ｂｙシャープ
twitter.com/junaoki1/status/6553250337656833　
321 名前：NAME IS NULL mailto:sage [2011/02/15(火) 06:01:04 ID:???]: 使用DBはOracleです。

■生徒テーブル
１．生徒NO→表の中で一意かつnullを許さない
２．クラスNO→nullを許さない
３．出席番号→クラス内で一意かつnullを許さない
４．生徒名→nullを許さない

1番にはPK、2,4番にはnot null制約をつければいいとして
3番はどうすれば良いのでしょうか？
322 名前：321 mailto:sage [2011/02/15(火) 06:08:14 ID:???]: 解決策として、「クラスNO」と「出席番号」を結合した「クラス別出席番号」という列を作り
ユニーク制約を付けようと思ってます。

もう少しスマートな方法があれば教えてください。
323 名前：NAME IS NULL mailto:sage [2011/02/15(火) 06:10:40 ID:???]: check制約でもいいと思うけどね
324 名前：NAME IS NULL mailto:sage [2011/02/15(火) 06:42:00 ID:???]: >>323
チェック制約だと他の列を参照することはできても、他の行を参照することはできないので
要件を満たせないんじゃないですか？
325 名前：NAME IS NULL mailto:sage [2011/02/15(火) 07:07:42 ID:???]: 普通にout_of_line_constraintでunique制約つければいい
326 名前：NAME IS NULL mailto:sage [2011/02/15(火) 08:35:30 ID:???]: >>325
ユニーク制約は複数列指定できたんですね。
1番スマートな方法ですね。
ありがとうございます。
327 名前：デフォルトの名無しさん [2011/02/19(土) 16:24:44 ID:rzbDbHjB]: 汎用マスタとか名称マスタとか呼ばれてるごった煮管理なOTLTなテーブルって
いまだに現役？
328 名前：NAME IS NULL mailto:sage [2011/02/19(土) 16:45:15 ID:???]: 現役のところ知っているけど
聞いてどうするの？
329 名前：デフォルトの名無しさん mailto:sage [2011/02/20(日) 13:11:42.68 ID:???]: その手のマスタにもサロゲートキーをつけて、
ジャーナルデータにはサロゲートキーを埋める形にするべきなのか迷ったので。
あと、適用期間をもって世代管理をしているマスタで親子関係があった場合、
子側のマスタには親のコードを要素として持つべきか否かで迷ってる。
330 名前：NAME IS NULL mailto:sage [2011/02/20(日) 14:15:42.10 ID:???]: サロゲートキーを使っている現場に出くわしたことない。
サロゲートキーを使おうとしていた現場はあったけど、
キーマンの一言「意味わからん」でお蔵になった。
331 名前：NAME IS NULL mailto:sage [2011/02/21(月) 16:11:30.78 ID:???]: だいたいどのページ見ても、総合的に見てサロゲートキーは良いみたいに書いてあるけど
実際はそこまでサロゲートキーを使ってるところが多くないのはなんでだ？
332 名前：NAME IS NULL mailto:sage [2011/02/21(月) 22:04:24.48 ID:???]: この間は複合キーの方が自然だからって押し切られたな。
変更に強い->そんな変更はあり得ない。あったらどうせ大改修だから意味がない。
ORMで楽->フレームワーク側の都合で設計するのは如何なものか。
333 名前：NAME IS NULL mailto:sage [2011/02/21(月) 22:11:50.75 ID:???]: 実際なくてもいい類のものだからな。冗長になることで面倒事も増えたりするし。
流行とか嗜好、メンバーのレベルで臨機応変に変えて問題ないものだから、
その押し切ったリーダーや「意味わからん」つったキーマンが無能というわけではない。
334 名前：NAME IS NULL mailto:sage [2011/02/21(月) 22:55:57.34 ID:???]: >>331
設計上不自然な値がキーになってしまうから直感的に避けられてる
335 名前：NAME IS NULL mailto:sage [2011/02/21(月) 23:43:07.58 ID:???]: >>332
そこは説明のしかた次第なんだろうけど、条件をつけずに「変更に強い」とか、
あたかも万能みたいに言ったらそりゃ眉唾で見られるだろうな。
336 名前：NAME IS NULL mailto:sage [2011/02/21(月) 23:52:10.02 ID:???]: >>334
なんか気持ち悪い・・・ってやつか。

webや書籍で、サロゲートキーについて触れてるのないかな？
具体的にテーブルの定義情報がいくつかあって
どこがどうゆうふうに変更された場合、サロゲートキー使ってる場合は
こうゆう手順で改修ができる。

複合PKを使ってる場合は、こうゆう手順で改修を行う必要があるみたいな
具体的な作業内容が見たい。
できれば筆者の経験談を元に書いてるのがいいな。
337 名前：NAME IS NULL mailto:sage [2011/02/22(火) 00:24:45.79 ID:???]: SQLアタマアカデミー：第3回　テーブル設計のグレーゾーン～毒と薬は紙一重　（4）サロゲートキーVSナチュラルキー｜gihyo.jp … 技術評論社
gihyo.jp/dev/serial/01/sql_academy2/000304
338 名前：NAME IS NULL mailto:sage [2011/02/22(火) 00:51:45.64 ID:???]: サロゲートキーと何でも一括りにするのって良くないと思うんだ。
人工キーを導入するにしても場面場面でその理由は異なるはずで、
そこを個別の事例ごとにきちんと区別して捉えないと、何でも
サロゲートキーマンセーとかいう困ったちゃんが出てくる。

改修に強くするためという理由でサロゲートキーを導入するのは
元々のデータモデルに時間不変な一意キーが無かったからだよね。
この場合サロゲートキーとはいっても元のデータモデルに修正を
入れているし、下手すりゃビジネスフローのところまで戻って
考え直した方が良いのかもしれない。
でも例えばパフォーマンス等の理由で複合キーを回避するために
使うという場合はサロゲートキーを導入するとはいえ、やりたい
こと自体は元のデータモデルと等価なことだよね。この場合既に
正規化されたスキーマに新たにキーを追加することで大抵は
第三正規形が崩れる。そこを意識して制約とかを加えないと後で
ハまる。

流行とかじゃなくて、ケースバイケースで丁寧に検討する必要が
あると思う。
339 名前：NAME IS NULL mailto:sage [2011/02/22(火) 15:36:28.74 ID:???]: >>337
なぜか図11では開始時点と終了時点のカラムの値が編集されていないが
これだと商品ID001で検索すると2つhitして
一応代理キーの値が大きいほど新しいということである程度わかるが
いつからいつまで001がガムテープだったのかがわからんよね。

さらにこのサロゲートキーの使い方だと、商品IDにユニーク制約付けられないから
アプリでミスったらどうにもならなくなるな。
怖すぎるんだが。

おれんとこは、得意先の合併とかで、得意先マスタの得意先NOの使い回しが行われるような場合に備えて
トランザクションのデータを作った時の名称も同時にトランザクションのテーブルに埋め込んじゃうんだが。
サロゲートキーも使ってない。

■受注明細
商品NO
商品名称
得意先NO
得意先名称
日時

上記のようなテーブルにしといて、検収まで終わった「過去」の受注明細を「参照」するときは
テーブルを結合せずに得意先名称をひっぱってきたりする。
不細工な形だが、わかりやすいんだ・・・
340 名前：NAME IS NULL mailto:sage [2011/02/22(火) 16:12:26.97 ID:???]: 履歴的なテーブルならまぁそういうやり方のとこが多いんだろうね
過去に遡って洗い替えとかあると死ねるけど
341 名前：NAME IS NULL mailto:sage [2011/02/22(火) 18:41:41.93 ID:???]: ちなみに商品IDの付け替えってありなの？
なにかと面倒だし、大した手間でもないから必ず新しいの作ってもらったほうがいいと思うんだが。

得意先は合併とかあるからお客さんの要望次第って感じだが。
342 名前：NAME IS NULL mailto:sage [2011/02/22(火) 20:54:07.27 ID:???]: 顧客要望によってはないこともない
正確には商品IDじゃなくて商品コードの付け替えだがな
343 名前：NAME IS NULL mailto:sage [2011/02/22(火) 21:13:38.22 ID:???]: コードの桁数が３桁固定とか決まってる場合はどっかでリセットする仕様な場合はあるね。
ただ３桁のみがキーになることも滅多にないと思うが。
344 名前：NAME IS NULL mailto:sage [2011/02/23(水) 04:06:56.64 ID:???]: DBは初心者です
テーブルA,Bの関連が1:1?または1:N*なテーブルは、相手が存在しない可能性もあるので
1．AとBに主キーを設定し、テーブルCにAとBの関連を入れる
2．Bの主キーをAの外部キーとして持たせ、Aの外部キーにnull値を許容する
のとどちらが良いと思いますか？

また、他のケースについて、今のところ
1:N*の場合は1を選択
1:1の場合と1:N+の場合は2.でnullを許容しない
N*:N*やN*:N+、N+:N+はA,Bどちら側からも検索する可能性があるなら1のみ(にこ動のタグとか)
そうでないなら検索する可能性がある項目を持つ側に外部キーを持たせる設計も検討する
という指針を考えてるのですが、大丈夫でしょうか
速度よりも修正容易性を重視したほうがよさそうな環境なので、基本サロゲートキーを付けてます
345 名前：NAME IS NULL mailto:sage [2011/02/23(水) 05:47:09.64 ID:???]: どういうことだ？
346 名前：NAME IS NULL mailto:sage [2011/02/23(水) 06:29:33.66 ID:???]: >>344
テーブルA,Bの関連が 1..N(Nは0以上) の基本を以下に書くよ。

o テーブルAに主キーを設定し、テーブルBには(テーブルAを参照する)外部キーを設定する。
o テーブルBに主キーが必要か否かは、エンティティA無しにエンティティBが存在しうるか否かで決める。

テーブルBの外部キーとしてNULL値を許容するとか、関連テーブルが必要かとかを検討する必要があるのは、
エンティティAも存在しないこともあるという関連 M:N(M,Nとも0以上) の場合だけだよん。
347 名前：NAME IS NULL mailto:sage [2011/02/23(水) 14:48:31.30 ID:???]: テーブル名やカラム名にマルチバイトの文字って使う？
とんでもなく長いsqlとか書いてるとわけわかんなくなるから、マルチバイト使いたいような気もするし
もしかしたら今後のアップデートとかでマルチバイトが祟ってエラー吐くかもしれないから
あんまりマルチバイトを使いたくないって気持ちもある。

カラム名はシングルバイトでコメントの部分だけにマルチバイトってありかな？
これなら多少ましにはなると思うんだが、中途半端感が否めない。
348 名前：NAME IS NULL mailto:sage [2011/02/23(水) 16:39:26.64 ID:???]: オラクルだと結構日本語テーブル日本語カラム見かける気がする
349 名前：NAME IS NULL mailto:sage [2011/02/23(水) 19:20:11.70 ID:???]: 客先でコンソールでデータとろうとしたときに詰むのが怖すぎる
350 名前：NAME IS NULL mailto:sage [2011/02/23(水) 19:23:18.26 ID:???]: 確かにリモートでつなげないような環境でデータを見る可能性があるならシングルバイトのほうが良さそうだね。
俺んとこはそうゆう事は一切ないから気づかなかった。
351 名前：NAME IS NULL [2011/02/23(水) 19:37:11.95 ID:iyykSQn2]: 以前働いていてたとこ、DB名、テーブル名からカラム名まで全て日本語 w
352 名前：NAME IS NULL mailto:sage [2011/02/23(水) 19:50:08.25 ID:???]: >>351
それで具体的に何が困ったかｋｗｓｋ
353 名前：NAME IS NULL mailto:sage [2011/02/24(木) 02:03:54.85 ID:???]: 最近の自動生成系の機能がついたIDEなんかだと日本語変数名にもつながっていくので
規約で変数名にマルチバイト文字使っちゃダメとかやると面倒くさい。
逆に積極的にマルチバイトを使うように決めてしまえばあるいは。
354 名前：NAME IS NULL mailto:sage [2011/02/24(木) 02:14:58.82 ID:???]: MySQLの公式ツールが落ちるからマルチバイトは使わないなぁ
コメントの日本語だけで詰むｗ

supplier.id ほげ.仕入れid hoge.siireid
こんなDB見た事がある
355 名前：NAME IS NULL mailto:sage [2011/02/24(木) 03:46:34.08 ID:???]: >>354
MySQLってそんなにマルチバイトに弱いの？

一昔前までは、世界的なシェアで見ると、MySQL＞PostgreSQLだが
日本ではMySQL＜PostgreSQLだった。
PostgreSQLに比べてMySQLは、最初のころはマルチバイトに弱いとかで人気が出なかったが
だんだんそのへんが良くなって来てるから、PostgreSQLとトントンくらいのシェアになってるとか
どこかで読んだ気がするんだが。

公式ツールで扱えないんじゃMySQLではマルチバイトでカラム名を付けるなんてことは考えられないなｗ
356 名前：NAME IS NULL mailto:sage [2011/02/24(木) 07:27:19.12 ID:???]: トントンくらいになったが、PostgreSQLの改善速度がかなり早く、MySQLはまた引き離されてしまった印象。
357 名前：NAME IS NULL mailto:sage [2011/02/24(木) 12:17:16.70 ID:???]: >>354
公式っても、GUIツールだろ。
そりゃあしかたない。

他は全然安定してるから問題ない。
あんまり。
358 名前：NAME IS NULL mailto:sage [2011/02/24(木) 12:43:23.84 ID:???]: サポートされてる機能を使っちゃいけないってのもおかしな話だしな
359 名前：NAME IS NULL mailto:sage [2011/02/24(木) 16:58:43.49 ID:???]: >>357
仕方なくないだろ。
あきらかにマルチバイトは軽く扱われてるじゃん。

OracleやSQLServerですら稀に問題が起こるのに
MySQLで問題が起こらないとは到底思えないな。
360 名前：NAME IS NULL mailto:sage [2011/02/24(木) 18:31:35.55 ID:???]: マルチバイトのテーブル名だの、項目名だの欲しがるのは、開発側じゃなくて大抵客。
だから、マルチバイトにしたビューを用意すればいいだけ
361 名前：NAME IS NULL mailto:sage [2011/02/24(木) 22:29:28.02 ID:???]: Oracleだとマルチバイトのカラム名は""で括らないと動かん場合がある
362 名前：NAME IS NULL mailto:sage [2011/02/24(木) 23:14:03.56 ID:???]: >>361
Oracleで""で括ってないって理由で動かないSQLを1度だけ見たことがある。

SQLServerは""で括らなくても問題ないの？
363 名前：NAME IS NULL mailto:sage [2011/02/25(金) 23:38:18.25 ID:???]: >>346
ありがとうございます。

>o テーブルAに主キーを設定し、テーブルBには(テーブルAを参照する)外部キーを設定する。
なるほど、これが一番良さそうです

>o テーブルBに主キーが必要か否かは、エンティティA無しにエンティティBが存在しうるか否かで決める。
主キーについてまだ理解が足りてなかったみたいです
では、DB設計時は1:NやN:Nといった関連と、
単体で存在しうるか、という軸でも整理しておく必要があるってことですね
今作っているテーブルの該当部分は親子関係(子がない場合もあり、子単体は存在しない)なので
親への外部キーのみ設定して、子の主キーは設定しなくても良さそうです
364 名前：NAME IS NULL mailto:sage [2011/02/26(土) 02:25:39.36 ID:???]: >>346, 363

訳が分からない。

> テーブルBに主キーが必要か否かは、エンティティA無しに
> エンティティBが存在しうるか否かで決める

なんでテーブルBに主キーが無くて良いことがあり得るの?

> 親への外部キーのみ設定して、子の主キーは設定しなくても
> 良さそうです

子の主キーも設定する。親への外部キーはNOT NULLで参照する。
そんだけ。あと初心者は気軽にNULL使わない。三値論理を理解して、
その面倒くささを理解してから使うこと。
365 名前：NAME IS NULL mailto:sage [2011/02/26(土) 10:04:45.13 ID:???]: >>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 mailto:sage [2011/02/26(土) 10:16:03.18 ID:???]: >>365
BがAに依存する属性だったとしても、Bに主キーがなければ
その属性を一意に特定することができないってことだろ？
「主キー」の意味するところが違う？
367 名前：NAME IS NULL mailto:sage [2011/02/26(土) 10:56:57.58 ID:???]: >>366
テーブルBの個々の行(ロウ)を一意に特定する必要があるのなら、
そのテーブルBは(属性ではなく)エンティティを表現していることになる。
もしテーブルBでエンティティを表現したいのであれば、当然のことながら
テーブルBに主キーは必要になるよ。
368 名前：NAME IS NULL mailto:sage [2011/02/26(土) 11:18:19.70 ID:???]: 複数存在するのに一意に特定する必要のない属性って、想像しにくいんだが。
それってたとえばどんなもの？
もしかして、BのエンティティキーをAと独立に持つかどうかという話じゃないのか？
369 名前：NAME IS NULL mailto:sage [2011/02/26(土) 12:04:19.62 ID:???]: >>368
想像しにくいというのが理解しがたいのだけれど、要望とあれば。
たとえばエンティティAが楽曲や書籍のような著作物であるとする。
この場合、作者(作曲家/作詞家/著者/原作者/翻訳者..etc)は属性であり、
ある著作物に複数の作者が関わることがあるから、複数の属性になる。
370 名前：NAME IS NULL mailto:sage [2011/02/26(土) 12:23:57.65 ID:???]: いや、問題は「一意に特定する必要がない」ということの方なんだが。
作曲家と作詞家、あるいは作曲家が2人いてもそれらは個々に特定
できなきゃならんのが普通だろ。
主キーを持たないということは、仮に同じ曲に同姓同名の作曲家が
2人いたとして、それを区別する術がないということだ。
371 名前：NAME IS NULL mailto:sage [2011/02/26(土) 12:32:11.67 ID:???]: >>370
>それらは個々に特定できなきゃならんのが普通だろ。

特定する/しないという判断は、与えられた問題(要求仕様)によって変わる。
「普通だろ」というのは設計者の勝手な意図(思いつき)にすぎない。
もしも特定しなくてもいいという問題であるのもかかわらず一意性を作り込んだのなら、
それは過剰な設計(設計ミス)ということになる。
372 名前：371 mailto:sage [2011/02/26(土) 12:35:49.91 ID:???]: >>371を一部訂正する。

X: もしも特定しなくてもいいという問題であるのもかかわらず
O: もしも特定しないという問題であるのもかかわらず
373 名前：NAME IS NULL mailto:sage [2011/02/26(土) 12:40:50.21 ID:???]: 別に本人が必要ないと思ってるんならいいんじゃない？
こんな頭の固いやつにいくら言っても無駄。宗教と同じ
374 名前：NAME IS NULL mailto:sage [2011/02/26(土) 12:48:42.38 ID:???]: あらゆるテーブルには主キーが存在しなければならないという考え方が、「頭の固い」発想だと思う。
どちらにせよ、人格攻撃に走ることしかできないのなら、漏れは議論から降りるよ。
375 名前：NAME IS NULL mailto:sage [2011/02/26(土) 12:53:18.72 ID:???]: だからさ、そんなもの見たことがないからどんな例があるか聞いてみたんだが？
RDBでは主キーがないテーブルも許されるが、設計論としてはリレーショナル
モデルにおいて主キーがないなんてことはありえないし。
376 名前：NAME IS NULL mailto:sage [2011/02/26(土) 13:02:13.25 ID:???]: >>371
ん？しかし>>346では「エンティティA無しにエンティティBが存在しうるか否かで決める」と言っているが？
377 名前：NAME IS NULL mailto:sage [2011/02/26(土) 18:27:05.81 ID:???]: あまり読んでないけど、
AなしにBが存在し得ない状況では外部キーが主キーと同じ意味を成すといいたいのかな。
そんなことないけど。
378 名前：NAME IS NULL mailto:sage [2011/02/26(土) 19:18:11.77 ID:???]: >>375
>だからさ、そんなもの見たことがないからどんな例があるか聞いてみたんだが？

重複を許す(=一意性を保証しない)属性テーブルというのは、普通に存在するよ。
なるべく分かりやすい例を挙げたつもりだし、重複の可否(=一意性の保証/無保証)を決めるのは、
DB設計者ではなく与えられた問題(要求仕様、つまり顧客)であることも書いた。
ここまで説明してもなお、自分は見たことが無い/経験した事が無いので想像がつかないと
言われたら、自分としてはショボーンとするしかない。

>RDBでは主キーがないテーブルも許されるが、設計論としてはリレーショナル
>モデルにおいて主キーがないなんてことはありえないし。

まず、関係論理/関係代数の世界においては、タプルに一意性が存在することを仮定しているから、
タプルの重複はありえない。ただし、残念ながらリレーショナルモデルというのは、
タプルの重複を許す多重集合(マルチセットまたはバッグ)なんだ。だからタプルの重複はありえるし、
従って一意性は必ずしも保証されない。必要であれば明示的な一意性制約の宣言が必要になる。

次に、RDB実装における主キー(プライマリキー)と、リレーショナルモデルにおける主キー
(行の一意性を保証する候補キーの集合)とを混同して理解しているように見える。
379 名前：NAME IS NULL mailto:sage [2011/02/26(土) 19:24:09.00 ID:???]: （>>378の続き）

たとえば>>365の(2)でテーブルBに一意性が必要であるならば、設定した外部キーと候補キー
(例えば作者名カラム)との組(くみ, タプル)に対してUNIQUE制約を設定するのが正しいDB設計。
この場合、外部キーと候補キーの組を「主キーとみなす」。(「主キーを設定する」とは言わない。)

>>364のようにテーブルBへ主キー(プライマリキー)を設定した場合には、RDB実装における
テーブルの一意性は保証されても、リレーショナルモデルにおける一意性(作者名の非重複保証)は
実現できないから、誤ったDB設計であると思う。
380 名前：378 mailto:sage [2011/02/26(土) 20:12:53.64 ID:???]: >>326,327
個別にはレスしないが、二人とも「単体での存在性(エンティティなのか？属性なのか？)」と
「主キーの有無(タブルの一意性を保証するのか？しないのか？)」を混同してるように見える。
381 名前：378 mailto:sage [2011/02/26(土) 20:15:43.69 ID:???]: アンカをミスった。

>>326,327は間違いだ。>>376,377に訂正する。
382 名前：NAME IS NULL mailto:sage [2011/02/26(土) 20:18:00.38 ID:???]: >>378
そういう一般論を言ったら、Aに関係なくBが存在する場合だって
必ずしも主キーは必要ないってなるんじゃね？
383 名前：NAME IS NULL mailto:sage [2011/02/26(土) 20:25:44.02 ID:???]: >>380
それを混同したのが>>346だと思うんだが。
384 名前：378 mailto:sage [2011/02/26(土) 20:36:57.54 ID:???]: >>382
それでも良いと思う。どこに(普通か普通じゃないかという)境界線を引くか、という話になるね。

>>383
えーと、>>346で書いた「主キーを設定する」という表現は、すべてDB実装における
主キー(プライマリーキー)のことだよ。それが読み取れないということは、やっぱり混同してるんだね。
385 名前：NAME IS NULL mailto:sage [2011/02/26(土) 20:54:52.06 ID:???]: つまり「主キー」という言葉には2種類の意味があって、自分が意図していたのは
違う方の意味だとｗ
>>379では「設定する」と「みなす」なんて言い換えまでしてご苦労なこったな。
386 名前：NAME IS NULL mailto:sage [2011/02/26(土) 21:41:24.92 ID:???]: 小難しい表現の割にはどうでもいい話だったな
387 名前：378 mailto:sage [2011/02/26(土) 21:44:24.81 ID:???]: >>385
えーと、困ったな。言葉の「使い分け」はしてるけど、「言い換え」はしていないつもりだよ。
「言い換え」とは、同じ事柄を別の方法で表現するという意味だよね。

>>346のテーブルAは、RDB実装における主キー(プライマリキー)とリレーショナルモデルにおける
主キー(一意性)が一致しているから「主キーを設定する」という表現をしても誤解されることはない。
それに対して、>>379のテーブルBはリレーショナルモデルにおける主キー(一意性)は存在しているけど
RDB実装における主キー(プライマリキー)は存在しないから、誤解の無いように「主キーとみなす」と
表現方法を「使い分けた」。

日本語って難しいね。
388 名前：378 mailto:sage [2011/02/26(土) 21:55:30.25 ID:???]: >>386

>>379では、「>>363のDB設計は誤りであり>>379が正しいDB設計である」と
言い切っちまっているんだけど、これはそのまま放置しといていいのかな？
それとも、これすら「どうでもいい話」なのかな？

「いいや、....だから>>364が正しい」とか「自分ならこうする」というような
反論/異論を期待してたんだけど....。
389 名前：NAME IS NULL mailto:sage [2011/02/26(土) 22:09:32.49 ID:???]: 彼の言う「主キー」と、「主キーを設定する」という用語は
一般的なSEやプログラマがRDBMS上でのテーブル設計をする際のそれと
意味合いが違うってことです

一般的なRDBMS上のテーブル設計では、そのテーブルの行を個別に識別できる項目（の組み合わせ）を
システム的に指定することを主キーを設定するといい、その指定された項目を主キーと呼びます
そういう意味では、行を識別必要があるする全てのテーブルにおいて、主キーを設定することが推奨されます
つまり、全てのテーブルに主キーがあるべきであると言う主張が成り立つわけです
390 名前：NAME IS NULL mailto:sage [2011/02/26(土) 22:11:18.60 ID:???]: もうどうでもいい。
Ｔ字形の論理編ぐらい、どうでもいい。
391 名前：378 mailto:sage [2011/02/26(土) 22:14:41.27 ID:???]: いけね、また間違えた。

X:「>>363のDB設計は誤りであり
O:「>>364のDB設計は誤りであり
392 名前：NAME IS NULL mailto:sage [2011/02/26(土) 22:19:21.49 ID:???]: もともと「設定する」と「みなす」を別の意味で使っていたのなら、>>346のテーブルAも
「設定する」と「みなす」場合両方があるわけだろ？
それを誤解がないからと勝手に片方だけ書いたら逆に誤解するわ。

じゃあ聞くけど、もう一度言葉の定義を明確にして>>346を正しく書き直したらどうなるの？
393 名前：386 mailto:sage [2011/02/26(土) 22:48:50.20 ID:???]: >>388
たとえば伝票と明細のケースでいえば
明細テーブルでは行を一意に識別する主キーはいらないってのがお前の立場なんだろ？

それで要件満たせるんなら別に問題ないと思うけど、
普通は明細の各行単位で修正入れたいケースとか必ず出てくるから、
現時点で必要ないように見えても必ず主キーは設定するように俺はする。
それがサロゲートキーなのか複合キーなのかは別にどっちでもいい。

ただ、現時点での要件を満たせるんなら後で修正すればいいだけだから、
別にお前のやり方でも俺はかまわない。
お前みたいなやつを説得するのは経験的に難しいとわかってるから、
機能的に不具合が出ないんなら議論なんかせずに迎合する。

要するにどっちでもいいし、どうでもいい。
394 名前：NAME IS NULL mailto:sage [2011/02/26(土) 23:01:47.25 ID:???]: >>387
モデルの一意性は存在してるけど実装のプライマリーキーが存在しない状態ってなんだよそれ。
つか、そもそも設計段階でそんなもん考慮するのか？
395 名前：378 mailto:sage [2011/02/26(土) 23:28:17.16 ID:???]: >>389
つまり、一般的なSE/PGのRDB設計とは>>375が言うところの設計論としての
リレーショナルモデルとは意味合いが違うってことなんだな。
だから、>>379のような「主キーとみなす」という表現は普通じゃないってことか。
うん、よく分かった。これからは注意しよう。

ところで、>>364では

>子の主キーも設定する。親への外部キーはNOT NULLで参照する。そんだけ。

とあるのだけれど、この「主キーも設定する」という表現は、自分は
単純に「プライマリキーを設定する」という意味であると(勘違いして)解釈しました。
でも、これは>>389によれば「適切な候補キー(たとえば作者名カラム)と外部キーとの
組合せに対し個別に指定できるよう主キーとして(UNIQUE制約を)システム的に指定する」と
解釈すべきなのかな？

分かっている人には当たり前なのかもしれないけど、>>344,363のような初心者に対して
「主キーも設定する」という短い一文からそのような推測を期待するのは、
ヒジョーに厳しすぎるんじゃないかと思うんですが、いかがですか？（自分も勘違いしたし....。）
いや、それすら「一般的なSE/PGのRDB設計」なら普通なのかな？
396 名前：378 mailto:sage [2011/02/26(土) 23:29:45.71 ID:???]: >>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 mailto:sage [2011/02/27(日) 00:12:42.89 ID:???]: >>393
いいや、その伝票と明細のケースで言えば、明細テーブルの各行は普通にエンティティだと思う。
だからリレーショナルモデルにおける主キー(一意性)は存在するよ。ただし、RDB実装における
主キー(プライマリキー)は設定せず、(明細テーブルを参照する)外部キーと候補キーとなる
行番号カラムとの組(から成る複合キー)をリレーショナルモデルにおける主キーとみなすという
違いはあるかもしれないけどね。

このケースで属性となるのは、ある行を構成する各桁の値だ。ここで、(>>365で書いたように)
行エンティティがその値を「ただ一つだけ(only one)」持つのなら、その値は行エンティティの
カラム(フィールド)として表現する。ここまでは問題無いと思う。意見が分かれるのはこの先だ。

もしも行エンティティがその値を「いくつか持つ(zero or more)」のなら、その値は
属性テーブルとして表現するものとし、属性テーブルには(行テーブルを参照する)外部キーのみを
設定し、プライマリキーは設定しない。更に、もしも与えられた問題下でその値に一意性が
必要であるのなら(=必要な場合に限り)、外部キーと値の組を主キーとみなしてUNIQUE制約を設定する。

具体的な例を挙げれば、値引きオプション、つまり「論理値の集合」で値を表現するケースになる。
ある行が商品を表現するとして、その商品に対する様々な値引き(優待顧客値引き/個別値引き...etc)を
0個以上の任意の組合せで表現することになるだろう。

この場合、>>393であれば、どのようにDB設計をしますか？やっぱり値引きテーブルにも
プライマリキーを設定するのかな。もちろんそれでも(AP開発に苦労はしても)要求仕様を
満たせるだろうから、どっちでもいいし、どうでもいいんだけどね。
398 名前：NAME IS NULL mailto:sage [2011/02/27(日) 00:15:40.50 ID:???]: >>396
ふむ。「設定」が>>389の意味だとするならば、言っていることはだいたいわかる。
＃本当は「存在しうる」とか「エンティティ」と「属性」の違いなんかは明確ではないが、
＃ここではそれを措いても特に問題ない。

その上で反論だ。
(1)1:Nならば無条件でBに外部キーを設定することになっているが、こここそ、Bが
Aから独立して存在するかどうかで変わる部分だろう？そうでなきゃ、対応するAの
レコードが存在するBの外部キーはNULLになってしまう。
(2)一意性が必要かどうかは要件で決定されるって自分で書いていなかったか？
自分は必要ないケースはめったにないと思っているが、どちらにしても、エンティティ
ABの関係とは関係がない。
(3)ここは言葉の問題。候補キーは(1)の外部キーを含む場合と含まない場合が
あるが、どちらにしてもそのまま主キーになり得る。だから、外部キーを含まない
候補キーとの複合キーなどというものは考えなくていい。
399 名前：389 mailto:sage [2011/02/27(日) 00:22:38.04 ID:???]: >>395
>「主キーも設定する」という短い一文からそのような推測を期待するのは、
>ヒジョーに厳しすぎるんじゃないかと

「一般的なSE/PGのRDB設計」ならそう思うのが普通だと思うが
純粋な設計と言うよりは、実装方法論だがな
だからあえてRDB設計とかいう言葉じゃなくて、RDBMS上のテーブル設計って言葉をつかったんだ
400 名前：NAME IS NULL mailto:sage [2011/02/27(日) 01:01:50.65 ID:???]: >>397
なんか例がおかしくない？優待値引きとか個別値引きとかあるのになんで論理値なの？

それはそれとして、値引きテーブルに一意性が必要ない(=同じ値引きが複数存在してもよい)
と言うことであればそれはそれでありだと思うが、特定の値引きを削除するとか変更するなんて
要件があった場合は一意性が必要となる。
一方で、ここに1商品1レコードの在庫テーブルがあったとする。これはここで言う「属性」には
当たらないと思うが、一意性の要否については上の値引きテーブルと変わらない。
つまり、一意性の要否を判断する上で「エンティティ」か「属性」かは関係ない。
401 名前：378 mailto:sage [2011/02/27(日) 01:49:22.13 ID:???]: >>398

(1) AとBが 1:N の関係であるなら、N側であるBから見ると1側であるAは必ず「ただ一つだけ(only one)」
　存在しているはずだと思います。だから、Bの外部キーがNULLになるケースが想像できないのですが？

(2) まず(2)では(一意性ではなく)存在性について述べているので、自分には論旨が不明です。
　ただし一意性については指摘のとおり、(存在性と同様に)その必要性を決めるのは要件(要求仕様)です。
　この点については、>>396への追加記述が漏れていました。

(3) この候補キーというのは、>>364の「子の主キーも設定する」というところのプライマリキーを
　指しているのですか？もしそうであり、なおかつプライマリキーが人工キーである、
　たとえば hoge_id のようにデータ型が自動インクリメントされる整数(つまり)であるなら、
　自動的に一意性は保証されるから複合キーは考えなくていいでしょう。
　自分は(なるべく)人工キーは作らず複合キーで実装する立場ですが、それはまた別の話です。
402 名前：386 mailto:sage [2011/02/27(日) 02:16:30.65 ID:???]: >>397
値引きオプションだって修正や削除の必要が発生する可能性はあるから、
当然主キーつけるに決まってるよ。
そもそも実務的には値引き伝票切るケースが多いけどな。

その例えはお前の主張したいことからして全く適切じゃない。
もっとちゃんとした例を出せ。

> プライマリキーを設定するのかな。もちろんそれでも(AP開発に苦労はしても)要求仕様を
> 満たせるだろうから、どっちでもいいし、どうでもいいんだけどね。

お前、いつの時代の人間なの？
最近のアプリケーションフレームワークなら、むしろプライマリキーをつけないほうが
特殊な処理過ぎて苦労するだろうが。
403 名前：NAME IS NULL mailto:sage [2011/02/27(日) 03:53:37.69 ID:???]: 軽い実例を出してくれたほうが伝わりやすいことは業務をやってればわかることだと思うんだけど、
いつまで文字でがんばるのか。
404 名前：NAME IS NULL mailto:sage [2011/02/27(日) 07:35:09.08 ID:???]: >>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 mailto:sage [2011/02/27(日) 10:13:02.26 ID:???]: うざいから、ER図付きでやってくれ
406 名前：NAME IS NULL mailto:sage [2011/02/27(日) 10:17:07.66 ID:???]: もともとの話は>>346に対する>>364の反論から始まってるんでしょ？

例えばブログの記事にタグ付けするような場合、
記事テーブル（記事IDがPRIMARY KEY）と
タグテーブル（記事IDがFOREIGN KEY）を作るとして、
364氏はタグテーブルでは何をPRIMARY KEYにするんだろう？

「子の主キーも設定する。親への外部キーはNOT NULLで参照する。」
と言っているからサロゲートキーを作るって話なんだろうな。

それだけの話だった（ように見える）のに、
以降の議論はただ話を難しくしてるだけのような。
407 名前：NAME IS NULL mailto:sage [2011/02/27(日) 11:23:29.66 ID:???]: なぜサロゲート？タグテーブルには候補キーが存在しない前提なの？
408 名前：406 mailto:sage [2011/02/27(日) 11:37:17.75 ID:???]: どういう候補キーがあると思う？

記事IDとタグの組み合わせを主キーにするってのは考えられるけど
それだと「親への外部キーはNOT NULLで参照する」っていうのを
わざわざ書く必要がない。（主キーなら必ずNOT NULLだから。）

わざわざ書いてるってことは364氏の言ってる主キーには
外部キーを含んでないっていう前提があるんでしょ？
（あくまで推測ね。俺は364氏じゃないから。）
409 名前：NAME IS NULL mailto:sage [2011/02/27(日) 13:07:55.88 ID:???]: >>364の真意は知らんが、「主キーに外部キーを含めない」と限定していたようには
俺には読めなかったな。含んでいようがいまいがNOT NULLということだろ？

1. わざわざNOT NULLと書いたから主キーには含まないんだろう
2. だとすると候補キーもないんだろう
3. じゃあ何をPRIMARY KEYにするんだろう？
4. たぶんサロゲートキーを作るんだな

3.の疑問を持った時点で自分の推測を疑えよって話だな。
410 名前：406 mailto:sage [2011/02/27(日) 13:22:03.68 ID:???]: うん、まあ、そうかもしれんしそうじゃないかもしれん。
どっちにしろ、364氏の真意が分からんことには議論はできないよね。
411 名前：NAME IS NULL mailto:sage [2011/02/28(月) 15:56:49.49 ID:???]: 364だけど、

>>406
「タグテーブル」が記事に対するタグ付けを表す(記事ID, タグID)、かつ
タグの順序に意味はないとして、同じタグを同じ記事に複数回付けられ
ないのであれば(普通の仕様だと思う)主キーは(記事ID, タグID)。
「[これはすごい][これはすごい][これはすごい]...」みたいに、同じ記事
に同一タグを複数回認める酔狂な仕様なのであればサロゲートキーも
必要。

後者は純粋に関係モデル的にはそもそもこのようなキーがないとデータ
を表現出来ない(setだから)。SQL的にはsetではなくbagだから無くても
表現できるけど、大抵は無いと更新時に填る。

>「子の主キーも設定する。親への外部キーはNOT NULLで参照する。」
>と言っているからサロゲートキーを作るって話なんだろうな。

いや全然。そんな話じゃない。
外部キー参照は仮に主キーを参照していてもNULLは入れられる。
「子単体は存在しない」、すなわち必ず親を持つのであれば明示的に
NOT NULLは宣言する必要がある。

>>409
>含んでいようがいまいがNOT NULLということだろ？

正解。
412 名前：NAME IS NULL mailto:sage [2011/02/28(月) 16:15:31.13 ID:???]: もひとつ、>>346に聞きたいのは、>>346のルールとか、そのあと
改正した>>396のルールとか、これ教科書か何かに書かれたものなの?
であれば参考までにリファレンスを示してくれると嬉しい。
413 名前：406 mailto:sage [2011/02/28(月) 18:47:49.98 ID:???]: つまり、>>364の
「子の主キーも設定する。親への外部キーはNOT NULLで参照する。」
は以下の意味だってことだろうから、俺は特に異論はない。

「子の主キーも設定する。
　ただし、要件によってはサロゲートキーとすることもあり得る。
　親への外部キーはNOT NULLで参照する。
　ただし、子の主キーが親への外部キーを含む複合キーである場合は、
　明示的にNOT NULLを指定する必要はない。」

346氏（=378氏？）は、単にサロゲートキー否定派なんじゃない？
414 名前：NAME IS NULL mailto:sage [2011/02/28(月) 19:49:10.77 ID:???]: >>413
そゆこと。ただし以下の下りはちょびっと。

>ただし、子の主キーが親への外部キーを含む複合キーである場合は、
>明示的にNOT NULLを指定する必要はない。

必要ないし意味的にはダブるかもしれないけど、それでも明示的に
指定するかな。ごくごく個人的には、単に作法として。
テーブル定義を読んでも、parent_id *** NOT NULLと直接書いて
あった方がparent_idの取り得る値の制限としては解りやすいし。

>346氏（=378氏？）は、単にサロゲートキー否定派なんじゃない？
よくわからんす。自然キーでも人工キーでも、必要な場面で正しく
使えばどっちでもよいです。
415 名前：NAME IS NULL mailto:sage [2011/03/01(火) 00:15:51.62 ID:???]: 「弱実体」でググると>>346が言いたかったことと、どこが間違っていたかがわかるかも。
416 名前：NAME IS NULL mailto:sage [2011/03/01(火) 01:34:29.60 ID:???]: >>396
> (2) もし存在しえないのなら、テーブルBは(エンティティではなく)属性を
>　　表現することになるから、テーブルBへのプライマリキーの設定は不要

逆にエンティティA無しにエンティティBが存在しうるとすればどう
するの? プライマリーキー定義するの? どう決めるの?

> (3) 候補キー(たとえば作者カラム)
それは部分キーだ。候補キーじゃない。他のレスでも間違っている。
言葉遣いの問題だが、関係モデルの超基本だ。

> (3) その複合キーに対してUNIQUE制約を設定する。
なんでUNIQUE制約? PRIMARY KEY制約だとダメなのか? だってその
「複合キー」はテーブルB中の行を一意に選択出来るんでしょ? 主キー
の資格十分じゃん。
素のUNIQUE制約はNULL許可するけど、それでも良いの?
417 名前：NAME IS NULL mailto:sage [2011/03/01(火) 01:43:38.21 ID:???]: >>397

> 具体的な例を挙げれば、値引きオプション、つまり「論理値の集合」で値を
> 表現するケースになる。ある行が商品を表現するとして、その商品に対する
> 様々な値引き(優待顧客値引き/個別値引き...etc)を 0個以上の任意の組合せで
> 表現することになるだろう。

関係従属性(商品, 値引きオプション) -> 適用可能[true or false]が存在。
なので値引きテーブルは(商品ID, 値引きオプションID, 適用可能)。
主キーは(商品ID, 値引きオプションID), 商品ID・値引きオプションIDに
外部キー制約。ちなみにBCNF。完璧じゃん。

主キーつけるのに何を悩む必要があるのか、それが解らない。
418 名前：NAME IS NULL mailto:sage [2011/03/01(火) 02:10:41.89 ID:???]: >>378氏は一生懸命頑張って主キーがいるいらないの説明しているけど、
まず純粋にスキーマ設計の立場からいうと各テーブルの候補キーを特定
しておくことはマストだよね。でないと正規化が出来ん。

次に正規化が完了した関係スキーマをSQLで実装するときには候補キーに
対応する属性やその組に適切な制約をつけておくことは作法だよね。
でないとデータの整合性をアプリケーションレベルで保証する必要がある。

次に、それでも更新時のパフォーマンスの問題などで制約を外したい事は
無いわけじゃないよね。でも基本的にキーに対する制約を外すとテーブル
中の各行をアトミックに更新出来ることをDB側で保証できなくなる。
なのでその部分はアプリ側で制約するとか、更新の対象や単位を詳細に
見極めて判断したりする必要がある。

ましてや>>344は初心者だといっているのだから、教科書通りER図など
から主キーも含めたテーブル定義を導出する方法で良いじゃないか。
419 名前：NAME IS NULL mailto:sage [2011/03/01(火) 03:10:14.37 ID:???]: みんな教科書通りにやろうとしてるぜ
みてる教科書の分野が微妙に違うんだがな
420 名前：NAME IS NULL mailto:sage [2011/03/01(火) 04:11:06.16 ID:???]: >>417
関係従属性 -> 関数従属性。
関係モデルの超基本だ・・・釣ってくる・・・
421 名前：デフォルトの名無しさん [2011/03/04(金) 00:09:48.83 ID:nwTUgCQG]: 話をサロゲートキーの話題に戻すが、

①商品マスタの商品コードが変わったときの話だが、
　サロゲートキーにしておけば、コードの付け替えが楽。

②トランザクションにてその時点のマスタ値を保障する方が安全
つまりトランザクションには、商品ＩＤ、商品コード、商品名等を
すべて保持する。

①と②は明らかに同時に成り立たないわけだが、
この矛盾はみんなどうしてる？

あと、階層関係があるマスタ、たとえば事業部マスタと部門マスタで
事業部と部門の紐付けが変更されうる。部門の名称変更がある等の理由で、
適用期間をおのおの持った場合、サロゲートキー（事業部ＩＤ）
だけでリレーションさせると、事業部マスタの世代が増えたタイミングで、
リレーションが破綻するわけだが、どうしたらいいんだろ。
422 名前：NAME IS NULL mailto:sage [2011/03/04(金) 00:38:25.10 ID:???]: > ①と②は明らかに同時に成り立たないわけだが、
> この矛盾はみんなどうしてる？

矛盾なんかしてません。
馬鹿じゃないの？

> 適用期間をおのおの持った場合、サロゲートキー（事業部ＩＤ）
> だけでリレーションさせると、事業部マスタの世代が増えたタイミングで、
> リレーションが破綻するわけだが、どうしたらいいんだろ。

どういうシチュエーションでどういう設計をしたら破綻するのか
全然イメージがわきません。
多分サロゲートキーじゃなくてお前の頭が悪いんだと思うよ。
423 名前：NAME IS NULL mailto:sage [2011/03/04(金) 00:55:03.15 ID:???]: >>421
サロゲートキーの使い回しをせず、商品コードの書き換えもマスタ
への追記で対応すれば(2)は本来不要なんじゃないのかな。
424 名前：NAME IS NULL mailto:sage [2011/03/04(金) 01:36:28.45 ID:???]: まず、この例で言うなら、商品コードが変わった場合
過去に登録されたトランザクションデータをどうしたいかを考えろよ

過去データを塗り変えたいなら１が便利
過去データはそのまま保持したいなら２が便利

それだけの話だろ
違う要件に対する解決案をならべて同時に成り立たないって当然だろ
425 名前：NAME IS NULL mailto:sage [2011/03/04(金) 01:39:40.34 ID:???]: 履歴とリアルタイムデータの区別が付いてないっぽいな
426 名前：NAME IS NULL mailto:sage [2011/03/04(金) 01:57:35.75 ID:???]: >>424
2にしてもトランザクションデータに追記する際に商品コードとか
商品名などを商品マスタの内容からコピペしているのであれば結局
1で対応出来るのだが。

商品マスタは基本追記で、最新フラグとか削除フラグとか付けて
古い商品レコードも全て保持するのは案外一般的だと思うけど。
427 名前：NAME IS NULL mailto:sage [2011/03/04(金) 20:05:10.85 ID:???]: サロゲートキーでよくわからないところがあるんだが
本来pkになるはずだった項目の制約はどうすんの？
前に張られたこのURLの例では、制約について一切触れてないから、そんな制約張りませんってことなのか・・・？
gihyo.jp/dev/serial/01/sql_academy2/000304
428 名前：NAME IS NULL mailto:sage [2011/03/04(金) 20:14:23.32 ID:???]: 制約つければよくね。
429 名前：NAME IS NULL mailto:sage [2011/03/04(金) 20:25:51.61 ID:???]: NOT NULLとUNIQUEでいいじゃん
430 名前：NAME IS NULL mailto:sage [2011/03/04(金) 20:28:03.50 ID:???]: >>428
もともとpkにする予定だった項目には、例外なくuniqueを張りたいんだけど
>>427の例ならどうするべきですか？
431 名前：NAME IS NULL mailto:sage [2011/03/04(金) 20:35:13.01 ID:???]: >>427
場合によるとしか言いようがない。
挙げられた例だともともと主キーだったitem_noにUNIQUE制約とか
は付けられないよね。同じitem_noを使い回すので。

沢山の属性を組み合わせた複合キーをシンプルなサロゲートキーで
置き換えるような場合は、主キーこそサロゲートキーにしたとはいえ
元々の複合キーも未だに候補キー、つまりキーに含まれる属性値の
組み合わせはユニークなはずなので、UNIQUE制約を付けた方が良い。
432 名前：NAME IS NULL mailto:sage [2011/03/04(金) 20:36:53.99 ID:???]: >>430
item_no（商品ID）とitem_name（商品名）の組み合わせに対して
UNIQUEだろうね
しかし>>427の例って商品ID自体が自然キーじゃないよな
433 名前：NAME IS NULL mailto:sage [2011/03/04(金) 20:55:19.98 ID:???]: >>427のように、同じitem_noを使い回すのであればテーブルには更に
最新フラグとか削除フラグをつけることが多いと思う。
[id(サロゲートキー), item_no, item_name, deleted]みたいな感じで。

で、上記の例の場合は削除フラグdeletedがfalse、つまり現在有効な
行の中でitem_noのダブりがあると困るわけなのだけど、この制約を
書くのはちょっと面倒くさい。フラグ値を工夫するとか一般制約を
使うとかすれば書けるけど。
実際はアプリケーションレベルでタブりを事前確認するロジックを
書くことが多いんじゃないのかな。
434 名前：NAME IS NULL mailto:sage [2011/03/04(金) 21:06:10.73 ID:???]: >>431
＞つまりキーに含まれる属性値の組み合わせはユニークなはずなので、UNIQUE制約を付けた方が良い。
この部分がよくわからないんですが、もうちょっとスキルが低い人にもわかるようにお願いできませんか？

>>432
名称もunique制約に含めるって、普通に行われることですか？
見たことが無いのでちょっと抵抗があるんですが。
それから、>>427の例の商品NOは、人口キーのようなどうでもいい文字列ってわけじゃなく
お客さんのなんらかの都合により使いまわされる事がある、お客さんも把握してる文字列なわけですから
自然キーの典型的な例だと思うんですが、違うんでしょうか？

>>433
変なデータができあがっちゃうとまずいんで
私が見たことのあるDBでは2重に重複チェックしてました。
具体的には、プログラム側でマスタを更新するまえにDBに問い合わせてチェック→重複してるようならweb画面にエラーを出す
プログラム側のチェックを通ったあとも、unique制約により、DB側でチェックが行われ、これも通れば更新されるといった仕組みでした。

おそらく削除フラグを付けたほうがいいというのは、期間でなくフラグを参照することで
select文を発行するときの負荷が減るというのが目的ですよね？
重複チェックはなかなかミスが出るようなところじゃないから、アプリ側できっちりやれってことでしょうか？
435 名前：NAME IS NULL mailto:sage [2011/03/04(金) 21:30:12.87 ID:???]: >>434
プライマリキーのカラム数が5個ぐらいあって、Joinがしんどくてしんどくてしょうがないという理由から
ただの連番のカラムを作って、それをキーとするようにしてみた
という状態であれば、もともとの5カラムにユニーク制約つけたままで問題ないよ
436 名前：NAME IS NULL mailto:sage [2011/03/04(金) 21:32:21.28 ID:???]: >>432
それがUNIQUEになるなんてただの思いこみなんじゃないかって思う
437 名前：NAME IS NULL mailto:sage [2011/03/04(金) 21:35:44.50 ID:???]: >>435
すごくわかりやすい、ありがとう。
効果は開発効率のアップと、select文のコストが少し減るって感じかな？

その目的でサロゲートキーを使う場合
全てのテーブルにサロゲートキーを追加するんじゃなくて
pkの項目が多くなりそうなテーブルにだけ追加するのが良さそうですね。
サロゲートキーを使用するテーブルの場合、例外なく最初の列に「PK_テーブル名」というカラムを作り
それをサロゲートキーにするというルールで設計すれば、アプリチームの混乱も防げて良さそうですね。
438 名前：NAME IS NULL mailto:sage [2011/03/04(金) 21:41:20.76 ID:???]: >>434
例えば月給テーブル(社員ID, 年, 月, 給料)を考えてみる。
主キーは(社員ID, 年, 月)ね。

で、理由はともあれ誰かさんが属性3つの複合キーなんて非効率的だ!
サロゲートキーにしろ! と叫んだとする。で、サロゲートキーSIDを追加して
月給テーブル(SID, 社員ID, 年, 月, 給料)、主キーSIDにしましたと。

で、このテーブルをよく見てみると、確かにSIDはキーですが、元々の主キー
(社員ID, 年, 月)もテーブル内の行を一意に特定出来るキーなんですね。
というか一意に特定出来ないと困る。でないと同じ社員が同じ年・月に複数回
給料もらえちゃいます。

関係モデルでは一つのテーブルが複数の「候補キー」を持つことがあります。
この場合はSIDと(社員ID, 年, 月)の二つの候補キーがあります。
その中から「主キー」を一つだけ選ぶわけですが、だからといって残った他の
候補キーがキーでなくなるわけではありません。それらも引き続いてキーです。
なので上記の例だと候補キー(社員ID, 年, 月)にUNIQUE制約を付けておく
必要があります。
439 名前：NAME IS NULL mailto:sage [2011/03/04(金) 22:00:25.24 ID:???]: >>434
>おそらく削除フラグを付けたほうがいいというのは、期間でなく
>フラグを参照することでselect文を発行するときの負荷が減ると
>いうのが目的ですよね？

例えばサロゲートキーを使った商品マスタテーブルを使って実際に
トランザクションデータを書き込むとき、伝票に書かれた商品IDから
サロゲートキーを逆引きする必要があります。
しかし>>427のテーブルの場合、商品ID001からサロゲートキーを
逆引きすると二つサロゲートキーの値が出てきます。これはで困る。
なのでフラグを付けて現在も有効なレコードだけから検索するように
する必要があります。
もちろん特別にフラグを設けずに、例えば有効期間を表す列に「現在も
有効」を表す特別な値(>>427の例だと"9999")が仕様として定義されて
いる場合はこれを使って絞り込んでもよいわけです。

ただこの手の終了フラグを使った場合、商品IDのタブりを防ぐ制約は
やや凝った記述になりがちで、となると現状PRIMARY KEYなど基本
どころ除けばDBMS毎に書ける制約の表現力がバラバラなのが難しい。
MySQLなんてCheck制約は書けてもガン無視するとか、そんな仕様。
なんでアプリ側でチェックするロジックを書くことも多い気がします。
440 名前：NAME IS NULL mailto:sage [2011/03/04(金) 22:26:37.03 ID:???]: >>438
丁寧な説明ありがとう。
この板はIDが無いみたいなんで、どのレスをした人がどのレスを返してくれてるのかわからないけど
>>435と>>438は同じ事ですよね？

>>439
MySQLでcheck制約がきかないのは初めて知りました・・・なんと恐ろしい。
>>427の場合は、トランザクションテーブルに書き込む商品の情報は
商品IDじゃなくてsrg_key（サロゲートキー）じゃないですか？

>>427の例の仕様ではこうなってるはず
・マスタのpkはサロゲートキーを使用する。
・トランザクションテーブルの外部参照をする列に格納するキーは、参照先のサロゲートキーを入れる。
・過去に入力された名称は、その時点で入力された名称をマスタから取得する。
・unique制約は付けない。

サロゲートキーの一つの利点である、pkに指定する項目が1つになるという部分は理解できました。
どこのページを見てもあんまり紹介されてませんが
unique制約が付けづらいというのはサロゲートキーのデメリットとして覚えておいた方が良さそうですね。
441 名前：デフォルトの名無しさん mailto:sage [2011/03/04(金) 22:32:56.51 ID:???]: 商品IDがダブらないなら本質的にサロゲートキーは不要かと…
やばいのは商品IDというか商品コードがメーカーによって使いまわされて、
ある製造日より別商品に割り当てられたが、
販売店の在庫管理としては商品コードと入荷日でしか
管理していなかったため、同一商品コードの違う製品が混在してしまって
何を販売したのか管理できず混乱するなどですよね。
442 名前：NAME IS NULL mailto:sage [2011/03/04(金) 22:45:47.53 ID:???]: >>441
得意先のマスタなんかは在庫とかって概念がないからどうゆうふうに設計してもなんとかなりそうなもんだけど
商品に関しては商品IDを使いまわす可能性があるならサロゲートキーは必須になるのか
443 名前：NAME IS NULL mailto:sage [2011/03/04(金) 22:50:32.51 ID:???]: すごーーーーく根本的な話になるんだけど
商品IDの使い回しを行いたい時ってどうゆう時？

得意先や部署はわかる。
合併やら統合やらあるもんね。
商品IDはわからん。
444 名前：デフォルトの名無しさん mailto:sage [2011/03/04(金) 23:00:00.52 ID:???]: 桁数だろう？
どれだけ必要になるかわからないからって
たとえば２０桁のコード体系をあらかじめ用意するのかってこと。
覚えられん…
445 名前：NAME IS NULL mailto:sage [2011/03/04(金) 23:10:09.40 ID:???]: >>443
古いシステムならコードのMAXが5桁とか普通に有り得るだろう。
446 名前：NAME IS NULL mailto:sage [2011/03/04(金) 23:18:26.31 ID:???]: えー・・・
447 名前：NAME IS NULL mailto:sage [2011/03/05(土) 00:12:24.71 ID:???]: くるくる回る商品IDなんてよくある。
ある時点においてユニークであれば、それで現場は回っていくんだよ。
なもんで、こっちとしてはサロゲートキーを作って、商品IDガン無視する。

たとえ今はいらなくとも、商品IDで検索したいってなったときに困らないように、
ある時点で有効な商品IDがどれかを特定できる情報を保持しておく。
448 名前：NAME IS NULL mailto:sage [2011/03/05(土) 00:39:28.99 ID:???]: 俺の場合、
自社に決定権がないコード体系のマスタ（商品など）は、サロゲートキー
自社に決定権があるコード体系のマスタ（得意先マスタ）はナチュラルキー
ジャーナルのヘッダはサロゲートキー、
ジャーナルの明細はヘッダのＩＤ＋明細番号の複合主キー
とすることが多いが、これって古臭い？
449 名前：NAME IS NULL mailto:sage [2011/03/05(土) 01:22:17.28 ID:???]: 雑誌コードなんか桁が足りなくて新規発番が出来なくなって使い回してるよな
450 名前：NAME IS NULL mailto:sage [2011/03/05(土) 01:28:21.09 ID:???]: そうゆうことか。
周辺システムが古くて桁数が少ないので
商品IDを使いまわさずを得ないと。

>>441みたいな場合ってどうなるの？
頻繁に商品IDが付け替えられて、古いほうの在庫も残る可能性がある。
同じ商品IDで、商品そのものも名称もまったく違う商品が存在する。

Web画面で商品を入力するためのボタンがあって、ポップアップで検索ボックスみたいのが出てきて
IDで検索すると同じ商品が複数出てくる。
それを選択してもらう。

Webの入力画面でコードを手打ち入力した場合の動作は？
ajaxとかで名称ひっぱりたいとこだけど、複数出てきた場合は新しい方を出したりするのかな？

なんにせよ恐ろしい・・・
こうゆう運用ならサロゲートキーは必須だ・・・
451 名前：NAME IS NULL mailto:sage [2011/03/05(土) 02:15:11.10 ID:???]: >>448
その得意先マスタのキーって得意先IDみたいなの、つまりサロゲーとキーでは？
ナチュラルキーになりうるのってなんだろうとぐぐってみたところ、
上場企業限定ならISINコードというものがあるようだけど、これなのかなぁ

>>449
休刊して番号温存だね。あるある。

>>450
客から見て、在庫も含めると異なる商品に対して同じ商品IDがついているけれども、
業務を滞りなく行えているのであれば、何も悩む必要はないよね。
こちらとしてはサロゲートキーで処理をしてしまえばいいだけだよー
452 名前：NAME IS NULL mailto:sage [2011/03/05(土) 02:17:08.29 ID:???]: >>450
加えて、商品IDでの検索結果が複数出てきたなら複数出せばいいんだよ。
それで業務がまわっているということが不思議だなぁと思うことはあれど、
それを正としなければいけないしねｗ
453 名前：NAME IS NULL mailto:sage [2011/03/05(土) 02:30:08.03 ID:???]: >>451
>上場企業限定ならISINコードというものがあるようだけど、これなのかなぁ

>>448の言う「自社に決定権があるコード体系」というのは、
そういった業界標準コード体系を意味しているのではなく、
業務の中で自然に発生する自社特有のコードを指していると思う。

たとえば、紙の受注伝票に記入する得意先コードや受注商品コードというのは、
自社特有の(自社で決定できる)自然キーである可能性が高い。
逆に、発注伝票に記入する発注商品コードというのは、
(自社では決定できないから)人工キーとせざるを得ない可能性が高い。
454 名前：NAME IS NULL mailto:sage [2011/03/05(土) 16:14:51.45 ID:???]: お前ら、商品ID商品ID言ってるけど、使いまわした時点でIDとしての役割を果たしてないだろうが
商品コードを使いまわす、が正しい用語だ
455 名前：NAME IS NULL mailto:sage [2011/03/05(土) 17:59:31.77 ID:???]: まぁ目安だよな。あくまでも、自分が定義したエンティティに対してそのコードが
一意であるがどうかで判断すべきであって。
・よそで定義されたコード→一意でない「可能性がある」
・自分で定義するコード→当然一意に「できる」

極端な話、実際の商品の品種と商品コードの一意性が一致しない場合であっても、
「商品」ではなく「商品コード」エンティティを作る分には商品コードをそのままキーと
してもぜんぜんかまわないわけだ。
456 名前：NAME IS NULL mailto:sage [2011/03/07(月) 20:06:48.91 ID:???]: >>453
＞自社特有の(自社で決定できる)自然キーである可能性が高い。
純粋な意味では、自然キーではないよね。ｗ
457 名前：NAME IS NULL [2011/03/07(月) 20:11:28.00 ID:OIEGkLgo]: >>440
＞MySQLでcheck制約がきかないのは初めて知りました・・・なんと恐ろしい。
こわくないよ？

つーか、それっておいしいの？
MySQLしか使わないオレには、よく
わからん話なんだよな。
458 名前：NAME IS NULL mailto:sage [2011/03/07(月) 20:53:11.82 ID:???]: >>456
システムの外で定義されるのが自然キーだろ？コードが人工的かどうかじゃなくて。
そんなこといったら、人名とか市町村名なんてどっちか判断つかん。
459 名前：NAME IS NULL mailto:sage [2011/03/08(火) 05:36:45.40 ID:???]: >>457
知らない者にとっちゃ恐ろしいだろ。
定義できるのにまさか動かないとは思わないだろうし。
460 名前：NAME IS NULL mailto:sage [2011/03/09(水) 01:13:08.54 ID:???]: >>454
このスレでのID、コードの使い分けって一般的に通用するものなの？
いや、自分もそういうふうに使い分けてるんだけど、他の人がそんな風に気にしてるの見たことがないので。
461 名前：NAME IS NULL mailto:sage [2011/03/09(水) 01:47:19.22 ID:???]: >>460
基本的には普遍でユニークな社員番号(商品ID)と、変更可能な姓名(商品コード)、
みたいな形で一般人も接してはいる。
462 名前：NAME IS NULL mailto:sage [2011/03/09(水) 15:48:40.12 ID:???]: >>460
まあ、大概の人は混同してる。このスレでも混同してる人もいるしな
一般の人にとって、コード振ってあるのに別にIDとるのは無駄に思えるんじゃね
463 名前：NAME IS NULL mailto:sage [2011/03/09(水) 20:21:29.21 ID:???]: 「混同」っていうと、まるで使い分けないのがおかしいみたいだな。
2行目をみるとそれぞれ別物のなにかを指しているというのはわかるんだが…
464 名前：NAME IS NULL mailto:sage [2011/03/10(木) 06:07:06.59 ID:???]: IDでもコードでも俺はどっちでもいいな。
使い分けてないプロジェクトがあっても、sql書く時に項目名間違えづらいなぁ程度にしか思わない。
465 名前：NAME IS NULL mailto:sage [2011/03/10(木) 09:17:01.62 ID:???]: >>458
システムの外で「独立して」定義されるのが
自然キーだろ？
顧客コードなんかデータベース以外に
ほとんど用途がないんだから。
466 名前：NAME IS NULL mailto:sage [2011/03/10(木) 15:38:23.73 ID:???]: >>463
ID=コードなシステムもまあよくある
というか、IDとコード別にもつシステムの方が少ないと思うけど

IDとコードもつシステムの例はコード使いまわされるようなやつとか
「その他」とか「一般小口」とかのコードもってるシステムとか

IDっていう用語の意味を考えると、厳密に区別できないとIDじゃないからな
467 名前：NAME IS NULL mailto:sage [2011/03/10(木) 22:58:24.84 ID:???]: >>465
この場合の「独立して」ってどういうことを意味しているのかな？
ここで挙げられた顧客コードってのは、「システムの外で定義されるけれども独立してない」例？
468 名前：NAME IS NULL mailto:sage [2011/03/11(金) 04:29:35.90 ID:???]: 独立していない可能性がある、または随時変更される可能性があるコードなんじゃない？
客から見えるコードだと、コードを振りなおしたい要求って結構くるよね
469 名前：NAME IS NULL mailto:sage [2011/03/11(金) 07:32:25.94 ID:???]: >>465
>顧客コードなんかデータベース以外に
>ほとんど用途がないんだから。

ええぇっ！！、それが常識なの？
自分のいる世界とは別の異次元な世界の住人さんらしい.... hahaha
470 名前：NAME IS NULL mailto:sage [2011/03/11(金) 11:13:05.74 ID:???]: 「データベース」の意味をどう捉えてるかによるだろうな
471 名前：NAME IS NULL mailto:sage [2011/03/11(金) 11:34:03.00 ID:???]: 「データベース」でくくるとさすがにちょっと狭いと思うぞ
ほとんど「情報処理」とか「システム化」と同じぐらいまで解釈を広げればまあ納得しなくはないが
472 名前：NAME IS NULL mailto:sage [2011/03/11(金) 13:15:03.35 ID:???]: 台帳をデータベースと呼ぶかどうか
473 名前：NAME IS NULL mailto:sage [2011/03/11(金) 13:18:57.55 ID:???]: >>469
そんな反応しなくてもｗ
そこだと、顧客コードは恒久的に変わらないことが前提で、顧客コードで会話等がされてるんでしょ。
その業務であればそのコードはIDであり、自然キーといっていいと思うよ。
474 名前：NAME IS NULL mailto:age [2011/03/13(日) 03:34:25.71 ID:???]: どのスレが適当か探してみたんですが、スレ立てるまでもない質問スレが見つからなかったので、ここで質問させて下さい。
病院で働いているんですが、今、上司からの依頼で、内視鏡検査の画像をデータベース化する作業をしています。
現在のシステムに以降する前の約２年分、件数にして4000件ぐらいのデータです。
データ形式ですが、約３ヶ月分ずつのデータがDVDにまとまっていて、DVDの中に入っている.exeファイルを起動して閲覧する、というものを、何とか一つのデータベースにまとめたいと悩んでいます。

各データは一件あたり数十枚で、たとえば34枚だとすると、フォルダ名00001、その中にjpeg画像00001から00034が３４枚格納されていて、つぎの件はフォルダ名00035となり、その中にまた画像一枚ずつに数字でファイル名がふってある形でした。
閲覧ソフトに患者名かIDか検査日を入力すると、画像が閲覧できます。
DVDに入っているのは画像フォルダ、恐らく画像とひも付けしたログファイルのフォルダ、あと閲覧ソフトです。

こういったデータを、Windows上で現在のシステムに移植するには、(オリンパスの出入り業者に確認した話ですが)一件一件検査オーダーを立てて、画像を指定する必要があるとのことでした。
自動でデータを読み出して全ての過去データDVDをデータベース化するか、現在のシステムに移植するには、どういうソフトを使えば可能でしょうか？
軽く調べたところ、SQLとやらいうスクリプトの話がでてきましたが、ド素人なので厳しいかと正直諦めかけてますorz
よろしくお願いします。
475 名前：NAME IS NULL mailto:sage [2011/03/13(日) 03:48:10.98 ID:???]: >>474
多分この内容だと情報が足りなすぎて誰もアドバイス出来ないと思う。
ファイルの格納の仕方は「なんだそれ」という感じではあるけれども
サルベージ出来ないわけでもない。多分ネックは、

>恐らく画像とひも付けしたログファイルのフォルダ

の中身と

>Windows上で現在のシステムに移植するには

の「現在のシステム」が分からないと、どうにもならないかと。
ただ間違ってもログファイルの抜粋をこのスレに貼り付けたりは
しないでね。

いずれにしても出来合いのソフトで出来そうな作業じゃない。
専用のマイグレーションのためのプログラムを書く必要はある。
476 名前：NAME IS NULL mailto:sage [2011/03/13(日) 04:30:03.11 ID:???]: >>475
レスありがとうございます。
やはり専用のプログラムが必要ですよね…
現在のシステムは、内視鏡サーバーに全て検査内容が直接スタックされるもので、オリンパスのsolemio というものです。
検査一件一件のデータをログから指定して、画面上の場所指定でオートクリック、ログ入力、画像指定が出来るソフトというと、オンラインゲームのチートソフトくらいしか思い付かず、それにしたってログを読み出すプログラムが別に必要になりそうな予感はしていました。

ちなみにログの抜粋がアウトなのは個人情報の関係ですか？
477 名前：NAME IS NULL mailto:sage [2011/03/13(日) 04:37:50.27 ID:???]: >>476
医療情報流出～匿名掲示板でアドバイスを装って診察データを入手か～

・・・なんてニュースになりたくないでしょw

オリンパスにデータインポーター提供してもらうしかないんじゃない
のかなぁ
478 名前：NAME IS NULL mailto:sage [2011/03/13(日) 05:08:53.69 ID:???]: >>474
画像の格納方法に規則性があるなら、画像を取り出すことは出来るかもしらんが、
「患者名かIDか検査日を入力すると～」がネック。おそらくこの他にも情報があるんだろうけど、これらのサルベージ方法が問題。
フォルダの中にテキストで埋めこまれてるとか言う間抜けな作りなら個人PGでも解析出来るだろうけど、さすがにそんなことはないだろうな・・。
そもそも元システムのライセンス的にどうかとかなりかねないし。

逆に解析を諦めるなら、最終手段で人がPC2台使って手入力でやれば出来る(つまり出入り業者の言う、「一件一件検査オーダーを立てて、画像を指定する」)。
この最終手段の可能性コミで、オリンパスに見積もってもらうのがベストだと思う。ただ人海戦術は安くないけどね。
479 名前：NAME IS NULL mailto:sage [2011/03/13(日) 06:48:05.90 ID:???]: >>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 mailto:sage [2011/03/13(日) 07:23:59.19 ID:???]: >>479の課題(3)で新規DB開発を決定した場合に限定される話だけど、
医療関係者が(外部の業者に頼らずに)自力でデータベース化を図るとしたら、
FileMaker Pro というDBアプリケーションがよく知られている。
FileMaker Pro は、Microsoft製であればAccessに相当するデスクトップDBソフトだけど、
SQLを憶える必要は無いし、テーブル設計/画面デザインからスクリプト作成まで
すべてGUIで操作できるから、簡易なDBであれば専門家でなくても開発できるのでお勧め。
（個人的にはシステム分析初期段階のラピッドプロトタイピングに活用している。）

たとえば以下の医療画像管理アプリはソースも公開されている。

・マイコミジャーナル：ファイルメーカ選手権（第一回）月間優秀賞：患者画像記録
　journal.mycom.co.jp/ad/contest/filemakersenshuken/01.html#2

FileMaker Proは試用版が無償で利用できるから、まずダウンロードして触ってみるのがいい。
質問等はビジネスsoft板に専用のスレがあるから、そちらへドーゾ。
481 名前：NAME IS NULL [2011/03/13(日) 16:43:53.66 ID:UrDSEA55]: 「はてな」や楽天のポイント履歴を見ていて思ったのですが、
ああいう頻繁にレコードの追加が発生するコミュニティサイトって
1テーブルのフィールド構成をどうしているのでしょうか？
単純に「日付｜ポイント数｜対象ユーザID｜対象動作ID」
で分けてるだけでしょうか？

でも、そう考えると、ユーザ数×履歴数で倍々に増えていくので
万単位の会員数があるサイトでは、ポイント履歴テーブルに
レコードが溜まりすぎるのではないか？と言う懸念があります。

ポイントというお金と変わらないものですから、
「○件まで保存。後は削除」と言うことはなかなか出来ないと思いますし・・・
482 名前：NAME IS NULL mailto:sage [2011/03/13(日) 17:03:45.55 ID:???]: ヒント：それらのケースでは厳密なACIDは要求されない。
　　　　（もちろん楽天の商品注文処理には厳密なACIDは要求される。）
483 名前：NAME IS NULL [2011/03/18(金) 16:34:48.59 ID:N3L942K+]: ショッピングサイトでのDB設計について
・注文テーブル、
・会員テーブル
があります。
会員が注文した場合は会員IDを外部キーとして注文テーブルに入れればいいのですが、
会員じゃない人からも注文が入るので、
注文テーブルに会員テーブルと同じようなフィールド（名前、送り先住所など）を入れて、
注文レコードに、会員ID（外部キー）が無い（NULLの)場合は、同じ注文レコードの名前や住所を参照しようと思っています。

もう１つは、会員テーブルと同じような、非会員テーブルをつくり、
会員じゃない人の住所情報などはそこに入れようという方法です。

後者の方が個人的にきれいな設計だと思うのですが、
この場合注文テーブルに入れる外部キーをどうするかがまた問題になって困っています（外部キーが非会員IDなのか会員IDなのかわからなくなる）。

これを解決するために、
非会員注文テーブル、
会員注文テーブル
と２つに分けることも考えていますが、
ここまですると逆に注文テーブルが２つになってしまうのできれいじゃなくなる気がします。

どうするのが一番良いでしょうか
484 名前：NAME IS NULL mailto:sage [2011/03/18(金) 16:40:17.60 ID:???]: 無駄すぎ
注文テーブルと会員テーブルだけでいいですがな
485 名前：NAME IS NULL mailto:sage [2011/03/18(金) 17:21:13.97 ID:???]: >>483
まず最初にモデル分析について。
前者は論外。注文テーブルでは注文に関する情報だけを定義すべき。
残る後者について、「会員の人」と「会員じゃない人」という概念は、
人に関する集合を意味するわけだけど、これら両方を包含した全体集合を考えなさい。
たとえば「取引先」という概念は一般に両者を包含するからよく用いられる。
あるいは全体集合を「会員」として位置付けて、部分集合を「正会員(会員の人)」と
「会員候補(会員じゃない人)」とに分割するという、逆の発想でもかまわない。

次に実装についてだけど、これもいくつかの方法がある。
たとえばモデル分析で全体集合を「取引先」とし部分集合を「会員」および「非会員」とした場合、
テーブルとしては「取引先テーブル」だけを定義し、そのフィールドとして会員区分コードを設ける方法。
あるいは各集合に対応する３個のテーブルを定義する方法もある。この場合、「会員テーブル」と
「非会員テーブル」には外部キーとして(取引先テーブルを参照する)取引先IDを設けることになる。

どちらの方法を選ぶにしても、注文テーブルの外部キーは取引先IDだけになるから、課題は解決される。
486 名前：NAME IS NULL mailto:sage [2011/03/18(金) 17:51:34.01 ID:???]: >>483
会員が自分の住所以外を送り先として注文することはないのかな?
487 名前：NAME IS NULL mailto:sage [2011/03/18(金) 18:02:59.08 ID:???]: >>485
前者は論外、とも言えないんじゃないのかなぁ。
会員IDがNULLの時だけ名前や住所の値を参照するという運用には
とても疑問があるけれども。

483は取引後に会員の名前が住所や変更される可能性と、その場合
も過去の個別の注文に関してはその当時の住所や名前を保存して
おく必要性(普通は必要だと思うけど)を考えるべきだと思う。

その場合には注文テーブルにも名前や住所などのカラムを作って
注文毎に会員情報から転記する方法と、少し前に散々議論された
会員情報をサロゲートキー使って管理する方法がある。
488 名前：NAME IS NULL [2011/03/18(金) 18:55:00.36 ID:vy9E5dGG]: 論理キー(複合キー)があるのに、わざわざID列を主キーに作るの勘弁してくれ。
489 名前：NAME IS NULL mailto:sage [2011/03/18(金) 20:32:06.47 ID:???]: 単にSingle Table Inheritanceの典型的なケースではないの？

この辺を参考にすれば
capsctrl.que.jp/kdmsnr/wiki/PofEAA/?SingleTableInheritance
490 名前：NAME IS NULL [2011/03/18(金) 21:45:08.46 ID:vy9E5dGG]: 典型的なプログラマー脳orパッケージ屋さんか？
491 名前：NAME IS NULL mailto:sage [2011/03/18(金) 22:02:10.77 ID:???]: ではDB屋さん的な回答どうぞ。
492 名前：NAME IS NULL mailto:sage [2011/03/18(金) 22:16:11.36 ID:???]: ・注文テーブル
・顧客テーブル
・会員テーブル

に分ければ良いだけじゃん。
注文テーブルの顧客IDと顧客テーブルのIDをJOINして
顧客テーブルのIDと会員テーブルのIDをJOINする。

会員テーブルには、ID/パスワードなど、ログイン専用のデータだけを保存する。
こうすれば会員じゃない人は顧客テーブルの参照で済むし、
会員なら会員テーブルまで参照すれば良いだけのこと。
493 名前：NAME IS NULL mailto:sage [2011/03/18(金) 22:26:40.26 ID:???]: ・注文テーブル (送り先の名前・住所入り)
・会員テーブル (会員の名前・住所入り)

かな。送り先の名前や住所は会員IDではなく注文IDに関数従属
するものだから、別のテーブルに分ける理由がない。

もちろん会員テーブルを過去の更新分も含めてサロゲートキーで
管理して、非会員の情報についても別の顧客テーブルなんちゃら
に分ける方法もあるけれども、無駄にスキーマが複雑になる。

判断は会員/非会員の注文の割合とか(非会員の注文が例外的か)
とかにも依存するけれども、単に注文毎に送り先を保存したい
場合は上のやり方が一番シンプルで良いと思うんだけど。
494 名前：NAME IS NULL [2011/03/18(金) 22:29:31.66 ID:N3L942K+]: >>484
会員テーブルに、非会員フラグなどのフィールドを入れるということですね？

>>487
> 483は取引後に会員の名前が住所や変更される可能性と、その場合
> も過去の個別の注文に関してはその当時の住所や名前を保存して
> おく必要性(普通は必要だと思うけど)を考えるべきだと思う。
それは全然考えてなかったですね・・・たしかに必要かも。

ということは、
>>492
の方法が一番良さそうですかね？
この>>492の顧客テーブルというのは、注文の住所や名前情報などがはいるんですよね？
注文レコードの数＝顧客レコードという認識ですが正しいでしょうか
495 名前：NAME IS NULL [2011/03/18(金) 22:33:01.55 ID:N3L942K+]: >>493
この方法も良さそうですね
496 名前：NAME IS NULL mailto:sage [2011/03/18(金) 22:42:31.73 ID:???]: >>494
・注文テーブル　→　注文日時、ステータス、商品合計金額
・（注文商品テーブル）　→　注文した商品のIDと価格
・顧客テーブル　→　名前や住所
・会員テーブル　→　ログインIDやパスワード

こう考えてみたらどうだろう
497 名前：NAME IS NULL mailto:sage [2011/03/18(金) 22:53:33.73 ID:???]: >>490
？
めちゃくちゃDB設計の話だと思うけど
498 名前：NAME IS NULL [2011/03/18(金) 23:00:42.16 ID:N3L942K+]: >>493の方法でいいかなと思っているのですが、
>>493の方法と比べて>>496の方法（顧客テーブルをはさむ）のメリットはなにがありますか？
499 名前：NAME IS NULL mailto:sage [2011/03/19(土) 00:18:10.77 ID:???]: >>498
>>493の方法の場合、例えば会員から注文があった場合には会員テーブル
から会員の名前や住所を送り先として注文テーブルに転記する必要がある。
会員の名前や住所はそうそう変わらないだろうから、同じ情報がテーブル
中に繰り返し現れるわけで、そういう意味では冗長でストレージの無駄。
>>496の場合は、これがない。

ただ>>496の方法で会員テーブルの結合に会員IDを使ってしまうと、ある
会員の名前や住所が変更になると過去の注文分に関しても送り先の情報が
変更されてしまう。注文履歴の正しい管理という意味でこれは拙い。
なのでこういう場合は会員テーブルに代理キーを立てて結合条件にはこれを
用い、会員情報を変更する場合も古い行はそのまま残して新しい行を会員
テーブルに追加する方法で対応する場合が多い。
言葉だと説明し難いので、過去ログを参照するかサロゲートキーで検索して
欲しい。

いずれにしても、会員/非会員の注文頻度の割合(非会員の注文も多い場合は
>>493のデメリットは相対的に小さくなる)、会員情報の更新頻度、あと
は注文データの件数によると思う。
ストレージの無駄さえ許容できれば>>493は一番シンプルな解だと思う。
500 名前：NAME IS NULL mailto:sage [2011/03/19(土) 00:27:12.05 ID:???]: そうか。顧客情報が変更になると注文情報も変更になるから
>>496だと整合性がとれなくなるよな。

>>493の方法は重複が出るけど、「過去○ヶ月のデータまで保存」
みたいな感じで、期限切れのデータは削除するかバックアップすれば
レコードの肥大化も極力抑えられる。
501 名前：NAME IS NULL mailto:sage [2011/03/19(土) 01:53:20.02 ID:???]: >>497
しかし>>489は回答にすらなっていない。
要件についてツッコミも考察も入れず「○○パターンで出来るよね～」
なんて真っ先にのたまうのは典型的なプログラマ脳だ。手元の技術しか
見えていない。
502 名前：NAME IS NULL mailto:sage [2011/03/19(土) 06:59:20.11 ID:???]: 「住所」が顧客の現住所(連絡先)なのか配送先なのか、はたまた配送先の
デフォルト値なのか、そういう分析がしっかりされないまま設計に入っても
議論がワヤになるといういい例だな。
503 名前：483 [2011/03/19(土) 13:14:35.62 ID:jv8AI/hU]: みなさんありがとうございました。助かりました。

会員の注文時の送り先住所は、
会員の住所が変わっても、変えてはいけないというのは盲点でした。

>>493の方法でいこうと思います。
これなら注文毎の住所が保存され、
会員の住所も保存できそうです。
会員の注文のときは、会員テーブルから住所をコピーして注文テーブルへ。
非会員の注文は、そのまま記載された住所を注文テーブルへ格納する。
という実装でいきたいと思います。
504 名前：NAME IS NULL mailto:sage [2011/03/19(土) 13:40:41.51 ID:???]: >>502
それは設計しながらでいいんじゃねーの？
仕様書作りながら「これはこういう可能性があるからこうしよう」
みたいな意見が生まれるじゃん。483のやりとり見ても生まれてるわけだし。
505 名前：483 [2011/03/19(土) 14:55:37.30 ID:jv8AI/hU]: まてよ、
>>493
> ・注文テーブル (送り先の名前・住所入り)
> ・会員テーブル (会員の名前・住所入り)
この方法だと、例えば新たに「電話番号２」カラムを追加したいときに、
２つのテーブルをいじらないといけないので、保守性の面であまり良いと言えないかもしれませんね。。。

なので、
・テーブルX
　名前、住所などを入れるテーブル（名前が思いつかない。顧客情報テーブル？）
をつくって、
注文テーブルや、
会員テーブルからはテーブルXのIDを外部キーとして保存するという方法を考えました
（それが>>492の方法でしょうか？）
これなら新しい項目が増えても、テーブルXを１つ編集すればいいだけなので解決しそうです。
実装方法は>>503の方法と基本的に同じで、
新たに注文が発生した場合は、
・会員の場合
　テーブルXに保存されている会員情報を、
　新たにテーブルXのレコードとしてコピーして、このIDを注文レコードの外部キーとする
・非会員の場合
　テーブルXに入力値を保存
このような形でつくろうと思います。
またご意見をくださいますでしょうか。

>>504のおっしゃるとおり、一人で開発しているので、
つくりながら仕様も決めていくような方式をとっているので、小出しになっていたら申し訳ないです
506 名前：483 [2011/03/19(土) 15:04:27.95 ID:jv8AI/hU]: まとめると、
- 注文テーブル
　・テーブルXのID（外部キー）
- 会員テーブル
　・テーブルXのID（外部キー）
- テーブルX
　・名前
　・住所
　・電話番号
　　　　：
　　　　：

この、テーブルXで名前住所などはすべて管理して、
あらたに会員が「届け先住所２」を追加したい場合は、
テーブルXに新しいレコードを追加して、そのIDを
会員テーブルの「届け先住所２」カラムに外部キーとして保存する、といった形になります。
507 名前：NAME IS NULL mailto:sage [2011/03/19(土) 16:00:36.14 ID:???]: そもそも規模によっては住所２が必要ない場合あるぞ。
小規模、顧客1000人以下程度ならいらないと思うけどな。
必要な時に追加したら良いんだよ。
508 名前：NAME IS NULL mailto:sage [2011/03/19(土) 16:18:47.06 ID:???]: 会員と非会員の注文比はどれぐらい?
非会員の注文数が多いようだと住所項目等を別テーブルに
切り出すメリットはかなり減るよ。
509 名前：483 [2011/03/19(土) 17:23:23.64 ID:jv8AI/hU]: >>508
現行のショップは会員という概念がなかったので、
今回会員を実装してどれぐらい会員になるかは未知数ですね。
ただ、非会員で買い物をするメリットというはあんまり無いので、
（会員になってもパスワードという入力項目が増えるだけ／会員になると今後の住所入力不要）
会員になる人が多くなると予想はしています。
ただ本当に具体的な比率は未知数です。
510 名前：NAME IS NULL mailto:sage [2011/03/19(土) 18:10:41.88 ID:???]: 会員になる人が多いか否かは商品によるんじゃね？
Amazonのように購入ペースが多いなら会員登録するだろうけど、
電化製品や服とかは、会員登録しなくても買いそうだけどな。
511 名前：NAME IS NULL mailto:sage [2011/03/19(土) 18:12:40.61 ID:???]: >>509
まず、

・会員情報に書かれる住所や名前や電話番号
・注文票に書かれる送り先の住所や名前や電話番号

ははっきり区別して考えた方が良いと思うよ。
例えば会員情報としては複数の住所や電話番号を持つことも
あるかも知れない。でもそれを全て注文票に転記する必要が
あるかというと、そうでもないと思う。

書かれている「新たに電話番号２カラムを追加したいときに」
の場合も、会員テーブルは変更する必要はあるかもしれない
けど、注文票にまで複数の電話番号を書き込む必要があるか?
というのは一度精査してみた方が良いと思う。
512 名前：483 [2011/03/19(土) 20:12:44.29 ID:jv8AI/hU]: >>511
たしかに。
やっぱり>>493がシンプルで良さそうだなぁ。
ぶれまくりですが、とりあえず先に進んでみようと思います。
また問題が発見してから考え直します。

みなさんありがとうございました。
513 名前：NAME IS NULL mailto:sage [2011/03/19(土) 21:26:29.97 ID:???]: プログラマ脳はどこへ行った?
514 名前：NAME IS NULL [2011/03/20(日) 22:16:51.93 ID:77T4BkwY]: エンティティとか主キーの概念がなくて
なんでも１テーブルに押し込む、キーはID列のみみたいなのはマジ勘弁
515 名前：NAME IS NULL mailto:sage [2011/03/20(日) 22:26:24.40 ID:???]: >>514
大福帳テーブルは意外と重宝しますよ。
516 名前：NAME IS NULL mailto:sage [2011/03/20(日) 23:11:01.39 ID:???]: >>515
うん。する。
517 名前：NAME IS NULL mailto:sage [2011/03/21(月) 08:13:31.36 ID:???]: NoSQLの設計はまさにそんなかんじじゃない？
518 名前：NAME IS NULL mailto:sage [2011/03/23(水) 04:59:34.66 ID:???]: .NETのコンポーネントの制限で複合キーを諦めざるを得ない
519 名前：NAME IS NULL [2011/03/23(水) 23:09:03.86 ID:MVHfXd/l]: 複合キーは無いわ
全テーブルにid int auto_increment でおｋ
520 名前：NAME IS NULL [2011/03/23(水) 23:27:16.79 ID:pi71qtr7]: まさにプログラム脳
521 名前：NAME IS NULL mailto:sage [2011/03/24(木) 01:02:41.70 ID:???]: >>519
つけるべきUNIQUE制約を忘れるなよ。
つけなければならない理由も。
522 名前：NAME IS NULL mailto:sage [2011/03/24(木) 14:48:10.96 ID:???]: >>519
MySQL脳か。
523 名前：NAME IS NULL [2011/03/24(木) 22:24:42.09 ID:G0Glp4Mc]: 今一緒にデータ移行の仕事してる人は業務的には複合キーのデータでも
キー値を１つにマージした列をわざわざ作ってるんだよなあ。

なんでもJOINするときにマージした列でJOINした方が早いとかw

複合キーでもINDEX張ったりすれば遅くないですよって言っても信じてくれない。
524 名前：NAME IS NULL mailto:sage [2011/03/25(金) 04:20:43.76 ID:???]: 複合キーでもサロゲートでもいいが、キー値のマージは一番アホ設計だと思うｗ
525 名前：NAME IS NULL mailto:sage [2011/03/25(金) 04:42:34.88 ID:???]: とりあえず日時型をキーに追加するアホが身近にいるので困る
526 名前：NAME IS NULL mailto:sage [2011/03/25(金) 04:51:01.91 ID:???]: 正規化崩しもそうだけど、解っていない人ほど「この方が速い」とか
キリッとのたまうんだよなぁ。
527 名前：NAME IS NULL mailto:sage [2011/03/26(土) 12:30:09.50 ID:???]: 会社マスタ
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 mailto:sage [2011/03/26(土) 17:27:46.83 ID:???]: ダメってことはないけど、CompanyIDとBranchIDを残してunique制約付けるなら
サロゲートキーは別に本来のキーと関係ある値にする必要はない。
529 名前：NAME IS NULL mailto:sage [2011/03/26(土) 19:35:25.40 ID:???]: >>527
なぜ複合キーが使えないのかわからん
その例なら、CompanyIDとBranchIDの複合キーじゃないのか？

その例なら単にBranchIDを支社マスタ内で一意になるように振れば良いだけだと思うけど
530 名前：NAME IS NULL [2011/03/26(土) 22:15:51.71 ID:Ib5l6n2v]: Companyコードはどこにあるの？
531 名前：NAME IS NULL [2011/03/26(土) 23:17:25.27 ID:U28l837d]: >>527
システム以外の都合でIDが決まる場合が少ない確率ながらある
（ID=1を本社にしたいとか、支社IDを使い回すとか）から、
やっぱり複合キーじゃなくて
全テーブルにIDを振るのがいいと思うんだがなぁ
なんでこのスレの人は否定するのかね
532 名前：NAME IS NULL mailto:sage [2011/03/26(土) 23:50:53.54 ID:???]: >>531
いや、普通に脳みそ足りなさそうな発想だから否定されて当然。

別に誰も代理キーを絶対に使うななんて言っていないでしょ。
要件をスキーマ設計に落とす過程で必要になった時に用法に注意
して使えば良いだけの話。
そのあたりをすっ飛ばしてトップダウンに「全テーブルにID振る」
なんて単細胞なアイデアを持ち出すから叩かれる。
533 名前：NAME IS NULL mailto:sage [2011/03/27(日) 05:15:34.98 ID:???]: 支社マスタ
BranchID(PK) , BranchName
　　0101　　　　　　本社
　　0102　　　　　　埼玉支社
　　0103　　　　　　神奈川支社

複合キーが使えないケースならこうせざるを得ないだろ
無関係なサロゲートキーでどうやって会社マスタとの紐付けを取る気だ
534 名前：NAME IS NULL mailto:sage [2011/03/27(日) 07:04:25.57 ID:???]: サロゲートキーを使うならこうだろ。

BranchKey not null,
CompanyID not null,
BranchID not null,

primary key ( BranchKey ),
unique( CompanyID, BranchID )

「複合キーが使えない」というのが複数カラムのUNIQUEも使えないという
意味なら別だが。
535 名前：NAME IS NULL mailto:sage [2011/03/27(日) 15:12:06.00 ID:???]: 複合キーが使えないってのがどういうことかわからんが
おそらく
CompanyID(PK) , BranchID(PK) , BranchName
01　　　　　　　　　　　　　01　　　　　　本社
02　　　　　　　　　　　　　01　　　　　　本社

みたいなことを想定してるんだと思うが、それなら
支社マスタって書いてるテーブルが、支社のマスタと
会社と支社のリレーション持ってるテーブルを兼用してるのが間違いだろ
536 名前：NAME IS NULL mailto:sage [2011/03/27(日) 15:41:43.57 ID:???]: それのどこが間違いなのかわからん。
537 名前：NAME IS NULL mailto:sage [2011/03/27(日) 15:45:16.49 ID:???]: 多分どっちでもいいんだよ。
どっちかしか駄目という人が間違ってる
538 名前：NAME IS NULL mailto:sage [2011/03/27(日) 16:19:08.97 ID:???]: >支社マスタって書いてるテーブルが、支社のマスタと
>会社と支社のリレーション持ってるテーブルを兼用してるのが間違いだろ

なんで間違いなん？
539 名前：NAME IS NULL mailto:sage [2011/03/27(日) 17:25:52.72 ID:???]: >>535
それが間違いだとして、テーブルを分けたとしても、その場合
会社支社リレーションのテーブルで同じ問題が起こる
そこが間違ってるかどうかは本質じゃない

じゃあ本質は何かっていうと
>複合キーが使えない場合、どういうキーを振るのが普通なの？
ってことだ
複合キーが使えない理由がよくわからんが、複合キーがダメなら代理キー作るしかないわな
代理キーの値をどうするかだが、ぶっちゃけ一意になれば何でも良いわけで
システム的に一意な連番振る機能があれば、それが使われることが多い
その場合は一意であることをシステム側で保障できるから
CompanyID+BranchIDの連結とかでもいいけど、その場合、それが一意かどうか
自分でチェックしないと保障されない
まあどっちにしろ要件的にCompanyID+BranchIDで一意チェックは必要だと思うから
この二つで主キーにしとけばシステム的に一意性が担保されるわけだが
540 名前：NAME IS NULL mailto:sage [2011/03/27(日) 19:55:32.48 ID:???]: たいていの場合CompanyID+BranchIDが一意になるとは思うが
仮にCompanyIDないしBranchIDを変更することになった場合
キー値も変更しないと気持ち悪いことになる
541 名前：NAME IS NULL mailto:sage [2011/03/27(日) 20:09:12.32 ID:???]: 連番使った場合はCompanyIDとBranchIDから代理キーの値を得るのに
支社テーブル上で逆引きをする必要があるけれども、CompanyIDと
BranchIDの連結をキーにした場合はアドホックに文字列処理でキーの
値が手に入るという利点は一応あるw

ただそういう設計や運用はあまり見ないよなぁ。やはり勘所は複合キー
が使えないという理由がよく分からん事だと思う。
ORMマッパー使っているからとか、DBMSの実装上の制約とか、上司の
オッサンが決めてしまったコーディング規則でそうなっているとか、
理由ごとに必要とされる答えも微妙に違う気がする。
542 名前：NAME IS NULL mailto:sage [2011/03/27(日) 20:17:45.17 ID:???]: >上司のオッサンが決めてしまったコーディング規則でそうなっているとか

これに500点
543 名前：NAME IS NULL mailto:sage [2011/03/28(月) 02:42:35.68 ID:???]: いや、単純にコンボボックスのデータソースに出来ないからだよ
544 名前：NAME IS NULL mailto:sage [2011/03/28(月) 02:51:30.55 ID:???]: CompanyIDを先に選択させりゃいいだろ
545 名前：NAME IS NULL [2011/03/29(火) 11:09:24.60 ID:1gjc3MDS]: >>532
無知で悪いけど、
「全テーブルにID振る」
これのデメリットってなにがあるの？
546 名前：NAME IS NULL mailto:sage [2011/03/29(火) 13:14:53.99 ID:???]: >>545
何の解決にもなっていないから。

連番をカラムとして追加してそれをテーブルの主キーにしたところで
「要件によって決まる」候補キーは歴然として存在するわけであって
そこに制約をつけたりアプリケーションのロジックを書いたりしないと
結局はデータの整合性は保たれないから。

「全テーブルにID振る」は実装上の方法論にすぎず、その前段階として
要件の分析をすっ飛ばすことは出来ない
ちゃんと分析をやった上で全テーブルに代理キー振るのなら、いいん
じゃない? ただその場合は当然分析の結果として必要な代理キーと共に
冗長な代理キーも見えてくるはずで、その評価は出来るよね。
547 名前：NAME IS NULL mailto:sage [2011/03/29(火) 16:32:09.66 ID:???]: もう少し馬鹿にもわかりやすく答えてくれ
548 名前：NAME IS NULL mailto:sage [2011/03/29(火) 17:11:30.69 ID:???]: 全テーブルにID振ること自体は「無駄」以外にデメリット無いよ。
OracleのROWID疑似列みたいな例もあるわけだし。

ただそれを無批判に主キーとして用いるのにはデメリットというか
危険性がある。例えば自然キーが存在するのを忘れてUNIQUE制約
を付け忘れたため危険な重複タプルが発生したりとか、変更の可能性
が無い自然キーに対しても代理キーを用いることでトランザクション
表の更新時に自然キーから代理キーの値を得る無駄な逆引きが必要に
なったりとか。
代理キーを持ち込むことで検索はともかく更新は一般的に複雑に
なりやすい。

個人的には要件の見落としを防ぐ意味でも、まず初めに自然キーを
主体にしたスキーマ設計に落として、そこから必要に応じて代理キー
を導入するのが一番安全だと思う。
何度も言うけれども、自然キーはまず要件から決まるものだから。
549 名前：NAME IS NULL mailto:sage [2011/03/29(火) 17:54:47.01 ID:???]: ＞表の更新時に自然キーから代理キーの値を得る無駄な逆引きが必要

いや別にいらんだろ
自然キーのユニークネスが保証されてるなら
550 名前：NAME IS NULL mailto:sage [2011/03/29(火) 22:02:11.24 ID:???]: 外部キーとして持つ場合なんかの話だろ
551 名前：NAME IS NULL mailto:sage [2011/03/30(水) 01:03:54.95 ID:???]: CREATE TABLE tablename (keyid VARBINARY(50) , columnid VARBINARY(50) , value BLOB , PRYMARY KEY(keyid , columnid));
ですべてことたりる
552 名前：NAME IS NULL mailto:sage [2011/03/30(水) 01:56:16.14 ID:???]: その分アプリのロジックで苦労するわけだけれどもね。
553 名前：NAME IS NULL mailto:sage [2011/03/30(水) 18:31:30.02 ID:???]: >>551
ガリレオ・ガリレイ
554 名前：NAME IS NULL mailto:sage [2011/03/30(水) 23:04:14.47 ID:???]: このスレと
【より良い】データモデリング【モデルを】
hibari.2ch.net/test/read.cgi/db/1057509675/
こっちのスレって何が違うの？
上流の作業の違いがいまいちよくわからん
モデリング後に設計？設計後にモデリング？
555 名前：NAME IS NULL [2011/03/30(水) 23:57:39.00 ID:1ro9g/Hl]: 住所の項目ってどうしてるよ？
都道府県と住所１と住所２（マンション名など）
って分け方が多いみたいだけど、
都道府県以外分ける必要ないよね
556 名前：NAME IS NULL mailto:sage [2011/03/31(木) 00:09:50.64 ID:???]: >>555
たとえばタックシールや送り状を作成する業務を考えると
住所が適当な長さで２行になってる方が都合がいいだろ

業務要件で住所が２行必要ならDB上も２項目でもつのは普通
つまり分ける必要があるかどうかは要件次第
557 名前：NAME IS NULL [2011/03/31(木) 00:18:34.96 ID:P2ST+s4H]: ２行かどうかなんてアプリケーション側の問題なんじゃ？
558 名前：NAME IS NULL mailto:sage [2011/03/31(木) 00:40:24.56 ID:???]: 要件に二行で折り返すことが含まれているのであれば、どこで
折り返すのか区切りが解らないと困るじゃん。

改行入りの文字列を住所として突っ込むのもありだけど、住所と
マンション名その他に分けて二つのカラムに分けて入れることが
多いと思う。
559 名前：NAME IS NULL mailto:sage [2011/03/31(木) 00:40:37.54 ID:???]: アプリケーション側の問題？
データモデルが常にそれらから独立していられるわけでもないだろう。
560 名前：NAME IS NULL mailto:sage [2011/03/31(木) 01:27:27.86 ID:???]: >>555

+--id--+--henji--+--syugo--+--dousi--|
| １ | YES　 | I　 | DO |
+----------------------------------+
561 名前：NAME IS NULL [2011/03/31(木) 20:36:43.35 ID:WO6NrX3S]: >>555
> 住所の項目ってどうしてるよ？
郵便番号が取得できるなら郵便番号DBを利用する
できないなら総務省の地域コードを使う
コード変換できない番地以下は各レコードに持たせる
最低でもこうしないと話にならない
562 名前：NAME IS NULL mailto:sage [2011/03/31(木) 20:53:20.54 ID:???]: DB的には住所をコード化するのが先決だわな

2行でタックシール(ｷﾘｯ)とか馬鹿じゃねえの
563 名前：NAME IS NULL mailto:sage [2011/03/31(木) 21:52:14.51 ID:???]: 単に土地住所と建物住所じゃないの？
564 名前：NAME IS NULL mailto:sage [2011/03/31(木) 22:57:25.26 ID:???]: タックシールの馬鹿を見るだけで、全角英数は馬鹿という定説が正しいことがよく分かる
565 名前：NAME IS NULL mailto:sage [2011/04/01(金) 00:06:20.96 ID:???]: DB的には氏名をコード化するのが先決だわな
566 名前：NAME IS NULL mailto:sage [2011/04/01(金) 00:35:02.02 ID:???]: 「コード化する」ってなに？
567 名前：NAME IS NULL mailto:sage [2011/04/01(金) 00:42:28.28 ID:???]: たっくんおかえり
568 名前：NAME IS NULL mailto:sage [2011/04/01(金) 00:48:36.32 ID:???]: (国)、都道府県、市町村、町域、建物その他で分けるだろ
569 名前：NAME IS NULL [2011/04/01(金) 07:05:20.44 ID:QNKMILe9]: 郵便番号検索とかどうしてる？
新しい市町村増えたり、メンテが面倒そうなんだけど
570 名前：NAME IS NULL mailto:sage [2011/04/01(金) 07:09:15.74 ID:???]: そうだよ。
だから郵便番号検索機能が仕様にある場合はメンテ分も見越して金額が跳ね上がらないといけない。
現実は「簡単でしょ？付けてよ」でプロジェクト終わり。
571 名前：NAME IS NULL mailto:sage [2011/04/01(金) 07:25:43.06 ID:???]: 要件確認せずに、「だろ」って決め付けてもねぇ。
地番は？住居表示はどうすべきだと思ってるの？
572 名前：NAME IS NULL mailto:sage [2011/04/01(金) 10:02:49.85 ID:???]: 初心者ですDBの勉強もかねて、簡単なユーザ登録のできるBlogサイト作成しようと思っています。
日記のデータを保存するテーブルについて質問なのですが、一般的(他のサイトなど)に日記を保存している
テーブルというのは、1つのテーブルで全ユーザの日記のデータを保存しているのでしょうか？
例えば一般的には、ユーザID,日付,日記本文,(その他省略)という構造なのでしょうか？

この場合、ユーザ数が増えれば相当なデータサイズになり、1ユーザの日記を数日分、selectするのに時間が
かかるような気がします。(この辺が初心者で、時間がかかるのかもよくわかってないのですが・・・)
573 名前：NAME IS NULL mailto:sage [2011/04/01(金) 11:09:31.44 ID:???]: まぁそのためのデータベースだ
適切な設定なら100万レコードからでも一瞬で目的のレコードを探せるよ
574 名前：NAME IS NULL mailto:sage [2011/04/01(金) 22:51:49.57 ID:???]: それだと、日記が一日ごとにしか書けないな。
575 名前：NAME IS NULL mailto:sage [2011/04/01(金) 22:54:03.22 ID:???]: 適当な質問には適当な回答しか無いだろ
576 名前：NAME IS NULL mailto:sage [2011/04/02(土) 02:10:35.17 ID:???]: お前ら、こういうDB設計の要件定義って、
仕事でやる場合どのくらい時間かける？最低1ヶ月はかかるよね
577 名前：NAME IS NULL [2011/04/02(土) 02:18:13.66 ID:SR6eBDqn]: >>570
そういう情報ってどっかにAPI公開されてないのかな
もしくはデータが簡単にダウンロードできたり
578 名前：NAME IS NULL mailto:sage [2011/04/02(土) 02:41:31.19 ID:???]: >>577
データは郵便局サイトに
コンポーネントもググれば簡単に見つかる
大概↑データを使用する前提
579 名前：NAME IS NULL mailto:sage [2011/04/02(土) 09:09:49.55 ID:???]: つーか、ろくすっぽ調べず「郵便番号メンテが面倒」とか、「住所は二行でタックシールだ！」
とかその手の足りない子を見ると、正規化だのサロゲートキーだのを熱く語る前に、他にやるべき
ことあんじゃねえのって感じだな
580 名前：NAME IS NULL mailto:sage [2011/04/02(土) 12:53:38.07 ID:???]: なんか、面倒だな
581 名前：NAME IS NULL mailto:sage [2011/04/03(日) 15:32:48.21 ID:???]: それでも地球はまわっている
582 名前：NAME IS NULL mailto:sage [2011/04/03(日) 17:10:43.94 ID:???]: そして原発は冷却中である
583 名前：NAME IS NULL mailto:sage [2011/04/03(日) 23:20:21.80 ID:???]: >>568
そんなの、実データ使った解析でいかようにもできる。
客が入力したままの文字列を一つだけ保持しておけば、あとは正規化した住所を都度アプリ側で吐き出せばいい。
584 名前：NAME IS NULL mailto:sage [2011/04/04(月) 00:39:15.82 ID:???]: >>583
アプリに全部任せてDBは設計もクソもなくていいって聞こえるが・・・
585 名前：NAME IS NULL mailto:sage [2011/04/04(月) 00:47:44.84 ID:???]: 座標保持するのが流行り
586 名前：NAME IS NULL mailto:sage [2011/04/04(月) 06:56:16.69 ID:???]: >>585
ダイレクトメールという文化はやがて滅びるから
企業の視点では、住所や所在地情報の地位は
低下し続けるに違いない。
587 名前：NAME IS NULL mailto:sage [2011/04/04(月) 07:51:03.48 ID:???]: >客が入力したままの文字列を一つだけ保持

こんなこと書いてるエセ設計者の言うことは無視でよろし
588 名前：NAME IS NULL mailto:sage [2011/04/04(月) 19:32:50.57 ID:???]: エセというか、ただの馬鹿だろ

せっかく公共団体の統一コードがあるのに文字列で持たせるとか正気か？
どうせAccessあたりで糞アプリ作ってる底辺プログラマだろけど
589 名前：NAME IS NULL mailto:sage [2011/04/04(月) 20:51:35.27 ID:???]: DM用や顧客用のデータなんだろ？
正規化用のデータを、持しても客が使うデータは、たとえ間違っていても入力のママで使うんだよ。
現場も知らない馬鹿が教科書通りに設計すると回らないから気をつけろw
590 名前：NAME IS NULL mailto:sage [2011/04/04(月) 22:22:53.14 ID:???]: 正規化と言いたいだけの中小企業Access使いとか、底辺を見ても何の参考にもならないし、
時間の無駄だから、まともな知能を持った人は郵便番号DBや地方公共団体コードを使いましょー
591 名前：NAME IS NULL mailto:sage [2011/04/04(月) 22:23:08.98 ID:???]: 馬鹿にしてるつもりなのかな？拙い日本語使って煽られてもねぇ・・・
592 名前：NAME IS NULL mailto:sage [2011/04/04(月) 22:54:36.58 ID:???]: ハンマーを持った子供には何でも釘に見える

地方公共団体コードなんて覚えたての子供は、「住所」と出てきたらコードを
使わなきゃ気が済まないんだよ。
593 名前：NAME IS NULL mailto:sage [2011/04/04(月) 23:40:02.69 ID:???]: まあ、要件も確認せずに何とかコードでOKとか言うやつは
まともな知能を持ってないってのは解る

あと底辺の人ほど他人を底辺だって決めつけるよな
バカっていうやつがバカ的な感じ
594 名前：NAME IS NULL mailto:sage [2011/04/04(月) 23:46:14.17 ID:???]: たっくんおかえり
595 名前：NAME IS NULL mailto:sage [2011/04/05(火) 00:53:48.93 ID:???]: >>590
名寄せのロジックの一部には郵便番号DBも使うが、あくまでも一部。
おまえ、日本全国の何百万という重複する住所の名寄せなんてしたことないだろ。
したことがあれば、あんな不完全なデータを錦の御旗にドヤ顔出来る訳がない。
596 名前：NAME IS NULL mailto:sage [2011/04/05(火) 07:29:40.55 ID:???]: >日本全国の何百万という重複する住所

具体例どぞ
597 名前：NAME IS NULL mailto:sage [2011/04/05(火) 07:33:04.51 ID:???]: >>596
どこそこ区の青葉台となになに市の青葉台で一例。
この組合わせを合計するとそんな数になりそう。
598 名前：NAME IS NULL mailto:sage [2011/04/05(火) 08:24:56.02 ID:???]: >>597
そういうのは都道府県が違うので重複とは言わない
もっと例示するにふさわしい具体例を挙げるよろし
599 名前：NAME IS NULL mailto:sage [2011/04/05(火) 08:53:52.43 ID:???]: >>596
数十万単位のユーザーが十数年にわたって複数回入力する住所の名寄せだよ。
当然ユーザーからしてみれば同じ住所でも入力パターンは間違いも含め多岐に渡り、市町村合併や郵便番号も変わるからね。
600 名前：599 mailto:sage [2011/04/05(火) 09:10:15.59 ID:???]: 他にも英語表記やカタカナ、ひらがな表記も含む。
市区町村の区分も守られておらず(特に町と村。そもそものインターフェースが郡で区切ってたりする)、都道府県が空白なんてざら。
複数のインターフェース、複数の時代を経た巨大な住所データなんて蓋を開ければこんなもん。
入力時に住所が正規化される単一のシステムならなんの問題もないけど、そうでない上記のようなデータなら、住所は一旦すべて連結し、解析掛けるのが正確で早い。
601 名前：NAME IS NULL mailto:sage [2011/04/05(火) 09:13:12.42 ID:???]: だからコードにしておけば手入力を解析だ名寄せだとかキチガイじみた発想にならんのだって
ためしに通販サイトかなんか見てみろよ
大抵、プルダウンから選択か、郵便番号から選択だろが

逆に手入力のメリットがあるなら出してみろや
602 名前：599 mailto:sage [2011/04/05(火) 09:24:48.43 ID:???]: >>601
日本語分かるか？
入力時に正規化出来るなら問題ないがと書いてるだろ。
新規で開発するような話をしてるんじゃなくて、手書きも含め、複数のインターフェースが存在することが前提のデータ処理の話をしているんだが。
603 名前：599 mailto:sage [2011/04/05(火) 09:28:14.95 ID:???]: >>601
そして、コード化の一番のデメリットは過去の住所はにたいおうしづらい
604 名前：599 mailto:sage [2011/04/05(火) 09:37:39.53 ID:???]: >>601
失礼、途中で送信してしまった。

コード化のデメリットは過去のデータに対応しづらいという事。購入、決済データぐらいじゃそこまで気にする事はないし、下手すればそもそもの住所の正規化すら要らないケースが多いけど、
過去にさかのぼる名寄せみたいに、コード化よりも解析のほうが現実てきなケースがある事を知っておいて損はない。
605 名前：NAME IS NULL [2011/04/05(火) 18:49:22.35 ID:Ge8zwV8y]: >>602
> >>601
> 日本語分かるか？
> 入力時に正規化出来るなら問題ないがと書いてるだろ。
名無しIDなしでお前のレスがどれだかわかるわけねーだろw
つーか、DB設計の話をしてるのに名寄せだ解析だとか言い出すから、
頓珍漢に拍車がかかるんだっての

データ移行が要件なら、その解析とやらに使う労力を変換に割り振れよww

言ってることが支離滅裂だっつーのw
606 名前：NAME IS NULL mailto:sage [2011/04/05(火) 19:31:24.00 ID:???]: >>605
要するに何の話をしているんだい。
607 名前：599 mailto:sage [2011/04/05(火) 20:05:05.66 ID:???]: >>605
わざわざ599と入れてるのも分からない馬鹿かw
だから、DB構造としては、住所は一つまのカラムしかもってない(まあ郵便番号くらいは持つが)と言う事だよ。
一応、入力時は分割されてるが、それを連結したものが正式なデータとしてつかわれる。
正規家した住所は複数のカラムを持つが、それは都度都度の最新住所を吐きだすワークテーブル扱い。
高言う実例もあるんだよ。
608 名前：NAME IS NULL [2011/04/05(火) 20:20:17.47 ID:Ge8zwV8y]: >>606
・住所をまんまの文字列で持つメリットは全くない
・文字列を保持して解析とか言ってるのは池沼
・名寄せとかいきなり言い出してるのは馬鹿(同じやつだろうけど)
・タックシール(ｷﾘｯ

ちなみに文字列解析が現実的とか、噴飯ものの物を知らない子
みたいだけど、世の中にはコンバータってのが売っていてだな、
それで変換できないのは、対象外にするか、客先マターにするか、
その辺は契約にもよるけど、少なくとも俺らが住所と関わるって
のはそういうもんなの
いくら底辺プログラマで単価が安くても、アホな設計の尻拭いに
工数かけて解析とかありえねーよw
コンバータ買ってもらえって

とここまで書いたらタックシールが性懲りもなく現れた
もはや解読困難で相手にすんの面倒くさいから、他の人に任せる

といことで逃亡
609 名前：NAME IS NULL mailto:sage [2011/04/05(火) 20:22:29.70 ID:???]: 大変だなぁ。で、設計の話はどこ？
610 名前：599 mailto:sage [2011/04/05(火) 20:50:16.33 ID:???]: >>608
コンバーターは、それぞれの企業が自社で使う必要があって開発したものなことも知らないのか。
どんだけ小さな現場しか知らないんだよw
入力データを正規化して保持して、オリジナルを破棄出来るなら苦労はないんだよ。
自分の知らないしくみがあることは恥でもなんでもないのに、実例紹介してるのに信じないなら勝手にしろw
611 名前：NAME IS NULL mailto:sage [2011/04/05(火) 20:50:39.64 ID:???]: 変換ソフトの稟議書作成じゃね？
612 名前：NAME IS NULL mailto:sage [2011/04/05(火) 20:53:18.81 ID:???]: >>610
設計の話しないなら帰れよ。
613 名前：NAME IS NULL [2011/04/05(火) 21:00:32.80 ID:r6xQc+hf]: コンバータってこれか
www.addressmatch.jp/anormapp/do_anorm

昔住んでいた埼玉県大宮市高鼻町で検索したら、一発で変換できた！
オラ良いこと知ったぞ

でももう埼玉は住みたくない
614 名前：NAME IS NULL mailto:sage [2011/04/05(火) 21:20:38.76 ID:???]: 正直、なぜこんなのでこの人たちがここまで熱くなれるのか疑問ではある
615 名前：NAME IS NULL mailto:sage [2011/04/05(火) 21:28:27.96 ID:???]: かつてクラス名簿を頼りに好きな娘の家の住所を探し歩いた経験からです
616 名前：599 mailto:sage [2011/04/05(火) 21:31:55.96 ID:???]: >>612
一応、設計上、住所がひとつの構造の実例もあるよ、という話だったが...
まぁ、確かにそろそろスレチだな。失礼。
617 名前：NAME IS NULL mailto:sage [2011/04/05(火) 21:37:41.55 ID:???]: スレチ以前になんの参考にならないからもう出てこなくていいお(^^
618 名前：NAME IS NULL mailto:sage [2011/04/05(火) 23:55:16.74 ID:???]: 厳密に言えば設計じゃないのかも知れんが、要件定義、モデリングの話題としては興味深い。
619 名前：NAME IS NULL mailto:sage [2011/04/06(水) 00:54:23.79 ID:???]: 市町村コードと住所正規化コンバータの存在は確かにためになった
サロゲート談義よりよっぽど
620 名前：NAME IS NULL mailto:sage [2011/04/06(水) 09:28:28.56 ID:???]: このスレ市町村コード知らない人が見てたのか
621 名前：NAME IS NULL mailto:sage [2011/04/06(水) 09:29:53.92 ID:???]: >>620
私は公的なものは大嫌いだから。
622 名前：NAME IS NULL mailto:sage [2011/04/06(水) 09:42:58.98 ID:???]: よくわからんけど、話題終了した方がよさそうなのはわかった
623 名前：NAME IS NULL mailto:sage [2011/04/06(水) 09:50:12.87 ID:???]: >>621
ねっこのおりん
624 名前：NAME IS NULL mailto:sage [2011/04/06(水) 20:40:10.84 ID:???]: 「都道府県がなぜ北海道始まりなんだ！」と言われたらJISを参照する
625 名前：NAME IS NULL mailto:sage [2011/04/07(木) 16:18:49.41 ID:???]: >>621
ただの馬鹿ですね
626 名前：NAME IS NULL mailto:sage [2011/04/07(木) 20:22:35.53 ID:???]: まあ市町村コードなんて、馴染みのない人には全くない系統の知識だからね
いつなんどきどういう案件が降ってくるか分からないんだから、普段から
色んなことにアンテナを張っておくことが大切だってことさ
627 名前：NAME IS NULL mailto:sage [2011/04/08(金) 01:02:53.18 ID:???]: > 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
628 名前：NAME IS NULL mailto:sage [2011/04/08(金) 04:33:07.53 ID:???]: それで結論として、
住所はユーザが打ち込んだひとつの欄でいいね。
エラーがあるかとか、いろいろ解析するのが楽しみでね。
629 名前：NAME IS NULL [2011/04/08(金) 08:59:30.25 ID:UUNyLKi3]: はいはい、タックシールタックシール
630 名前：599 mailto:sage [2011/04/08(金) 09:52:11.62 ID:???]: >>628
結論は、色々なケースがある、だろ。
住所一つ厨も、自分のケースは特殊と言ってたろ。
631 名前：NAME IS NULL [2011/04/08(金) 12:25:56.73 ID:UUNyLKi3]: その場かぎりのアンケートみたいなのは使い捨てでいいんさ
顧客情報が絡んで将来的にDWH的な使い方がありえるんなら、
コード化にコストを費やすことを考えなくちゃならない
つか、そう提案すべき
632 名前：NAME IS NULL [2011/04/11(月) 17:06:53.99 ID:9HYaTenG]: ちょっとご相談というかむしろどのような方法が一般的なのか判らない状態での質問です。

DBはSql鯖2008R2 アプリはC# WinFormで作成しています。

現在開発中物件で　営業時間・毎週休業日・祝祭日・臨時休業・臨時営業　の設定が必要なシステムを作成する事になりました。
今考えているのは各設定を年度毎にもち
確定された時点で1年分のカレンダーデータを一気に作成(1年分のレコードを作成)
修正された場合、修正日以降のカレンダーデータを変更する

ような感じで設計してみようと考えています。

カレンダーデータは

年月日
営業開始時間
営業終了時間
種別(0営業 1臨時営業 2定休 3祝日 4臨時休業 )

のような感じで1年分を作成し保持しようかと・・・

伝えたいことがうまく伝えにくいのですが、休日を柔軟に設定する事が出来て、
営業時間・休日のデータが簡単に取り出せる・判定できるようなテーブル設計を行いたいのです。

なんらかの定石的な方法があるのであればいいのですが、そのようなものは社内にないようでして・・・
何らかのヒント的なものでもいいので、お手すきの方がいらっしゃいましたらご教示いただければと思います。
633 名前：599 mailto:sage [2011/04/11(月) 23:53:09.51 ID:???]: >>632
種別が一つじゃ、臨時営業だけど、実は定休でなおかつ祝日の日とかどうすんだよw
種別は全部バラしてマスタにしろ。
それぞれの重み付けは固定ならアプリで持ってもいいし、変動するならこれもマスタにする。
634 名前：NAME IS NULL mailto:sage [2011/04/12(火) 00:25:33.31 ID:???]: >>632
今考えてみた
T/種別( ID 名称 )
T/ルール（月日曜日何週優先度開始終了種別ID ）
T/カレンダー（年月日開始終了種別ID ）
V/カレンダー（年月日開始終了曜日@年月日何週@年月日種別ID ）
カレンダーをデフォルト値で1年分生成してからルールを適用する

俺ならこうするかも知れない
635 名前：NAME IS NULL mailto:sage [2011/04/12(火) 07:21:40.99 ID:???]: >>632
例えば、毎週休業日が年に三回変更になったとして、
そのルール・ログが残らないような設計はおかしい。

毎週休業日
---------------------------
休業日起点 | 休業日終点 | 曜日

というようなテーブルを定義していくべき。
636 名前：NAME IS NULL mailto:sage [2011/04/12(火) 10:01:08.49 ID:???]: おはようございます。
>>633->>635
お時間を割いていただきありがとうございます。
皆さんの意見を参考に考え直してみました。
結果以下のような感じに・・・皆さんから見るとまだまだ設計力が足りませんが

TM_祝日(年月日{pk}、祝日名)
※祝日は基本固定なんで年更新処理で1月n週や固定日などから生成し、変更可能に

TM_毎週休業日(適用開始日{pk}、適用終了日{pk}、曜日番号{pk})
※休日は現在毎週n曜日のみでいいらしい。毎月n日とかその他のが出たらマスタ増やして対応

TM_臨時休業(年月日、備考[理由])
TM_臨時営業(年月日、営業開始時間、営業終了時間、備考[理由])

TM/営業時間(適用開始日、適用終了日、曜日、営業開始時間、営業終了時間)
※毎週土曜は半ドンらしくこういった持ち方もあり？

TM_カレンダー(年月日{pk}、{pk}に対する曜日、{pk}に対する第hoge週,営業開始(null有)、営業終了(null有)、備考)
※開始・終了のいずれかがnullなら営業してない(片方だけnullはありえない)
※備考は祝日\r\n臨時営業とかの情報をマスタ変更時に残すようにする

上記TM系のマスタ条件でカレンダーを生成
マスタ変更時は影響範囲のカレンダレコードだけを同時に書き換え
(優先度は　臨時営業>臨時休業>定休>祝日　カレンダーデータ作成時に固定となる)

TM_カレンダーは(年月日{pk}、{pk}に対する曜日、{pk}に対する第hoge週)だけを持ち、
ビューやストアドなどで結果を返すほうがデータの無駄が無いかもしれませんが、
参照の回数とかを考慮して少しデータ量が増えますがあえてテーブルに書き込むようにしてみました。

設計て難しい、でもこれしっかりやらないとアプリがグダグダになってしまうので
妥協範囲を出来るだけあげてキッチリやっておきたいです・・・
637 名前：634 mailto:sage [2011/04/13(水) 00:29:50.20 ID:???]: 曜日、何週をビューで定義したのはバグとミスオペでの変更を抑える為
634の形ではルール適用で必要になるから持ってる
636の形はよく理解できてないけどあんまり必要じゃない気がする
ぱっと見TM_祝日はハッピーマンデー対応できない気がするけど毎年修正するのか？

>>635
毎週休業日の変更とかどの業種でもかなり大きい変更だから年数回どころか数年に1回だと思うけど
638 名前：NAME IS NULL mailto:sage [2011/04/13(水) 00:48:02.58 ID:???]: >>637
TM_祝日は基本年次処理でつどつど祝日をyymmddで保持するっぽいから、ハッピーマンデーも問題ない気がする。
639 名前：NAME IS NULL mailto:sage [2011/04/13(水) 00:57:50.12 ID:???]: >>638
そこでやるのか～
ずいぶん高度だな
640 名前：NAME IS NULL mailto:sage [2011/04/13(水) 05:27:11.25 ID:???]: >>639
高度というか、力技だな。単純だがそれがいい。
管理者も入れ替わり、運用がおざなりになったときに、日付の入力を忘れたり間違えたりして支障が出る可能性は高そうだがｗ
641 名前：NAME IS NULL mailto:sage [2011/04/13(水) 09:51:31.28 ID:???]: >>637-640
色々なご意見ありがとうございます。

>>637
いや、正直日付から週数や曜日は簡単に出るんですが、試しに入れてみたらそのデータがあるとDBを生で見たりする場合に
判りやすじかったのでパクらせてもらいました。

祝日に関してですが
年次更新時にデフォルトできっちりデータは入れてやります。(全て入力とかは間違えるし厳しいと思うので)
その為にプログラム内で1月1日は元旦、1月の第2月曜日は成人の日などの情報を持ち
その情報からレコードを作成してやります。

基本的に祝日定義や名称の変更があるんでその部分をDLLなり設定ファイルなりにして
変更時にアップデートでファイルの差し替え、年次更新時にそのデータ利用して一覧を作る
という感じです。
祝日の定義が変る可能性が非常に高いので、もし何らかの理由でこちらの対応が間に合わない場合、
何かユーザー側での変更可能な方法が必要かなと思いベタベタな実装にしました。
（今の政府は年度開始時に年度末の休日定義とか平気で変えてきそうなので・・・）
※地方によって祝日定義変わるとかホント勘弁してください。　ほんと苦肉の策です　ありがとうございました。

後他の入力に関してですが
正直オペミスはあるとおもいます。なので入力チェックとかキツキツにする必要はあると思います。
(年次更新時に定義の範囲が今年度にかぶってない場合は出来ないとか)

PS.
仕様書・設計・レビュー・PG・デバッグ・設置と納品まですべて一人でやらなきゃいけないので頭が沸いてきました。
642 名前：NAME IS NULL mailto:sage [2011/04/13(水) 10:00:34.82 ID:???]: >プログラム内で1月1日は元旦、1月の第2月曜日は成人の日などの情報を持ち
>その部分をDLLなり設定ファイルなりにして
なぜそれをＤＢに格納しないのかね
643 名前：NAME IS NULL mailto:sage [2011/04/13(水) 10:14:53.39 ID:???]: >>642
年次更新のタイミングでその情報をDBへ格納します。
定義が変る可能性が高いので年次でギリギリまで登録待ってから登録→もし年内で変更あれば手動で変更
という予定です。
644 名前：NAME IS NULL mailto:sage [2011/04/13(水) 23:30:26.66 ID:???]: ハッピーマンデーも将来無くなる可能性がある。

祝日をyyyy/mm/ddで持つのもありだね。
645 名前：NAME IS NULL [2011/04/14(木) 20:42:54.35 ID:2zZWkF3S]: >>643
その年が変わってから、
その年の休日が変わる可能性なんてないよｗ
646 名前：NAME IS NULL mailto:sage [2011/04/14(木) 20:55:04.90 ID:???]: >>643
>定義が変る可能性が高いので
変わる可能性が高い情報をプログラム側に持たすのか？
休日の定義もＤＢにもたせて、その定義から年次更新でマスタ作成すればいいだろ
647 名前：NAME IS NULL mailto:sage [2011/04/14(木) 21:18:24.25 ID:???]: 休日の定義を持たせたら、その休日の定義の有効期間まで保持しなきゃならなくなる。
だったら、素直にyymmddで休日を持たせたほうが話が早い。
648 名前：NAME IS NULL mailto:sage [2011/04/14(木) 22:15:42.63 ID:???]: 過去となった祝日は絶対に不変なのだから、yyyy-mm-ddで決め打ちでいいと思うけどな～
649 名前：NAME IS NULL mailto:sage [2011/04/14(木) 22:51:22.94 ID:???]: 祝日どころか全部過去適用なしなんだから有効期間ってのがなぜ必要なのか意味が分からない
単に、ルールで持てば？展開して日付で持てば？って話のような気がするけど
650 名前：NAME IS NULL mailto:sage [2011/04/14(木) 23:07:13.39 ID:???]: >>649
例えば、極端な話、元日が1月1日ではなく、1月10日に変更になったとする。
当然、過去の1月1日には適用できないので、いつから元旦が1月10日になったのか日付を保持する必要があるだろ。
651 名前：NAME IS NULL mailto:sage [2011/04/14(木) 23:11:40.13 ID:???]: 別にないよ。
2010/01/01
2011/01/10
って持っとけばいいだけだから。
652 名前：NAME IS NULL mailto:sage [2011/04/14(木) 23:17:29.01 ID:???]: >>651
だから、それでいいじゃん、と言ってるわけだ。
休日のルールを定義づけして、DBで保持する必要はない。
653 名前：NAME IS NULL mailto:sage [2011/04/14(木) 23:57:19.08 ID:???]: >>650
ごめん、>>646の解釈が全然間違ってて見当違いなレスした

生成よりも反映でやった方が色々いい気がするけどなぁ
延々増え続ける祝日テーブルとか嫌だわ、俺は
654 名前：NAME IS NULL mailto:sage [2011/04/15(金) 00:20:06.76 ID:???]: おめーの好き嫌いはどうでもいい
655 名前：NAME IS NULL mailto:sage [2011/04/15(金) 00:54:12.36 ID:???]: >>654
ちょっと笑ったw
それにしても、ID出ないと議論もまともにし辛いね。
IDなしでもOKの理由ってなんかあるんだっけ？
656 名前：NAME IS NULL mailto:sage [2011/04/15(金) 05:30:37.26 ID:???]: >>653
反映ってのが、ルールを動的に適用するって言う意味なら
ハッピーマンデーや春分の日を動的に適用するのが難しい
逆に、定休日の変更とか考えると動的に適用する方がいいかもしれん
ただ、生成にしても反映にしても、過去分切り捨てないなら
延々増え続けるのに違いはないと思うが

生成あるいは反映されたカレンダーをどう使うかにもよるだろうけど
変更の頻度とカレンダーを使う際のパフォーマンスとか考えると
俺なら適当なタイミングで生成する
657 名前：NAME IS NULL mailto:sage [2011/04/16(土) 00:12:24.94 ID:???]: まさに今度の案件で、FROM年月日、TO年月日で営業日やそれ以外を保持する必要が出た。

祝日などは FROM:2011/01/01 TO:2011/01/01 名称：正月
658 名前：NAME IS NULL mailto:sage [2011/04/16(土) 16:59:35.02 ID:???]: 夏休みでもないと1日単位の方が効率的な感じだな
659 名前：NAME IS NULL mailto:sage [2011/04/16(土) 17:41:05.38 ID:???]: こういうテーブルは差集合を取るために使うことが多いしな。
1日1レコードの方が何かと無難に思える。
660 名前：NAME IS NULL mailto:sage [2011/04/17(日) 09:08:09.05 ID:???]: ここのスレのひとたちのレベルとは違いすぎるんで恐縮なんですが、、、
インデックスって何に設定するのが良いんでしょうか。
たとえば、掲示板の投稿テーブルとかだとなににインデックスを設定したらいいでしょうか
661 名前：NAME IS NULL mailto:sage [2011/04/17(日) 09:13:32.97 ID:???]: 検索キーに張ればいいよ。
662 名前：NAME IS NULL mailto:sage [2011/04/17(日) 09:31:24.55 ID:???]: >>661
検索対象となりえるフィールドってことでしょうか。
今は名前と、本文メッセージで検索できるようにしてるので、
それらにINDEXつけたらいいのかな？
663 名前：NAME IS NULL mailto:sage [2011/04/17(日) 09:35:35.93 ID:???]: 名前はアリだろうけど、本文メッセージはインデックスの意味ないだろうね。
664 名前：NAME IS NULL mailto:sage [2011/04/17(日) 09:59:15.72 ID:???]: >>663
文章が長すぎるからですか？

あと、
postテーブル　（投稿
tagテーブル　（タグ
こういう２つのテーブルがあるとして、
postテーブルに複数のtagがつくような場合（多対多であってますか？）
postとtagを結びつけるテーブルが必要だと思いますが、
このテーブルの名前がいい感じのが思いつきません・・・。
みなさんこういうテーブルは何テーブルと名づけてますか？
post_tag_relation
とかかな？
665 名前：NAME IS NULL mailto:sage [2011/04/17(日) 11:55:47.26 ID:???]: テーブル名はそのものズバリの短い名称ならなんでもいい、SQLでの記述量が全体的に減る。
短くなるならローマ字表記もありだと思う。
666 名前：NAME IS NULL mailto:sage [2011/04/17(日) 12:58:08.73 ID:???]: ＞postとtagを結びつけるテーブルが必要だと思いますが、
そもそも直に結び付かないのがなぜかと問いたいが。
関係性が複数あってアナリシスパターンみたいに知識レベルと操作レベルに分けたいならともかく。
667 名前：NAME IS NULL mailto:sage [2011/04/17(日) 13:26:25.07 ID:???]: >>665
短縮しようとすると必然的に漢字になる。
668 名前：NAME IS NULL mailto:sage [2011/04/17(日) 13:58:57.30 ID:???]: >>666
postテーブル
id title name message
1 投稿テストななしてすです。

tagテーブル
id name
1 タグ１
2 タグ２

post-tagテーブル（ナイスなネーミングが思いつかない）
id post_id tag_id
1 1 1
1 1 2

↑
表にするとこんな感じです。
3つ目のテーブルがないと結びつかないと思いますが・・・できます？？
669 名前：NAME IS NULL mailto:sage [2011/04/17(日) 15:01:12.87 ID:???]: いや、あってるよ。
それと、本文を高速に検索するには形態素解析とか別の技術がいる。
670 名前：NAME IS NULL mailto:sage [2011/04/17(日) 15:05:04.50 ID:???]: >>669
ありがとうございます。
え、%LIKE%でやってて、全く問題なく動いてるんですけど、
書き込み数が少ないからいけてるだけなのかな
671 名前：NAME IS NULL mailto:sage [2011/04/17(日) 17:00:42.33 ID:???]: LIKE句で早いかどうかはDB側のエンジンに依ると思います。
672 名前：NAME IS NULL mailto:sage [2011/04/17(日) 17:19:18.92 ID:???]: ネーミングは、『R_投タ』だろ？
673 名前：NAME IS NULL mailto:sage [2011/04/17(日) 17:31:36.42 ID:???]: 件数とフィールドサイズ次第じゃね？
674 名前：NAME IS NULL mailto:sage [2011/04/19(火) 00:35:20.25 ID:???]: １　業務の区分番号で自然キー設計した
２　削除履歴も残したくて削除フラグを作った（行を複製して削除=1する)
３　削除フラグを立てた行を作るとキーが二つになってしまう！
４　履歴を沢山もてるように削除日を作った
５　（自然キー + 削除フラグ + 削除日）で複合キーに変更した
６　履歴行を除くためテーブルを結合してからwhere句で削除フラグ=0することに
７　クエリを１０段階くらいネストしてモリモリ書く
８　なんかデータが欠落してると思ってたら、INNER JOINしてることに気が付く
９　手の施しようがなくなって俺のとこにお鉢が回ってきた

こんなデータベース管理したくねーよカス。だから女は嫌いなんだ
675 名前：NAME IS NULL mailto:sage [2011/04/19(火) 08:28:01.29 ID:???]: >>674
8はたしかにバカだけど、ほかはまあ
しかたないんじゃね？
676 名前：NAME IS NULL mailto:sage [2011/04/19(火) 15:53:11.76 ID:???]: てか別に手の施しようがなくなってもない気が
677 名前：NAME IS NULL mailto:sage [2011/04/19(火) 21:02:38.78 ID:???]: クエリ10段階程度は、普通とは言わないけどたまにあるなー。
インデックスちゃんとはってたら結構パフォーマンスも出るし
678 名前：NAME IS NULL mailto:sage [2011/04/21(木) 07:14:14.64 ID:???]: > （行を複製して削除=1する)
なんで複製するの？
679 名前：NAME IS NULL mailto:sage [2011/04/21(木) 11:13:26.69 ID:???]: 思うに区分番号を使いまわしたいんだろう
つまり、もともとも区分番号は候補キーじゃなかったって話で、
１から間違ってるってことだな

ただ、
>（自然キー + 削除フラグ + 削除日）で複合キーに変更した
らしいので、別にそれで何とかなるだろって話

そこは自然キーじゃなくて区分番号だろうと突っ込みたいが
>>674は区分番号がキーじゃないとちゃんと解ってるのかね
680 名前：NAME IS NULL mailto:sage [2011/04/21(木) 17:50:16.56 ID:???]: 何のテーブルとどう結合したのかよくわからんのだが、削除日だけだと
日付が絡んだ結合がかなり複雑になりそうな気が。
作成日も加えるとか、それこそサロゲートキー導入か。
681 名前：NAME IS NULL mailto:sage [2011/04/21(木) 17:55:47.87 ID:???]: 削除した事実と日付、元データのログだけなら、削除テーブルに退避させるだけでいい。
682 名前：NAME IS NULL mailto:sage [2011/04/21(木) 21:31:10.43 ID:???]: >>678
よくわからないが、同一テーブル内に履歴があれば管理
しやすいと思った形跡がある。。テーブル開いてすぐ下に
履歴があるので、どう変更したか見やすいとか。

>>679
×（自然キー + 削除フラグ + 削除日）で複合キーに変更した
○（区分番号 + 削除フラグ + 削除日）で複合キーに変更した

書き間違い。すまそ

>>680
最初からそうしとけと

>>681
普通の人間が考えればなそうだな。考えたやつが普通の
人間じゃないから困る。
683 名前：NAME IS NULL mailto:sage [2011/04/21(木) 22:10:23.27 ID:???]: ログ管理用のテーブル設計の難しさは異常
684 名前：NAME IS NULL mailto:sage [2011/04/29(金) 00:43:58.61 ID:???]: ＤＢ設計のコツは、「難しく考えるな。あきらめろ！」
685 名前：NAME IS NULL mailto:sage [2011/05/01(日) 01:24:07.02 ID:???]: >>683
何が難しいの？よければ要件を教えて。
686 名前：NAME IS NULL mailto:sage [2011/05/02(月) 10:42:57.33 ID:???]: >>683じゃないけど、全文検索のこととか考え出して、行き詰まってんじゃないの
687 名前：NAME IS NULL [2011/05/02(月) 17:27:10.54 ID:Ym6L+dps]: モデリングの勉強をしているのですが以下のような場合、どんなモデルになるでしょうか？

商品の卸売のようなシステムで

1．顧客からはは随時、受注がくる
2．ある時点で、受注を束ねて、顧客商品別に発注先に発注
3．発注先が直接顧客へ商品を配送して、完了報告をしてくる

という業務フローです。
自分のシステムでは、受注を受けるだけで、出荷は商品ごとの発注先任せといった感じです。

よろしくおねがいすます
688 名前：NAME IS NULL mailto:sage [2011/05/02(月) 17:33:37.85 ID:???]: 商品マスタと
発注先マスタと
受注テーブルを用意して適切に紐付け

任意のタイミングで商品別に集計出して発注アクション
その時に受注テーブルにあるレコードに発注済みフラグを立てる

おしまい
689 名前：NAME IS NULL mailto:sage [2011/05/02(月) 17:46:15.64 ID:???]: １つの受注には、いくつかの商品があり、その商品は発注先はバラバラです。

受注：キー　受注番号　非キー　顧客番号、配送先住所
受注明細：キー　受注番号、受注明細番号　非キー　商品番号、数量、発注先

発注：キー　発注番号　非キー　発注先、顧客番号、配送先住所
発注明細：キー　発注番号、発注明細番号　非キー　受注番号、受注明細番号、商品番号、数量

リレーションは
受注：受注明細　１：N
発注：発注明細　１：N
受注明細：発注明細　１：１

発注まではこんな感じだとおもっています
690 名前：NAME IS NULL [2011/05/03(火) 00:29:54.01 ID:6I8m/Wta]: >>689
なぜ、「配送先住所」が「受注」と「発注」の両方にあるの？
なぜ、「数量」と「商品番号」が「受注明細」と「発注明細」の両方にあるの？
よく分からない。
691 名前：NAME IS NULL mailto:sage [2011/05/03(火) 00:35:37.80 ID:???]: >>689
一つの「顧客」は、一つの「配送先」を持つの？
それとも、一つの「顧客」は、複数の「配送先」を持ちえるの？

全ての受注は必ず発注されるの？
仮にそうだとした場合、
「商品番号」が決まれば「発注先」は自然と決まるの？

このあたりがはっきりしないと答えがだせないよ。
692 名前：NAME IS NULL mailto:sage [2011/05/03(火) 01:05:27.07 ID:???]: >>687
メインのフローは馬鹿でもできるから、適当に組んでもみんなほぼ同じモデルになる。
ちゃんと考えなきゃいけないのは、返品、誤配送、破損、誤発注、キャンセル、郵送先変更、在庫切れなどの例外処理のフロー。
693 名前：NAME IS NULL mailto:sage [2011/05/03(火) 03:49:27.10 ID:???]: >>692
勉強って書いてあるべさw
そこまで細かくやらんでしょ
694 名前：NAME IS NULL [2011/05/11(水) 23:35:39.63 ID:+dDfImqi]: サロゲートキーってのは調べてみると
「ユーザーが認知しない、業務的に意味をなさない連番とかのキーにせよ。」というのは理解したんだが
このサロゲートキーは検索画面の条件や帳票項目とかに利用していいのかしら？

ユーザーが認知しないという意味では、利用してはいけない気がするが
たとえば業務的な採番ルールがない（ただの歯抜けOK連番とか）伝票番号の場合
システムでは検索条件にもなるし出力項目として利用されていると思う。

この場合、伝票番号とは別にサロゲートキーを持つのか否か。どうおもう？
695 名前：NAME IS NULL mailto:sage [2011/05/11(水) 23:57:54.25 ID:???]: 迷うまでもなく持つわ
696 名前：NAME IS NULL mailto:sage [2011/05/12(木) 00:19:14.93 ID:???]: ＞このサロゲートキーは検索画面の条件や帳票項目とかに利用していいのかしら？
いい。サロゲートキーにする意味は、未来永劫不変で一意であることを保証することだから、
IDとか識別番号とかいう名前で利用することはある。

＞この場合、伝票番号とは別にサロゲートキーを持つのか否か。どうおもう？
伝票番号が一意のサロゲートキーになるならどっちでもいい。
697 名前：694 mailto:sage [2011/05/12(木) 00:37:27.98 ID:???]: どうもです。

>696さんの意見はしっくりきました。
>695さんの、迷うことなく持つの理由は

>いい。サロゲートキーにする意味は、未来永劫不変で一意であることを保証することだから、
がユーザーが認知することで崩れるから。ということかな？

ユーザーが認知すると、ユーザーの使い勝手で「伝票番号に日付入れてくれ！」とか言われたら
未来永劫不変で一意であることを保証できんな
698 名前：NAME IS NULL mailto:sage [2011/05/12(木) 00:45:57.64 ID:???]: 伝票に日付、アルファベット、ゼロ埋めはザラにある変更
699 名前：忍法帖【Lv=22,xxxPT】 mailto:sage [2011/05/15(日) 16:22:26.09 ID:???]: a
700 名前：NAME IS NULL mailto:sage [2011/05/15(日) 20:33:01.83 ID:???]: >>697
キーの一意性が変わるような変更に対して、サロゲートキーが対策になる
なんて思っていたら痛い目見るよ。
701 名前：NAME IS NULL mailto:sage [2011/05/15(日) 21:08:57.72 ID:???]: > キーの一意性が変わるような変更
？
702 名前：NAME IS NULL mailto:sage [2011/05/16(月) 00:34:01.57 ID:???]: 「未来永劫不変で一意であることを保証」できなくなるような変更のことだろ。
703 名前：NAME IS NULL mailto:sage [2011/05/16(月) 03:35:54.10 ID:???]: >>700
キーって何のことだ？主キー？候補キー？

候補キーが、候補キーじゃなくなるような変更がありえるなら
（その前提がある段階で候補キーかどうかあやしいが）
その候補キーを主キーにしないでサロゲートキーを使うのは対策になるわけだが
お前の言う痛い目ってどんな事なんだ？
704 名前：NAME IS NULL mailto:sage [2011/05/16(月) 05:15:31.90 ID:???]: >>703
主キーを追加しなくてはならなくなることだろう。
705 名前：NAME IS NULL mailto:sage [2011/05/16(月) 07:17:25.05 ID:???]: >>704
サロゲートキーを使うっていうことは
当然そのサロゲートキーが主キーになってると思うんだが

サロゲートキーの一意性が保証できなくなるって話なのか？
706 名前：NAME IS NULL mailto:sage [2011/05/16(月) 21:00:42.81 ID:???]: そんな風にシステム内部で発行する人工キーだけが唯一の候補キーになっているテーブル
だらけで、投入するデータがinsertされるべきかupdateされるべきかわけがわからない状態に
なってしまったシステムは見たことがあるな。
キーが無いのと同じことなんで、注意深くやらないと破綻するのは目に見えているんだけどね。
707 名前：NAME IS NULL mailto:sage [2011/05/16(月) 22:50:38.28 ID:???]: >>706
> 投入するデータがinsertされるべきかupdateされるべきかわけがわからない状態に

サロゲートキー関係なくね？
708 名前：NAME IS NULL mailto:sage [2011/05/16(月) 23:00:41.81 ID:???]: 関係ないよ。
「サロゲートキーで一意性を保証」するから大丈夫なんて言えない例。
709 名前：NAME IS NULL mailto:sage [2011/05/16(月) 23:20:15.18 ID:???]: 魔法じゃないんだから、サロゲートキーに何期待してるんだよ (w
710 名前：NAME IS NULL mailto:sage [2011/05/17(火) 00:07:43.44 ID:???]: >>708
いいえ
バカ除けを施しても破綻させちゃう逸材が居る限り大丈夫なんて言えない例です
711 名前：NAME IS NULL mailto:sage [2011/05/17(火) 05:33:39.34 ID:???]: なんで、このスレのやつってサロゲート談義が大好きなん？
712 名前：NAME IS NULL mailto:sage [2011/05/17(火) 06:47:19.90 ID:???]: バカ除け？サロゲートキーしかキーが無いテーブルがバカそのものじゃん。
713 名前：NAME IS NULL mailto:sage [2011/05/17(火) 16:17:28.35 ID:???]: 馬鹿寄せ呪文「サロゲート！」
714 名前：NAME IS NULL mailto:sage [2011/05/17(火) 18:27:09.25 ID:???]: サロゲ廚、自重しろ
715 名前：NAME IS NULL mailto:sage [2011/05/17(火) 21:15:26.73 ID:???]: fjのmalloc/free論争みたいなもんだな。季節の風物詩。
716 名前：NAME IS NULL mailto:sage [2011/05/18(水) 00:23:53.39 ID:???]: >>706
イメージできないから具体例あげてみて

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef