DB設計を語るスレ 3

引き続き語れ！！

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

過去スレ
DB設計を語るスレ
http://pc11.2ch.net/test/read.cgi/db/1166540159/

またサロゲート厨か

T字形ERマスターの俺様が華麗に2ゲット!

有給と勤怠の管理システム作ってるけど、
有給の設計むずいな。前年度の繰越とか

社員　今年残　前年残
A　　　　　20　　　15
B　　　　　5　　　　9

で消化するとき今年残から先に減らせばいいだけ
繰越は単に今年残→前年残、今年残→規定リストからセットで済む

なにそのくそせっけい

どうしろと

簡単なのでいいから勤怠管理の設計載ってるサイト教えて下さい

俺だったら、年次ごとに与えられた日数と消化した日数は別々に保存する。
計算結果だけ保存するのは、俺の感が駄目だと言ってる。

有給テーブル
取得日
日数

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

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

有休残計算はストアドとかで

T字型マスターの俺様、なんとか言ってやってください！

自分達に無い物を作ろうとするから、どう設計すれば良いのか見えないんじゃね?

有休テーブル
+社員ID
+年次（っぽいもの）
+付与日数

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

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

今現在の有休残はストアドとかで

>>13
有給実績テーブルの消化日数って、有給テーブルにくっつけたらダメなの？なんでわけてんの？

13じゃないのに勝手に答えるけど、
それだと付与・消化の属性を追加して使い分けるとか
あるいはrowそのものを書き換える必要が出てくるじゃない

テーブルで分けといた方が分かりやすいと思うな
休んだ日数を細切れでブっこんでおいて、全体の消化日数はID＆年次でselectしてsum取ればいいし

>>14
有給の付与が年度の開始時にしか起こらないって脳内ルールを作ってないか？

つまりそれは回りまわって>>12に帰結するわけだな（涙

有効期限があるポイントを管理しなきゃならんのだわ。
やっぱり1ポイント1レコードかしら？

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

教えてちょんまげ。

直したのかよ
有給ないやつにも分かるように直したのかよ

>>16
有給は半年前倒しで全社員一斉に与えても
いいんだよ。でなければ、入社日から計算。
入社半年で、0.5年度。一年半で1.5年度。
年度は入社何年目かって事でしょ。西暦
じゃないよ。この年度単位でないと、
繰越計算しにくいと思う。だから、年度に
与えた日数と消化した日数持たせていい。

>>15
なんかいまいちその利点がイメージできない。消化日数を持たせた時点で、集計
してrowをその都度更新していくのは
当たり前だし。それに、本当にsumなんか
で繰越の計算できんの？

実際に消化した実績日数だけで良いシステムなら、同一テーブルでもいいけど、
大抵は、事前に申請が必要だし、その申請こみで今現在の残日数を求める必要が
あったりする。つまり、大抵は（案２）みたいなテーブルが必要になるだろうってこと。

そういえば最近は時間単位で年休取得できる会社もあるよな。

時間単位はややこしい。日単位なら
その日の勤怠区分で処理できるのに。
例えば、10時出勤でも遅刻でないとか、
しかし、そのその日の勤務時間は一時間
マイナスで、有給で一時間補充とか、考えるだけで鬱になる

簡単相互リンク集みたいなのを作ってまして
初めてDBをまともに使うのですが、こんな設計で問題ないでしょうか?

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

UserTable
---------------------
UserID　|　Mail　　　　　　　　　| 　Password 　 | 自分のSiteIDs　　　　 |　承認待ち 　　　　　　　　　　　　 | 申請中
---------------------
u2145　　| [email protected] 　| 　 1234　　　　　| s3265,s2664, 　　　　　 | s3526(相手) to s3265(自分), 　　| s3265(自分) to s4377(相手)


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


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

リンク集生成時にURLとタイトルを取得する為に複数のSiteIDを問い合わせるので、心配なのですが
普段はHTMLファイルを生成して追加/削除するときにHTMLファイルを更新する感じにすれば問題ないでしょうか?
アドバイスよろしくお願いします。

>>24
ユーザー毎にテーブル作った方がいい

to に笑った

「s3265,s2664」とかなってるのはカラムの中にカンマ区切りにするって意味？
そんなんDB使う意味ないぞ。テキストデータで持ってた方がマシなレベル。
それに静的データ（マスタ）と動的ステータスは完全に分けた方がいいがごっちゃになってる
それと未認証とリンク切れとか意味が全く違うものを一緒にしちゃいかん。

>>25
ユーザが増えたらcreate table発行か？ありえん。

レスありがとうこざいます。


>>27

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

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

静的と動的はこの場合、頻繁に書き換わるSiteIDが動的?ですかね
UserTableの申請中などの情報は新しいテーブルに作ってみます。

＞カラムに複数の値を管理
配列を入れられるDBもあるけど検索に使いづらくなるのでまずやらない。
そういう場合、RDBは複数レコードで管理する。もちろん行数は多くなるが管理や検索速度のバランスだからしゃーない。

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

SiteLinkStatusTableは申請時１レコード、承認されて相互リンクになると２レコードになる。
未認証→認証を行うのは管理者でいいの？

>>29
すごく具体的ありがとうこざいます> <

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

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

ちょっと私には複雑すぎてSQL質疑応答スレで聞くことになると思いますが
とりあえず寝てから作成してみます。

未認証とリンク切れは一緒でいいんじゃまいか
認証されてなければリンク切れとは判定しないだろうし
0 = 正常 / 1 = 未認証 / 2 = リンク切れ
とでもすれば

まあ、なんにせよ要件次第ではあるが

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

>>31
・未認証で承認しようとしたらリンクが切れてました
・承認してたんだけど、ある日リンクが切れました
の二つを区別して記録したいなら分けておかないとだめじゃね
もしくは別途サイト登録履歴みたいなテーブルもたせるか

皆様ありがとうこざいます

作ろうとしてるのは、ユーザーのサイトに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タイムスタンプを使おうかと思ってます。

UNIXタイムスタンプはダメだ
DATETIME型でカラム作った方がいいぞ

在庫調査のDBを作ろうとしてるのですが、
差分データのようにしないとデータ多すぎて一ヶ月もしないうちに大変な事になってしまいそうです。
エリア、店名、商品名、価格、個数、調査時間
最低限保持しないといけないのが上記項目で
同じ店でも同じ商品名でも陳列が別なら別登録になります。（ヤフオクで同じ商品が同じ価格でずらっと並んでるような）
調査1回につき、20〜30エリア、1〜100店、商品1〜100点、個数1〜100程度になるので単純にDBに登録すると1回で最大時30万行になってしまいます。
これを3時間ごとに調査となると、1ヶ月で数千万行になってしまって現実的ではありません。
なので調査ごとの変化は1割にも満たないので差分の登録の仕方や利用の仕方を勉強したいのですが、
そのような設計例の載ってる本やサイトをご存知ないでしょうか？

差分ってか
ようは在庫変動のトランザクションを持ってりゃいいだけの
話のように思うが

すいませんもう少し詳しく教えていただけませんか？
単に今の在庫がわかればいいってわけではなくて、
調査日のその時間にどこにどんな値段で在庫がいくらかあったか、店自体開いてたか開いてなかったかなどの
そのままの情報を保持したいので、
在庫変動したら値を変えるだけってわけではないのですが、そういう意味でもしおっしゃられていたのならすみません。

もし本当にそのままの情報を保持する必要があるなら
30万件だろうがそのまま持っとくほうがいいだろう
ただし、それを保存している間に在庫が動く可能性があるから
その瞬間の在庫という一貫性は保てないぞ

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

三時間おきのデータを数年も保持しとかないといけないとかいうなら
要件を見直すべきかと

取ったデータで何をするかじゃないかな。
例えばWeb画面でセミリアルタイムで変動をグラフで見せたい（計算させたい）のだったら１クリック５時間のクソアプリになるが、
月に１回バッチで在庫変動情報の帳票を作りたいだけなら全部突っ込んで１億レコードになっても何ら問題ない。

>>33
てか「（申請に添える）メッセージ」が「（サイト間の）リンク申請情報」を持ってるっておかしくなってるじゃん。

>>40
おかしいですか?
SiteLinkStatusTableにメッセージを置くのもおかしいので
MessageBoxTableにリンク申請情報を持たせてしまえば楽かなぁと
(メッセージ消したらリンク拒否みたいに)

UserID MEDIUMINT NOT NULL AUTO_INCREMENT
SiteID MEDIUMINT NOT NULL AUTO_INCREMENT

>>38
要件見直すことにします。
>>39
そのクソアプリに近い感じなのでリアルタイムなものと、日間月間変動情報なものとわけて考えて見ます。

これ見てよ↓
http://livedoor.blogimg.jp/tekepo/imgs/3/4/3414dfca.jpg
ばらまこうぜ！

最近DBの勉強をし始めたのですが
通し番号　社員ID 社員名　製品ID　製品名　登録日時
のような列があった場合、通し番号　社員ID　製品ID　登録日時のテーブルと他2つに正規化できますが、
検索するときに必ず名を利用する場合（社員名、製品名、登録日時を取り出すのがメインの利用方法）、
サブクエリが増える分検索が遅くなると思うのですが
こういった場合でもテーブルって分けるべきなんでしょうか？
社員ID、製品IDを利用する事はほとんどありません。
正規化するとDB容量は節約できますが、利用時の負荷が増大するのでデメリットに感じます。
それともサブクエリ増えてたとしても、列が少なくDB容量が小さくなるようにした方が速くなるでしょうか？

やってみないと判らないと言われればそれまでだけど、

そんなに心配しないとイケないほど検索が遅くなる？負荷が増える？

初心者なら型通りにやれ。
パフォーマンスを気にするなら、テーブル設計に手を入れるのはSQLチューニングで
改善の余地があるかどうか自分で判断できるようになってからだ。

>>45
パフォーマンスのための非正規化なんてのは最後の最後の最後の手段。
社員数が1000万〜1億人もいるならそれもありかもなー、なレベル。
考えるのがムダとはいわないが、悩むのはムダ。

最終手段なんですね・・・
まずは基本どおりの設計を覚えて経験していくことにします。ありがとうございました。

>>48
プロフを参照したところこの方、銀歯を作る仕事（ﾌﾟｯ）をなさっていたそうで（苦笑）
道理で、物作りの厳しさ、商売の難しさどれを取っても何一つ理解しておらず、突っ込み所満載なわけです
しかも過去形である所を見ると景気に関係なく黙ってても患者が来る、
病気や虫歯を直す商売でさえ勤まらなかったということでは（笑）
銀歯と金型では要求される精度も品質もまるで違います
質問者が何を作りたいのかが明らかにされていないため分かりませんが
趣味のようなもの、とおっしゃるなら趣味の掲示板で相談されたらいかがでしょうか
その分野の同好の士が良い方法をご存じかもしれませんから
もちろん、趣味の世界といえども技術は只で教えてもらえるほど甘い物じゃないという事をお忘れなく

どこの誤爆？妙に番号だけあってて笑える。

enumを使うか、マスタ化するかについて。
http://www.developer0000.jp/2008/11/08/3163/
http://blogs.wankuma.com/ognac/archive/2009/09/07/180928.aspx

全部をマスタ化すると無駄な感じがするのは確かだけど、
表示順や表示名、ロジック分岐フラグなどのパラメータをもてる。
マスタ化しておくことでアプリ内のswitch文を減らすことができる場合
も多々あるので、基本的にはマスタ化が好きなんだけどどう思う？

英語⇔日本語
みたいな対応表を作る時のようにどちらも主キーになるような場合は
どちらかを主キーにしてもう片方もインデックスする感じになるんでしょうか？

別の連番のキーをつけた方がいいんじゃない？

>>54
ＩＤ　日本語　英語で全部ユニークインデックスってことですか？
ＩＤは使う予定ないのですが将来に備えてということでしょうか。

日本語と英語はユニークである必要無いんじゃない？
確実に1対1なの？

>>56
確実に１対１です。かぶることはありません。
商品名の日本語⇔英語⇔中国語⇔ドイツ語とあるとして
日本語から英語、ドイツ語から中国語みたいに検索したいんです。

かぶらないって空欄も無いってことか
でも連番の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'

商品名の対訳表なら、商品の主キー＋言語コードで主キーにするな、俺なら

>>59 >>60
なるほど。これなら言語増えても列増やさなくて済むんですね。
こういうの自己結合って言うんですね。
自己結合って知らなかったので調べてみます。
いま全く知らない状態だと select Message, Language from Locale where LocaleID = 3
の方が速いんじゃないの？とか
行数増えると結合してるから遅くなるんじゃないの？とか思ってたりします。

自己結合知らんような初心者がパフォーマンス考えるとかムダだから

>>62
はい。ベテランの方々が提示したものが初心者の私が考えるより確実にいい設計だと思うので、
そのまま使おうと思います。

create table locale (
localeid int,
jpn nvarchar(100),
eng nvarchar(100),
doitu nvarchar(100),
china nvarchar(100)
)

↑
メンテしやすい

それはないわ

俺はその形大好きだがｗ

>>66
なんでないと思うのかな。必ず全部の言語のデータを一対一で作るという前提なら、ありだろ。

だってdoituだよ？

>>66
将来にわたって言語の追加変更削除がないことが担保されるならありだと思うが

add columnしとけ。

>>64
要件変更時に悲惨なことになりそうな予感しかしない。

chinaだけちゃんとしたフルネーム

あ、フルネームって前に付くあれは無しで

ごく基本的なテーブル設計の話なんですが。

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

こういうのが↓依存リレーションで
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せず。

実際に両方で作ってみたらいいじゃん。
どっちもhouse_name village_nameを何度も書くはめになることに気づくよ。

それでもいいんだ！っていうなら1テーブルで作っちゃえばいいと思う。
「いちいち」player village houseを分ける必要ないでしょ。

あ、各テーブルの関係は1:Nです。情報後出しで申し訳ない。

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

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

↑に追加で書いたのは、N:Nのときに使う、と。
（逆に言うと1:Nのときに使うメリットは特に無いと思う）

ごめん見落としていた。
>>75の後者って、一つの村は一つのユーザしか所有できないという制限になると思うけど
それはそういう仕様？
ならそれでもいい。

前者は正規化すべき対象がある(かつ、それが煩雑になりすぎない)のに
やらないというところが20年前なんじゃないかな。

>>78
そこは（遅れましたが）1:Nなので仕様です。

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

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

…いや、それこそ両方組んで実データぶっこんでテストしなきゃわからないか。
結局どちらが是かは要件次第、なのかなぁ。

1:Nなら前者にする必要がないんじゃ？
> villageテーブル：primary(player_id, villege_no), village_name, ...
に、unique(village_no)をつけて1:Nであるとアピールしてもいいけど。

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

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

あと、誰も所有していない村や家はどうなるの？

あれ、俺疲れてんのかな…

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

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

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

ちなみに質問では親ー子ー孫の３層にしましたが実装は４層。
前者にするとキー長が長くなって検索にはむしろ不利なのか？

後者は外部キー制約あるんだから、家があるなら村はあるはずだし、
村があるならプレイヤーはいるはずになっているよ。

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

依存リレーションという言葉も知らなくてなんだかごめん。

で、今依存、非依存について調べたわけですが、

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

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

ということなんじゃないのかなーと。

PG的には村や家に確実にユニークなIDが振られてる方が楽だと思うが。逆引きするにしても。
「前者のvillege_noやhouse_noも実はユニークなんです(ｷﾘｯ」なら糞設計と呼ばれても仕方ないと思うけど。

どう考えても後者の設計だな。前者のが古いかどうかは知らないが、親子関係が変更になった時に主キーに触らないといけないのが気持ち悪い。

うーむ…。よし、ここは経験と思って、後者で実装することにします。
すでに前者で組んでる最中の、取り返しが付かない段階のシステムがあるので、
違いを肌で感じることにします。

ありがとう御座いました。肌で感じたあとブログにでもまとめようと思います。

てかもっと新しい（？）というか安全なのは、「プレイヤー-村」関連テーブルと「村-家」関連テーブルを別途作ることじゃないかね。

>>87
それが>>77で追加したやつのことなんですけど、
N:Nならそうせざるを得ないとして、
1:Nでもそこまでします？

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

1:Nなので、「プレイヤー村」関連テーブルと「村」テーブルの
件数って完全一致で、「なんのために２テーブルに別れてんだ？」って考えてしまうのですが。

その程度でパフォーマンスが気になるほど更新が頻繁なのか？

更新はそれなりに頻繁、件数が億単位を想定。
パフォーマンスのために多少の開発効率を落とすのも辞さないレベル。

んな条件を後出しすんじゃねぇよｗｗｗ
億単位レコードのテーブルは非正規化されてる方が普通なくらいだろｗ

で、ですよね。すいません。

それを先に出すべきとか言うところに頭がピンと来ない人間が
億単位システムのDB設計をしているという…。

ていうかそれ何のDB？

MySQLです。

まぁ最初はよほど負荷が見えてるところ意外は基本的に正規形で考えて
後から発覚した負荷について非正規形にする感じで考えてる。

それがもしモバゲとかグリーとかブラゲならDB以外にも抑えておかないといけない点がいくつかあるんだけど
その辺は大丈夫なのかね。

そのへんは肯定も否定もしないでおくけど
memcache使うとか基幹システムAPIは極力叩かないとかは抑えてるつもり。
まぁスレ違いにもなって申し訳ないのであくまでDB設計の話を、と。
ご忠告感謝。

そっか。それなら、だいじょうぶかな。DBも分散を検討してね。
うまく行くことを願っているよ。

MASTER、SLAVEの分散もありました、忘れてました。
あとコネクションを極力短く、少なくとか。状況次第じゃいったん切るとか。

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

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

取り返しがつく今のうちに修正に入ることにします…。

今どき複合キーはないわ。
オブジェクト指向とかORM(Object Relational Mapping)とか考えるとサロゲートキー一択っしょ。

あと、１：Nなら関連テーブルは不要だね。

俺なら前者にはしない。
なぜなら、playerが所有しない村も（今は無くとも）存在するだろう（かもしれない）し、家も同様。
また、所有者が変更になるとき、pkeyの更新になるのはいただけない。

複合キーとサロゲートキーって、
具体的にどう違うの？

サロゲートは完全なキーであるためだけのキー。

>>102
単独か複合かは関係ないんですね？
ユニークと同じ意味と思っていい？

>>103
何で調べないの？
Wikipediaでもある程度わかるのに。
http://ja.wikipedia.org/wiki/%E4%B8%BB%E3%82%AD%E3%83%BC

サロゲートキーは「本当はいらないはずだけど、どうしても作らなければいけない」
というイメージがあります。
ダミー列がprimary keyのような感じ。

祇園精舎の鐘の声
諸行無常の響きあり

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

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

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

サロゲートキー、それは自然キーの否定。

>>105
あんたの感想はわかった。それで？

いやまぁ合ってるよ
業務要件上はいらないけど、システム要件上は必要なので
ダミー（ユニークネスを保証する以外に意味のない）列を追加するわけだから

まーた始まった

>>107
ごめんなさい。

>>109
ん？まーた始まったって？

私は初めて書き込みますが、サロゲートキーは一つのデータベースで必要な部分と不必要な部分があります
必要な部分では必ず適用します
不要な部分では使用しません
何故必要な部分で使用するかというと使用しなかった時に大変困ったという経験則に基づくものです
不要な部分というのはデータベースごとで違うでしょうが、使用しなくても大して困らなかったという経験則に基づくものです
つまり必要無いと思う人は使わなければ良いし必要だと思う人は使えば良いだけじゃないでしょうか

>>111
「必要なとき使う、不要なとき使わない、その基準は経験則」
そんな情報をネット上のフォーラムに残すことに何の意味がある？誰の参考になる？

どうせならその経験則を少しでも、ほんの一部でも噛み砕いて置いていってくれないか。

>>111ではないが、RDB的なサロゲートキーってのはその名のとおり長大な
複合キーなど取り回しに難がある場合に代理として用いるものだろ。どのくらいで
「難がある」かはケースバイケース。
ただし、>>108の言うような「ユニークネスを保証する以外に意味のない」キー
というのは本来のサロゲートキーとは違って、OODBのIDのようなもの。
こいつらはデータモデルがそもそも違うんで、ごっちゃに議論すると発散する。

顧客が決める気持ち悪いコードに対して
それと１対１になるように一見意味のなさそうなIDを振りなおすのがサロゲートキー。
（あとから仕様変更によって、１対１じゃなくなる可能性があるが）

単にテーブル設計の都合上の複合キーに対してIDを振りなおすのは
ちょっとわけが違うということか。

いや、どっちかっつーとサロゲートキーというのは後者。
また、前者で1:1でなくなる仕様変更というのは、RDB的には「そんな仕様変更があったら
従属関係が変わってるからテーブル定義を変更せずに済むとは限らんだろ」となる。
これが有効なのは、OOあるいはER的に「オブジェクト/エンティティ境界はそれが持つ
属性やその関係よりも安定である」という前提でそのように設計した場合の話。

サロゲートキーが必要／不必要で論じると、
複合キーを認めないという前提でないかぎり、すべて不必要だと思うが

ただ単に取り扱いが楽かどうかだけの問題以外に必要性があるなら教えてほしい

ニコニコ動画とかのタグ付けって
ひとつのカラムに空白区切りとかで押しこむのが普通なんでしょうか?

>>117
動画テーブルと、タグテーブルの間でN:Mの関連を構築すればいいんじゃないの？

>>118
ありがとうございます
勉強してきます > <

http://q.hatena.ne.jp/1152280193
仕事でやってるとこんな風に考えられるのか・・・
アマだとまったく思いつかない; ;

実際の仕事ではpopular_tagsとtagsテーブルは合算されるよ
なるべくテーブル数は減らして結合処理のボトルネックを減らした方が後々いいからね

減らす為にpopular_tagsを作ってるんじゃ。。

え？

数学

>>121
>なるべくテーブル数は減らして結合処理のボトルネックを減らした方が後々いいからね
やめてくれ

初心者は結合すると遅くなると本気で信じてる奴いるからな。

ド素人が第三正規化にこだわるのをよく見るな

> 結合処理のボトルネック
SQL書けない馬鹿の言い訳

あるあるｗ

>>120
相変わらずhatenaはレベルの低い回答が多いな

SQL書けない人にJOINさせると開発工数のボトルネックになる(笑)

>>120をよく読まずに>>121が反応してるので話がかみ合ってないだけじゃね？
popular_tagsはタグの種類じゃなくて集計用のテーブル。
目的は精度や時系列の一貫性を求められないが頻繁に参照されるデータの取り扱いのためであって、
正規化やそれを崩した場合のＪＯＩＮのパフォーマンス云々は関係ない。

集計のためのカウントアップの前にjoinする必要がある
結果を表示する時もjoinする必要がある
結論：無駄

おｋ？

>>133
だからさ、どういう仕組みのシステムを想定してるかで変わってくるのだから、
その辺を明確にしないと話がかみ合わない。
それぞれ違うものを想定して結論だけをあーだこーだ言っても仕方ないだろ。

あのさ、普通に考えてみなよ
カウントアップの時はユーザがタグを入力した時
そのタグ名を判定しつつカウントアップしないといけない
つまりjoinまたは過剰なクエリ発行を伴う

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

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

たのむから億単位のレコードを扱ってから物申してくれ
こんな設計をする奴は経験が浅い

>>135
じゃ一つシナリオを挙げよう。
popular_tagsテーブルはいらない。tagsをgroup byすれば済む。
ただこれを人気タグの一覧を表示するごとにクエリするとコストが高い。
それで１０分おき位にgroup byのクエリを行い、popular_tagsテーブルにキャッシュしておく。
場合によってはRDBではなくアプリケーションサーバー内のメモリにキャッシュしてても良い。

>>121
>実際の仕事ではpopular_tagsとtagsテーブルは合算されるよ
合算って何？

>>135
ずれてない？

所与の条件は、タグは自由入力形式で１つのコンテンツに対して複数付けられるってことだよね。
人気タグに関しては検索数（参照数）が多いのか、付けた数が多いのか明確にされていない。
また集計期間を設けるかどうかやその期間についても明らかにされていない。
検索数の場合はカウントアップが必要になるかもしれないが、
付加数ならば>>136の方法が妥当じゃないかな。
>>135の想定しているものがいまいち分からないが、
それぞれのテーブルが１：１：１でとか考えていて、
タグ名と参照数をわざわざ３テーブルに分けるのは無駄だとか考えているのだろうか。
>>136のはコンテンツとタグが１：ｎ、人気タグテーブルが独立して存在という考え方だろう。

>>127
第三正規化が正確に出来てから言え！！
まずこだわることが大事だぞ。

>>127のはできないやつのいいわけだからｗ

121みたいな何も知らない馬鹿はおいておいて、人気タグのようなケースはデータ構造というよりアプリ依存の話だから、ごっちゃに話すと混乱するでしょ。

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

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

hatenaの回答者はそれを一緒くたに回答しているので話がややこしくなってる。

ﾅﾝｶﾜﾛﾀｗ
どんだけ一人の書き込みを気にしてんだよｗ

一人の書き込みに食いつかざるを得ないほど、ネタがないｗ

アクセスコストがストアドで解決できるとかw

>>121は、元コボラーだな。

元コボラーが設計したテーブル設計って酷いのが多いんだわ。

>>145
アクセスコストの話は下段だろjk

121の人気に嫉妬ｗ
たぶん合ってるから人気なんだろうなｗ

2ヶ月も前の話題を引っ張るなよ。それにしても>>121大人気だな。

いまどき一般的な規模のRDBでテーブルの結合がボトルネックになる、なんて書いたらそりゃ人気も出るw

>>147
下段って？>>142本人なら解説ｷﾎﾞﾝ

>>146
元コボラーには有償研修のSQL入門程度は行かせた方が良い。
わずかな投資で使いものにならなかった人材が使えるように
なったらもうけもの。

汎用機ではこうだったからだ、、、
と仕事を妨害することも少なくなれば一石二鳥。

COBOLにOCCURS項目があるといのがCOBOLとSQLの相性が悪いところなんでしょうかね… w

それだけではないでしょうけど

SQLというより、テーブル定義の問題だがな
COBOLのようなISAM編成に向いたテーブル定義と
RDBを前提としたテーブル定義は違うってことだ

ある製品を作る時に使用する部品をDB化したい。

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

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

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

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

>>155
将来、部品点数が絶対に増えないといえるのなら、
非正規化でもいいかもね。

将来、部品点数が増えたり、階層化する可能性があるなら、
正規化しといたほうが、後々潰しが効くと思う。

>>156
どうもです。

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

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

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

悩む…。
非正規化はテーブルの見た目がださい所も気になる。

>>155
非正規化の場合、部品のステータスに修正入ったら一括変更でもするつもりか？
データ構造が変わらない（商品を構成する部品の点数や構成が将来的に変わらない）としても、表示するフロントエンド（アプリ）は色々変わったり、
他の場所で使われることがあるから、素直に正規化しておけ。
非正規化されたデータをもとに他の人間がフロントエンド作るのは非常に面倒くさい。

その程度のクロス集計のコストが高くなるというのは、そもそもの設計か実行時のSQLに問題があるだけ。

>>157
＞非正規化はテーブルの見た目がださい所も気になる。
開発者の感覚としては、これにつきる。
その程度のテーブルなら、どんな構成
でも実行速度は変わらんだろ。

捨てコードでもいいから突貫で、と
いうのでなければ、個人的に非正規は
ありえない。

>>157
非難だけしてもなんなので、現実的な方法を。
仮に出力の（クロス集計の）コストが高いというのが問題であるならば、部品構成の変更などが頻繁でない限りは（今回のケースはそうだと思うが）、
部品の変更や修正、追加をトリガーに出力用のデータをテーブルなりファイルなりに吐き出しておけばよい。
最終形でなくても、計算途中のデータを出力しておけば実行速度の問題はなくなるはず。

大手のデジカメの階層化されたPDMで実際にやってる。

なんでこうJOIN一発するだけでレスポンスが"だいぶ"悪くなると思う奴がDB設計とかやってるんだろう。

つかこれ、かならず部品１〜２０までを固定で取り扱うというなら
横に１〜２０まで並べても非正規化だとはいえない気がする．．．．

が、俺なら絶対実テーブルを部品１〜２０まで繰り返したりしない
部品点数が増えたときに非正規化が工数的に有利だと思う考えが理解できん
毎回別途に集計するのがめんどくさいというのも、いまいち理解できん
ビュー使えよ。最近のＤＢＭＳなら>160の言うようなワークテーブル的に
使える実体付きビューを使えるものもあるんだぜ

テーブル名を日本語で作るのは駄目かな？

出来るけどやめておけと言われるはず。
日本語が入力出来ない状態でメンテナンスするってなった場合、手段が減る。

特別な理由がない限りASCII文字で作って老いた方が無難。

どっかで、日本語を推奨してる人を見たことがある。
今はO/Rマッパーやらツールやらがいろいろあり、
テーブル名や項目名を直接タイプすることが少なくなったから、
（日本人しか使わないなら）直感的な日本語のほうがいいとか言ってた。

わりと賛同できるのだが、やっぱ怖いもんは怖いよなぁ。
こんなことで変なリスク抱えたくないわ。

>>165
>O/Rマッパーやらツールやらがいろいろあり

色々あるから、むしろ TBL0002345 みたいなテーブル名でも最終的にはさほど困らないと思うんだが。
テーブル名や項目名が直感的に把握できる必要があるものに関してはVIEWなりストアドで作ればいい。

>>165
全く賛同できないんだが。
ていうか、何を言ってるんだ？って感じだ。
そんな奴が近くに居たら、ぶちのめしてやりたい。

>>167
論理的な意見が聞きたい

>>168
>>164の
＞日本語が入力出来ない状態でメンテナンスするってなった場合、手段が減る。
これとか
charset問題とかだろ

>>168
OSやらDBやらアプリやらで、文字コードを統一しないと怖くて使えない。
プログラムを組んでいる最中に、いちいち全角入力モードに変える必要がある。
　　（絶対に、全角スペースをコードに記述してしまってコンパイルエラーとなる頻度が多くなる）
半角と全角の区別がつき難い。
　　（例えば、"1"と"１"はパッと見解らない。）

あと、O/Rマッパーやらツールやらを使うことが出来ない場合のことを考えろ。

コンパイルエラーなんて別に構わないだろ。その場で分かるんだから。
怖いのは潜在的なエラーとしてバグを引き起こすこと。しかも数年後とか、改修時に。
後は抽出条件が実は間違っていた、とか。

簡単な人材派遣システムを作りたいのですが、空き人材の抽出方法に悩んでいます。

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

また各人材が稼働日空き日を保持するのと、先に競合タスクを判定して
従事者を除外するのはどちらが一般的なやり方でしょうか？

業務で人材派遣システムを覗いたことがある。

人のアサインはアサイン管理テーブルみたいなので運用。
基本はDELETE→INSERT、少しでも期間が被った場合はエラー、
前の予約状況をキャンセルしない限り新しいアサインは不可。

管理テーブルでDeleteは乱暴なので、更新日時が最新なものをピックアップでよい。案件確定後なり一定期間後にログとして出力してクリーニング。

>期間が被った場合はエラーについては
どう判定するのでしょうか？

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

日付に従業フラグを立てる場合は新規開始〜終了までの日数分ループを回して
一日ごとに競合判定することが考えられますが、せっかく規則性あるのに
200日なら200個データを持つのは実用的なのかスマートでないのか…（柔軟にはなりますが）。

bitフラグ判定で言いじゃん
db問い合わせも出来るし何が不満なんだ？

給与計算ソフトで「社会保険料等控除後の額」とか
日本語の述語を使いまくった身としては日本語名を支持したい。

文字コードはUnix系では怖いけど.NETならまず心配ないし。

.NET言語の変数名なら問題おこさないけど
Oracleの列名で日本語はいろいろ問題あるからなぁ

>>155
>[正規化]
>作成No,製品名,合計,作成日,コメント
>部品No,作成No,部品,個数,単価
遅レスだが

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

実はこう？
面倒臭いな

.NETもLINQが使えないVS2005あたりで開発すると、正規化は諸刃の剣

>>178
> Oracleの列名で日本語はいろいろ問題あるからなぁ

なんか定期的にこういうやつ出てくるけど、具体的な「問題」とやらは
書かないんだな (w

最初に入った会社のDB設計は、列名日本語でやってたな。
優秀な人はいたけどガラパゴス状態な感じで、
今になって真似しようとは思わないけど、それなりにちゃんと動いてたよ。
Windowsオンリーの環境だったのが良かったのかもしれんけど

だから、クローズドの環境なら日本語だろうがドイツ語だろうがハングルだろうがサンスクリットだろうが問題ないんだってばさ。
問題がおきれば随時つぶせばいいだけだし。

環境が頻繁に変わったり、他との連携で様々なドライバ使う可能性があったり、フロントエンドがガンガン増産されるような環境なら、
動作保障内でやるのが定石。

それ Oracle の問題じゃねーだろ。

そもそも動作保証云々以前に「環境が頻繁に変わったり、他との連携で
様々なドライバ使う可能性があったり、フロントエンドがガンガン増産
されるような環境なら」日本語なんか使う奴は馬鹿だろ。

>>181
文字コードの問題があるだろ。
日本語にしてしまうことで、文字コードがEUCなのかUTF8なのかSJISなのかを気にする必要が出てくるんだよ。

Windowsならまだしも、UNIX上からSQL文を叩くのに日本語入力することなんてありえねぇわ。

そんなん今時utfやん。
大体おまえんとこは実機で直接SQLたたいてんの？w

>>185
何年前の話をしてるんだ？

わかるわかる。ASCIIのDDLもってけばどんな環境の上でも構築できるよねｗｗｗ

試さずに聞くが、NLS_LANG=Japanese_Japan.UTF8でDB作れば
「�ａvとかを列名に含めても問題起こさないのか？
場合によって""で括る必要があったりなかったりで面倒なんだが・・・

何か問題を起こしそうな文字コードなの？

>>189
問題ない。



と言われれば信じるのか？ｗ

>>191
それ、頭悪いレスの筆頭候補だと思ってる。

>>186
OSはUTF8で、DBはSJISの環境が多いだろが。
勿論、実機でSQL文を叩くことが多いね。

DBがSJIS

OSがUTF8でわざわざDBをSJISにする理由がないだろｗ
一昔前はOSがEUCでDBがSJISなら結構あったと思うが。

得意先別の締日を登録する場合，例えばデータ型をIntとした場合，
月末締めはどのように表現するのがいいのでしょうか？
よく，月末は99として登録するなどのテクニックがありますが，
どのような方法がいいのでしょうか。

３１でいいと思うんだが

31だと末尾を指定したかったのか31日を指定したかったのかが読み取れない

31で十分
なんかの時のbitフラグ使用時もちょうどいいしな
99とか今時あるのか？

それを区別する要件があるなら違う値にすればいい
俺にはそれを区別する要件は思い浮かばない
３１日締めの指定って、２月とか４月とかの締めどうするんだ？

>>200
2月や4月の時に32指定だったら末日だとわかる。
31だとユーザや別システムの入力ミスかもしれない。

31=月末
入力ミスとかDBでやるならトリガーで見張れよ
基本だろ…

>>201
それは入力ミスってるんだから別問題だろ
そんなの救ってやる必要ないと思われる
たまにそういう仕様外の動作をコードでキャッチしようとする奴がいるけど
問題の切り分けができてない

>>201
入力ミスって、３２でも入力ミスの可能性はあるわけだが？
結局３１でも３２でも、その月の末日で締めるわけだろ
わざわざ３１日締めという、月末締めとは別の状態が必要か？
それを正しく区別する設計というなら、指定日ごと締めと、月ごと（月末）締めの
締め区分みたいなものを別途用意するのが正解だろうな

多くのレス有難うございます。31を月末締めとすればいいようですね。

>>205
いやー、仕様を確認したほうがいいと思うぞー
そもそも２９日締めとかって設定も入るようにする気か？
その場合２月とかどーすんだよｗ
本当は１日と１５日と末しかねーんだろ？
もしくは日付＋例外条件とかなってたら日にちで保存はヤバイかもしんないんだぞ
俺が前までいた会社は月の最期の営業日が締め日（技術者向けの）だったぞ
ただし、四半期の月じゃねーときは次の月のはじめの営業日までがセーフ・・・とかそんなんだ
複雑だろ？ｗ

もっと実務について詳しい担当と話合えよｗ
こーゆーのってディスプレイといくらにらめっこしててもダメだと思うぜ

それ、締め日じゃない何かと勘違いしてないか？
セーフとかなんだそれ。

仕様を確認した方がいいのは確かにそうだが
>206の話は締め基準日と、稼働日とか絡んだ実際の締日は別ってだけの話だ
今問題にしてるのは、締め基準日が月末の場合にどう保持するってだけの話
そっから実際の締め日をどう算出するかはまた別の話

仮に締め日が来月の１日だったときって日付保存ってダメじゃね？って言ってほしいの？

>>208
すでに実務として１〜３１日って指定のが珍しいのに
これを継続して使うのってどうだろ？
よくある締め日と多少の例外ぐらいはサンプル集めたほうがいいと思うね

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

だったら折角１〜３１日まで入るようにしてあっても大半が無駄なわけじゃん
もうステータスでいいんじゃないの？
ステータスなら第二金曜日とか対応できるよ

わかった！varchar型にして末日だったら「末日」って登録すればいいんじゃないかな？

もう割り切って、テキストにすれば。

>>211
素直が一番ってのは俺の長年のＰＧ経験で学んだこと

ある売上が何年何月の第何週に起算されたものか、って言うのをシステム上で
表示して欲しいとか言われて、馬鹿正直に作ったら、
お盆期間は必ず8月の1週めに含む、とか、年末年始は〜
とか色々なルールがあって結局全部コードに書いて何とかした。
今も動いてるのかなぁ、あのシステム。

意外に盛り上がっているので，ちょっと驚いています。

マジレスすると，都度請求なので，単に得意先の締め日がわかればいいだけなので，
あまり複雑には考えていませんでした。確かに，複数の締め日があったり，
締め日が変動するケースもありそうなので，まじめに考えると頭が痛いですね。

売り上げの起算日とお盆期間がどう関係あるのかよく分からないや。
今年だったら、8/1-8/7がお盆になるとして、8/3の売り上げはそのまま
8月の第一週に起算されたものなんじゃないの？

こういう仕様は日本のSヨの飯のタネだからな。

いやだから8/13〜15に立った売上は8月第一週換算とかそんな感じ。
8月12日はお盆期間じゃないから第二週換算だけど、とか。

あ。
お盆期間を8月1週とする、かと勘違いしてたorz
スマンカッター。

>>217
サマータイムとか旧正月とかあるし日本に限らないような気も。

得意先マスタに訪問履歴1、訪問履歴2、訪問履歴3というカラムが。
何がしたいのか聞いてみたら、1回目の訪問時の内容を〜、とのこと。
俺「3回以上訪問したら。。。？」
相手「その辺は運用で何とかします。大抵は3回分保持できれば十分ですので。」
だとさ。

>>220
なんとでもなるのに何を難しく考えているんだろうな？ｗ
素直に訪問履歴ｘＮ回になっても大丈夫なように作ってくれって言えばいいのにｗ

履歴とかいうから全部残さなくていいのおおおお？と思っちまうけど、要は「初回3回までの訪問日時」だろそれ。
最初の数回の挨拶とか紹介だかの日時のメモ書きであって、4回以上は捨てて問題ないってこと。
RDBとしてはうんこだけど実運用考えればそれはそれでありだろう。

ほんとにメモ的な情報で良ければそれでもいいのだけど、
あとからとんでもなく重要な情報であることが発覚して、
大改修を迫られることになる。
さらに下請けの悲しさか費用は込みこみで；；

大改修よりも運用で何とかしていたものを移行するのが死にそう。
過去データ登録機能を作って客に入れてもらうかｗ

SQL質疑応答スレから誘導されてきました。
http://hibari.2ch.net/test/read.cgi/db/1274791771

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

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

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

よろしくお願いします。

追加です。あんまり関係ないかもしれませんが。
先月の購入金額に応じて顧客にグレードがあり、
１万円以上の購入者は基本ポイントがｎ＋１％、
５万円以上の購入者は基本ポイントがｎ＋２％などとなります。
これもDBに格納させたいです。

いや
肝心のなにが聞きたいのかがわからんし

どういったテーブルの設計をすれば最適か伺いたかったのですが。。。

「倍率が高いほうを優先」と「さらに」の2パターンしかないのかな。

>>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:
曜日キャンペーンに期間は必要ですねぇ。
いまはまだ付けてないです。
参考にさせていただきます。

それでは、スレ違いだったようなので、別スレにて再度、投稿してきます。

それぞれのキャンペーンで、パーセンテージを「５％に置き換え」「３％加算」「ｎ倍にする」といった種類をつけたいです。

キャンペーンで、決算キャンペーン12月は＋５％、クリスマス期間は「さらに＋５％（計１０％）」「１０％に置き換え」といったような、
期間が重複する場合も、期間の範囲が広いほうから狭いほうに順に計算したいです。

キャンペーンテーブル作って
買い物ごとに適用されたキャンペーンＩＤ入れておけばいいだろ
±Ｘが％なのか○円以上で〜なのかは多分ルールが変わるだろうからその辺は
その都度でいいんじゃね？（f(x)の形）

複数のキャンペーンが適用される場合は？

>>233
>>232に対してのレスだろうか。別途テーブル起こせってことじゃないかと思うんだけど、
そもそもの主眼は適用されるキャンペーンを楽に取得することだからなぁ。

別テーブルかぁ。
１２月３日になって、「そういえば今月は決算キャンペーンだと発表してたのに、システムの設定忘れてた」
って場合はどうする？

いまキャンペーンテーブルは日別、曜日別、期間別の３つに分かれているわけだけど、
これを１つにまとめちゃうスマートなアイディアは無いの？

まとめればいいじゃん
開始日付,終了日付,キャンペーンID
そういう〜別とかいうのは月次処理でやりゃいい

発表した時点でキャンペーン情報を登録しておくべきだよねぇ。

忘れてた時どうするといわれても、どちらかというと別テーブルで保持したほうがバッチつくりやすそうには思うぐらいで、
めんどくさい作業が待ってることには違いないかな。

このスレ質問者はIDを出す文化がないのか、とおもったけど質問スレじゃなかったな

そもそもDB設計なんざ枯れてるんだから迷う要素なんてないだろ
設計というのも恥ずかしいぐらい簡単

簡単すぎて書く気にもならないってレスはまだか？

>>233
複数登録できるようにしたらいいんじゃない？っていうしなきゃダメだな
なんのキャンペーンが適用されてこの値段になったのかわからないとか最悪の結果だ
計算によって％だけ出して会計すませりゃいいって問題じゃないだろ
下手したら脱税で訴えられそう

売り上げテーブル
+ID
+売り上げ金額
+ポイント額

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

みたいな感じ？

しらね
どういうＤＢ作りたいのか詳しく知りたくないからよく読んでない
キャンペーンは確実にその日すべての買い物に適用されるとかなるのか仕様がよくわかってない
タイムサービスとかないんだろか？とか結局なんの統計とりたいの？とかよくわかんねーし
やっぱ、この辺は担当者とお話してちゃんと仕様決めないとね

一般的な〜ってないと思うよ

え、今日ポイントどれくらいつくの？ってのを取得しやすい設計を知りたいんじゃないの？
俺はそれに応じたレスをいくつかしてはいるんだけれど。

統計とか何の話だろうって思うわ。

>>245
追記で購入金額に応じたポイントまであるんだから全売上の詳細まで管理したいような感じもするけどね

買い物客ごとにデータを保持しておいたほうがいいね
実運用では商品によってキャンペーン対象外商品がきっとある（でないと転売屋天国になるからな）

まあ、教科書的な答えだけほしいってんならテキトーでいいと思うけどねｗ

キャンペーン複数適用するのに
たとえばAキャンペーンが1000円引き、
Bキャンペーンが1割引だったとしたら
正価から1000円引いてから1割引するのか、
1割引してから1000円引きなのか、とかも考慮する必要あるし
もっと仕様を詰めないといけないんじゃない？
逆に言えば仕様が固まればおのずとDBは決まると思うけど

ああ、値引じゃなくてポイントか
まぁ話としては変わらんけど

>>248
それもPHPコードで決めうちじゃなくて、
計算順をDBに入れて、利用者が設定できるようにしたいですね。

例えば、キャンペーンにプライオリティカラムをつけて、
その順番に適用していくとか。

結局どこで詰まってるんだか。

> １か月分のパーセンテージ一覧を作るのに、１日ごとにSQLを複数実行して
> かなり重いので、その辺も簡略化できる設計だと助かります。
3テーブルあって、月次バッチ処理をしているとして、1日ごとに実行したとしても、90回の抽出と30回の挿入だよね。
なんでそんなのが重くなるんだ？
DB今のままでちょっとチューニングしたら終わるんでないの。

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行分入れておか
ないといけない)になりそうで、ここが悩みのポイントです。

テーブル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 ポート番号上

>>254
between何てのがあったと！
それをip_tableにjoinすれば使いたいポートが開いてるアドレス一覧が取れると。

ありがとうございました。

>>255

開いてる)ポート番号が飛び飛びだったらどうすんの？

16ビットで表現できるな。

IPアドレスマスタ
IPAddress(PK) , ValidFlag

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

こんな感じじゃダメなんか

給与の締め日と支払い日を管理するDB設計は、どういった形がよいでしょうか？

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

こういった要件を自由にカスタマイズできるようにしたいです。

タイプ：月、週、日
締日
支払日

こんだけ

二週ごと、とか無理だろ。
DBでやるのは無理だから、ビジネスロジックでやるもんじゃね？

給与の締め日ってどんな感じで色々かわんのかね？
パッケージ向けってつーことかい

>>256
偶数番号のみ全開とかは泣ける…

>>258
IPアドレスマスタの ValidFlag はもしかして、65536bitのポート開いてる閉じてるフラグ？

>>253
悩むのは6500万件のテーブルが「えらいこと」かどうか確認してからでいいだろ。

65536bit・・・ だめだこりゃ。

>>255
betweenじゃなくても、
ポート番号下 <= xx and xx <= ポート番号上
で同じことになるよ。

>>259
DBに計算式のスクリプトを直接突っ込んでる

>>263
ああ、外部公開用WANじゃなくて、クライアントのIPアドレスの話か
ならLANが前提だろからIPアドレスは主キーには出来ないのでFQDN見るしかない
NICの複数差しも考慮しなくちゃいけない

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

ユーザーは別テーブルでFQDNと紐付けて、ポートの重複とか論理整合はストアドで取ればいいんじゃね？

なんだこの展開

しばらく見てなかったらえらい複雑な展開になっているみたいで申し訳ない。
後出しで申し訳ないんだけど、やりたいアプリは/24程度のFWの裏にいるグロー
バルアドレス持ちなネットワークのアドレス管理なのですよ。
FWでアドレス毎にinboundの接続設定が異なっているので、それの管理用アプ
リに、と思った次第。
基本　アドレス、利用者、開いてるポート番号　の要素を管理しておきたくて、
このネットワークの利用者からは「××番が開いてるアドレスなーい？」とか
「全開のアドレス空いてない？」いう問い合わせが多いので、ポートの状況で
検索というのが要件に挙がったと。

ここまででいくつかアイデア頂いてるので、それぞれ試作して検討してみます。
なので一旦closeということで。

誘導されました

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

記事: 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は著者、カテゴリ、タグのいずれか
http://hibari.2ch.net/test/read.cgi/db/1276247839/888-889

>>271
前者じゃないかな。あと、気持ちの問題だけど、記事idを先頭に持って行きたい

個人的にば、一つの事象を一つのエンティティとして切り出すほうが好きなので、前者で作って、
著者名、カテゴリ名、タグ名から透過的に検索するために、taxo関係をビューにするかな。

>>272-273
ありがとうございます。

> taxo関係をビューにするかな。
これのやり方がわからないんで教えてもらっていいですか？

>>274
単にJOINしたSQLをビューにしておくっていう意味以上のものはないと思うぞ

あ、つまり↑の作りの場合のデメリットはテーブルが増えすぎてわけわかんなくなるかも、ってことだから
ビューをあらかじめ作っておこうという嗅覚が働いたという話かと。

テーブル数は気にならないのでとりあえず上で行って見ます。
ありがとうございました。

テーブルAのある列の値がXのときだけ、テーブルBに対応するレコードが存在する。X以外では存在しない、
っていう制約がある場合、アプリ側だけで制御してる？トリガーとかでDB側でも制御してる？

>>278
その制約が破られたときの金銭的損失、瑕疵として損害賠償請求されたときの想定金額次第

>>278
俺的にはDB側にあんまり制約つけるの好きじゃないんだが
そのDBが一つのアプリ（システム）からしか利用されないならそのアプリで制御する
複数のシステムで共有されるようなDBなら、DB側になんらかの制御を入れる
ぐらいの基準かな

あるDBが複数のアプリから利用された場合を想定して、DB側でも制御、だなぁ。
とあるシステムで、顧客情報をWebアプリからも登録されるし、
オフラインのFaxやハガキからも登録される、っていうシステム見たんだけど、
オンラインからはメールアドレス必須なのに、Faxなんかには入ってなくって、
オンライン側でバグる、みたいなことが立て続けに発生してた。

個人的には仕様書がないときにバイナリしか残ってないアプリからじゃなにも分からないけど、
DB側に実装しておいてもらえれば、最悪でも仕様だけは知ることが出来るからDB側で実装してほしい。

新任の後任者が仕様変更で一方のロジックしか直さず
顧客をブチ切れさせるのが通過儀礼となる図

そもそもそんな設計が悪い、とか言い出す奴がそろそろ登場する悪寒。

・ユーザ情報テーブル（画像1枚）
・店舗情報テーブル（画像複数）

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

自分で思いついたのは、
・画像情報テーブル
を作って
そのテーブルに
foreign_id INT UNSIGNED　/* 外部キー */
forein_type enum('user', 'shop')　/* どのテーブルの外部キーかの値 */
てな感じで、外部キーをもたせつつ、その外部キーがどのテーブルのものかを判断する値も持たせれば
良いかなと思ったのですが、
もっと良い方法ありますか？

>>285
・ユーザ画像テーブル
・店舗画像テーブル
をもっちゃいけないの？
画像テーブル一つにまとめて画像データすべてに対してなんらかの処理をしたいなら
一つにまとめるのもアリだと思うけど・・・
普通はint情報テーブルとかもたないよねｗ・・・

>>286
それだと、今後別のテーブルにまた画像が必要なときにまた画像テーブルをつくるはめになるので、、、
１つのテーブルに画像情報がまとまっていれば、
そのテーブルに対するモデルさえあれば、
今後どんなテーブルに画像が必要になっても対応できるので、
なるべく１つのテーブルで管理したいんですよね

画像情報テーブルにユニークなキーがあれば、
それがユーザーのものか店舗のものかは気にしなくていいんじゃない？

何のために、どのテーブルのものかを判断するの？

>>288
例えば店舗情報を表示するページで店舗画像を取ってくるわけですが、
画像テーブルの外部キーが店舗のIDなのか、ユーザのIDなのかがわからないためです

ダメだこりゃ。

その「画像データ本人」が自分が店舗画像下ユーザ画像なのかを知ってる必要はないよね。

>>291
すいません、完全に理解できないです・・・。申し訳ない。

画像データが店舗のものかユーザのものか判断するのは
どのテーブルのフィールドが担うんでしょうか？
画像が必要なテーブルに、
画像IDを外部キーとして保持するとしても、
複数画像に対応できない気がしますが、認識が間違ってますか？？

・画像情報関連テーブル
ユーザか店舗のキー 画像のキー

これでなんか問題あるの？

>>292
画像がユーザーあるいは店舗に従属するのであれば、ユーザーと店舗の
テーブルを分けた時点で画像の方も分けなければならない。
どうしても画像テーブルを一つにしたいのであれば、手としては2つある。
・ユーザー・店舗の共通エンティティを用意する
→ただし、ユーザー画像は常に1つ、店舗画像は複数可、などは表現できない
・ユーザー―画像、店舗―画像という連関エンティティを別に用意する。
→場合によっては素直にユーザー画像テーブル、店舗画像テーブルの方が簡単

>>293
店舗とユーザのIDは別テーブルなので重複する可能性がありますね。わかりづらくてすいません

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

ありがとうございました。

店舗とユーザのどっちかを判別できるキーにすりゃいいだけだろ
アプリ側からしたらユーザか店舗かはJOIN時に分かりきってるんだから
解決したならもういいけどさ

>>295
教科書的な作り方なら

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

・画像テーブル

の３つが必要

>>297
あ〜こっちのほうがいいですね。
これでいきます！
どうもです

今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列の保存場所を
持っていれば良いと思っています

メインは↓みたいな感じでいいんじゃね？

ID、タイトル名、保存場所、ファイル名、作者ID、ジャンルID、コメント

有難うございます
まぁそういう形になるのかなぁと。
それで試しに作ってみます。

・ひとつの「タイトル」は、3つ(?)の「ジャンル」を持つ
・ひとつの「ファイル」に、「タイトル」はひとつ
・ひとつの「タイトル」で、複数の「ファイル」がある
・「タイトル」が同じでも、別のファイルなら、作者名、コメントは別？

タイトル { タイトルID, タイトル名 }
ファイル { ファイルID, タイトルID, 保存場所, ファイル名, 作者ID, コメント }
タイトルジャンル { タイトルID, ジャンルID }

・ひとつの「タイトル」は、3つ(?)の「ジャンル」を持つ
現在はジャンルを3つにしていますが、3つに限定しないといけない理由は
ないです。ただ最低限1つはかならず持つという事で

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

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

　複数の作者で同じタイトルという可能性はあります。ただしその場合
ファイルは別々ですが。

すんごい基本的な事なんだけど、毎回悩む。
たとえば、男、女 の様なマスターが欲しいとき、IDはふった方が良いんですかね？

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

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


うーん、、

最近は性別も更新される可能性のある属性ですｗｗｗ

マスターの方を変えたらジェンダーフリーすぎだろｗ

性別欄が必須でないデータってのもよくある話で、
男性、女性、中性、（未選択）
くらいはあってもよい気がする。

JISで性別のコードって規定されてなかったか

男 男性 M Male のように表現がいろいろあるから残念な気持ちになりつつ、男と女の2レコードを作っておくといいんじゃないかな

>>304
どっちでもいいんじゃない？
プログラム組んでてもそういう問題ってあるじゃない

>>304
自分の個人的な判断基準は、その値が表示するだけ（帳票に出ればいいだけ）なのか、検索やグルーピングで使うかかな。
後者なら一応IDにしておく。

二つだから気になるんだ
オカマとオナベもつけておけば気にならない

>>308
JISは廃止された（はず）だけど、ISO/IEC 5218:2004　はまだ生きてるかな。

外部テーブルにすれば外部キー制約が使えるが生データだと使えない
検索はインデックス張っておけばIDもvarcharも大差ない。

キー＝データになるんだから外部キー制約は使えるんじゃないか？

>>314
チェック制約じゃまずいの？

MySQLはCHECKねえじゃん

MySQL前提だったとは。

標準はティムポウェアだよ

目指してる 未来が違うｗｗｗｗｗｗ　ｂｙシャープ
http://twitter.com/junaoki1/status/6553250337656833　

使用DBはOracleです。

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

1番にはPK、2,4番にはnot null制約をつければいいとして
3番はどうすれば良いのでしょうか？

解決策として、「クラスNO」と「出席番号」を結合した「クラス別出席番号」という列を作り
ユニーク制約を付けようと思ってます。

もう少しスマートな方法があれば教えてください。

check制約でもいいと思うけどね

>>323
チェック制約だと他の列を参照することはできても、他の行を参照することはできないので
要件を満たせないんじゃないですか？

普通にout_of_line_constraintでunique制約つければいい

>>325
ユニーク制約は複数列指定できたんですね。
1番スマートな方法ですね。
ありがとうございます。

汎用マスタとか名称マスタとか呼ばれてるごった煮管理なOTLTなテーブルって
いまだに現役？

現役のところ知っているけど
聞いてどうするの？

その手のマスタにもサロゲートキーをつけて、
ジャーナルデータにはサロゲートキーを埋める形にするべきなのか迷ったので。
あと、適用期間をもって世代管理をしているマスタで親子関係があった場合、
子側のマスタには親のコードを要素として持つべきか否かで迷ってる。

サロゲートキーを使っている現場に出くわしたことない。
サロゲートキーを使おうとしていた現場はあったけど、
キーマンの一言「意味わからん」でお蔵になった。

だいたいどのページ見ても、総合的に見てサロゲートキーは良いみたいに書いてあるけど
実際はそこまでサロゲートキーを使ってるところが多くないのはなんでだ？

この間は複合キーの方が自然だからって押し切られたな。
変更に強い->そんな変更はあり得ない。あったらどうせ大改修だから意味がない。
ORMで楽->フレームワーク側の都合で設計するのは如何なものか。

実際なくてもいい類のものだからな。冗長になることで面倒事も増えたりするし。
流行とか嗜好、メンバーのレベルで臨機応変に変えて問題ないものだから、
その押し切ったリーダーや「意味わからん」つったキーマンが無能というわけではない。

>>331
設計上不自然な値がキーになってしまうから直感的に避けられてる

>>332
そこは説明のしかた次第なんだろうけど、条件をつけずに「変更に強い」とか、
あたかも万能みたいに言ったらそりゃ眉唾で見られるだろうな。

>>334
なんか気持ち悪い・・・ってやつか。

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

複合PKを使ってる場合は、こうゆう手順で改修を行う必要があるみたいな
具体的な作業内容が見たい。
できれば筆者の経験談を元に書いてるのがいいな。

SQLアタマアカデミー：第3回　テーブル設計のグレーゾーン〜毒と薬は紙一重　（4）サロゲートキーVSナチュラルキー｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/sql_academy2/000304

サロゲートキーと何でも一括りにするのって良くないと思うんだ。
人工キーを導入するにしても場面場面でその理由は異なるはずで、
そこを個別の事例ごとにきちんと区別して捉えないと、何でも
サロゲートキーマンセーとかいう困ったちゃんが出てくる。

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

流行とかじゃなくて、ケースバイケースで丁寧に検討する必要が
あると思う。

>>337
なぜか図11では開始時点と終了時点のカラムの値が編集されていないが
これだと商品ID001で検索すると2つhitして
一応代理キーの値が大きいほど新しいということである程度わかるが
いつからいつまで001がガムテープだったのかがわからんよね。

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

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

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

上記のようなテーブルにしといて、検収まで終わった「過去」の受注明細を「参照」するときは
テーブルを結合せずに得意先名称をひっぱってきたりする。
不細工な形だが、わかりやすいんだ・・・

履歴的なテーブルならまぁそういうやり方のとこが多いんだろうね
過去に遡って洗い替えとかあると死ねるけど

ちなみに商品IDの付け替えってありなの？
なにかと面倒だし、大した手間でもないから必ず新しいの作ってもらったほうがいいと思うんだが。

得意先は合併とかあるからお客さんの要望次第って感じだが。

顧客要望によってはないこともない
正確には商品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のみ(にこ動のタグとか)
そうでないなら検索する可能性がある項目を持つ側に外部キーを持たせる設計も検討する
という指針を考えてるのですが、大丈夫でしょうか
速度よりも修正容易性を重視したほうがよさそうな環境なので、基本サロゲートキーを付けてます

どういうことだ？

>>344
テーブルA,Bの関連が 1..N(Nは0以上) の基本を以下に書くよ。

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

テーブルBの外部キーとしてNULL値を許容するとか、関連テーブルが必要かとかを検討する必要があるのは、
エンティティAも存在しないこともあるという関連 M:N(M,Nとも0以上) の場合だけだよん。

テーブル名やカラム名にマルチバイトの文字って使う？
とんでもなく長いsqlとか書いてるとわけわかんなくなるから、マルチバイト使いたいような気もするし
もしかしたら今後のアップデートとかでマルチバイトが祟ってエラー吐くかもしれないから
あんまりマルチバイトを使いたくないって気持ちもある。

カラム名はシングルバイトでコメントの部分だけにマルチバイトってありかな？
これなら多少ましにはなると思うんだが、中途半端感が否めない。

オラクルだと結構日本語テーブル日本語カラム見かける気がする

客先でコンソールでデータとろうとしたときに詰むのが怖すぎる

確かにリモートでつなげないような環境でデータを見る可能性があるならシングルバイトのほうが良さそうだね。
俺んとこはそうゆう事は一切ないから気づかなかった。

以前働いていてたとこ、DB名、テーブル名からカラム名まで全て日本語 w

>>351
それで具体的に何が困ったかｋｗｓｋ

最近の自動生成系の機能がついたIDEなんかだと日本語変数名にもつながっていくので
規約で変数名にマルチバイト文字使っちゃダメとかやると面倒くさい。
逆に積極的にマルチバイトを使うように決めてしまえばあるいは。

MySQLの公式ツールが落ちるからマルチバイトは使わないなぁ
コメントの日本語だけで詰むｗ

supplier.id ほげ.仕入れid hoge.siireid
こんなDB見た事がある

>>354
MySQLってそんなにマルチバイトに弱いの？

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

公式ツールで扱えないんじゃMySQLではマルチバイトでカラム名を付けるなんてことは考えられないなｗ

トントンくらいになったが、PostgreSQLの改善速度がかなり早く、MySQLはまた引き離されてしまった印象。

>>354
公式っても、GUIツールだろ。
そりゃあしかたない。

他は全然安定してるから問題ない。
あんまり。

サポートされてる機能を使っちゃいけないってのもおかしな話だしな

>>357
仕方なくないだろ。
あきらかにマルチバイトは軽く扱われてるじゃん。

OracleやSQLServerですら稀に問題が起こるのに
MySQLで問題が起こらないとは到底思えないな。

マルチバイトのテーブル名だの、項目名だの欲しがるのは、開発側じゃなくて大抵客。
だから、マルチバイトにしたビューを用意すればいいだけ

Oracleだとマルチバイトのカラム名は""で括らないと動かん場合がある

>>361
Oracleで""で括ってないって理由で動かないSQLを1度だけ見たことがある。

SQLServerは""で括らなくても問題ないの？

>>346
ありがとうございます。

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

>o テーブルBに主キーが必要か否かは、エンティティA無しにエンティティBが存在しうるか否かで決める。
主キーについてまだ理解が足りてなかったみたいです
では、DB設計時は1:NやN:Nといった関連と、
単体で存在しうるか、という軸でも整理しておく必要があるってことですね
今作っているテーブルの該当部分は親子関係(子がない場合もあり、子単体は存在しない)なので
親への外部キーのみ設定して、子の主キーは設定しなくても良さそうです

>>346, 363

訳が分からない。

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

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

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

子の主キーも設定する。親への外部キーはNOT NULLで参照する。
そんだけ。あと初心者は気軽にNULL使わない。三値論理を理解して、
その面倒くささを理解してから使うこと。

>>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に主キーは必要無い。

>>365
BがAに依存する属性だったとしても、Bに主キーがなければ
その属性を一意に特定することができないってことだろ？
「主キー」の意味するところが違う？

>>366
テーブルBの個々の行(ロウ)を一意に特定する必要があるのなら、
そのテーブルBは(属性ではなく)エンティティを表現していることになる。
もしテーブルBでエンティティを表現したいのであれば、当然のことながら
テーブルBに主キーは必要になるよ。

複数存在するのに一意に特定する必要のない属性って、想像しにくいんだが。
それってたとえばどんなもの？
もしかして、BのエンティティキーをAと独立に持つかどうかという話じゃないのか？

>>368
想像しにくいというのが理解しがたいのだけれど、要望とあれば。
たとえばエンティティAが楽曲や書籍のような著作物であるとする。
この場合、作者(作曲家/作詞家/著者/原作者/翻訳者..etc)は属性であり、
ある著作物に複数の作者が関わることがあるから、複数の属性になる。

いや、問題は「一意に特定する必要がない」ということの方なんだが。
作曲家と作詞家、あるいは作曲家が2人いてもそれらは個々に特定
できなきゃならんのが普通だろ。
主キーを持たないということは、仮に同じ曲に同姓同名の作曲家が
2人いたとして、それを区別する術がないということだ。

>>370
>それらは個々に特定できなきゃならんのが普通だろ。

特定する/しないという判断は、与えられた問題(要求仕様)によって変わる。
「普通だろ」というのは設計者の勝手な意図(思いつき)にすぎない。
もしも特定しなくてもいいという問題であるのもかかわらず一意性を作り込んだのなら、
それは過剰な設計(設計ミス)ということになる。

>>371を一部訂正する。

X: もしも特定しなくてもいいという問題であるのもかかわらず
O: もしも特定しないという問題であるのもかかわらず

別に本人が必要ないと思ってるんならいいんじゃない？
こんな頭の固いやつにいくら言っても無駄。宗教と同じ

あらゆるテーブルには主キーが存在しなければならないという考え方が、「頭の固い」発想だと思う。
どちらにせよ、人格攻撃に走ることしかできないのなら、漏れは議論から降りるよ。

だからさ、そんなもの見たことがないからどんな例があるか聞いてみたんだが？
RDBでは主キーがないテーブルも許されるが、設計論としてはリレーショナル
モデルにおいて主キーがないなんてことはありえないし。

>>371
ん？しかし>>346では「エンティティA無しにエンティティBが存在しうるか否かで決める」と言っているが？

あまり読んでないけど、
AなしにBが存在し得ない状況では外部キーが主キーと同じ意味を成すといいたいのかな。
そんなことないけど。

>>375
>だからさ、そんなもの見たことがないからどんな例があるか聞いてみたんだが？

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

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

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

次に、RDB実装における主キー(プライマリキー)と、リレーショナルモデルにおける主キー
(行の一意性を保証する候補キーの集合)とを混同して理解しているように見える。

（>>378の続き）

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

>>364のようにテーブルBへ主キー(プライマリキー)を設定した場合には、RDB実装における
テーブルの一意性は保証されても、リレーショナルモデルにおける一意性(作者名の非重複保証)は
実現できないから、誤ったDB設計であると思う。

>>326,327
個別にはレスしないが、二人とも「単体での存在性(エンティティなのか？属性なのか？)」と
「主キーの有無(タブルの一意性を保証するのか？しないのか？)」を混同してるように見える。

アンカをミスった。

>>326,327は間違いだ。>>376,377に訂正する。

>>378
そういう一般論を言ったら、Aに関係なくBが存在する場合だって
必ずしも主キーは必要ないってなるんじゃね？

>>380
それを混同したのが>>346だと思うんだが。

>>382
それでも良いと思う。どこに(普通か普通じゃないかという)境界線を引くか、という話になるね。

>>383
えーと、>>346で書いた「主キーを設定する」という表現は、すべてDB実装における
主キー(プライマリーキー)のことだよ。それが読み取れないということは、やっぱり混同してるんだね。

つまり「主キー」という言葉には2種類の意味があって、自分が意図していたのは
違う方の意味だとｗ
>>379では「設定する」と「みなす」なんて言い換えまでしてご苦労なこったな。

小難しい表現の割にはどうでもいい話だったな

>>385
えーと、困ったな。言葉の「使い分け」はしてるけど、「言い換え」はしていないつもりだよ。
「言い換え」とは、同じ事柄を別の方法で表現するという意味だよね。

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

日本語って難しいね。

>>386

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

「いいや、....だから>>364が正しい」とか「自分ならこうする」というような
反論/異論を期待してたんだけど....。

彼の言う「主キー」と、「主キーを設定する」という用語は
一般的なSEやプログラマがRDBMS上でのテーブル設計をする際のそれと
意味合いが違うってことです

一般的なRDBMS上のテーブル設計では、そのテーブルの行を個別に識別できる項目（の組み合わせ）を
システム的に指定することを主キーを設定するといい、その指定された項目を主キーと呼びます
そういう意味では、行を識別必要があるする全てのテーブルにおいて、主キーを設定することが推奨されます
つまり、全てのテーブルに主キーがあるべきであると言う主張が成り立つわけです

もうどうでもいい。
Ｔ字形の論理編ぐらい、どうでもいい。

いけね、また間違えた。

X:「>>363のDB設計は誤りであり
O:「>>364のDB設計は誤りであり

もともと「設定する」と「みなす」を別の意味で使っていたのなら、>>346のテーブルAも
「設定する」と「みなす」場合両方があるわけだろ？
それを誤解がないからと勝手に片方だけ書いたら逆に誤解するわ。

じゃあ聞くけど、もう一度言葉の定義を明確にして>>346を正しく書き直したらどうなるの？

>>388
たとえば伝票と明細のケースでいえば
明細テーブルでは行を一意に識別する主キーはいらないってのがお前の立場なんだろ？

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

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

要するにどっちでもいいし、どうでもいい。

>>387
モデルの一意性は存在してるけど実装のプライマリーキーが存在しない状態ってなんだよそれ。
つか、そもそも設計段階でそんなもん考慮するのか？

>>389
つまり、一般的なSE/PGのRDB設計とは>>375が言うところの設計論としての
リレーショナルモデルとは意味合いが違うってことなんだな。
だから、>>379のような「主キーとみなす」という表現は普通じゃないってことか。
うん、よく分かった。これからは注意しよう。

ところで、>>364では

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

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

分かっている人には当たり前なのかもしれないけど、>>344,363のような初心者に対して
「主キーも設定する」という短い一文からそのような推測を期待するのは、
ヒジョーに厳しすぎるんじゃないかと思うんですが、いかがですか？（自分も勘違いしたし....。）
いや、それすら「一般的なSE/PGのRDB設計」なら普通なのかな？

>>392
>>346を書き直してみた。これなら誤解はしないかな？

>>>344
>テーブルA,Bの関連が 1..N(Nは0以上) の基本を以下に書くよ。
>
>(1) テーブルAにプライマリキーを設定し、テーブルBには(テーブルAを参照する)外部キーを設定する。
>(2) 次にテーブルBにプライマリキーが必要か否かは、エンティティA無しにエンティティBが存在しうるか
>　否かで決める。ここで、もし存在しえないのなら、テーブルBは(エンティティではなく)属性を
>　表現することになるから、テーブルBへのプライマリキーの設定は不要になる。
>(3) 最後に(エンティティまたは属性)Bの一意性について検討する。もしBに一意性が必要とされるなら、
>　(1)で設定した外部キーと適切な候補キー(たとえば作者カラム)との複合キーをリレーショナルモデル上の
>　主キーであるとみなし、その複合キーに対してUNIQUE制約を設定する。
>
> （以下は同文なので省略）

>>393
いいや、その伝票と明細のケースで言えば、明細テーブルの各行は普通にエンティティだと思う。
だからリレーショナルモデルにおける主キー(一意性)は存在するよ。ただし、RDB実装における
主キー(プライマリキー)は設定せず、(明細テーブルを参照する)外部キーと候補キーとなる
行番号カラムとの組(から成る複合キー)をリレーショナルモデルにおける主キーとみなすという
違いはあるかもしれないけどね。

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

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

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

この場合、>>393であれば、どのようにDB設計をしますか？やっぱり値引きテーブルにも
プライマリキーを設定するのかな。もちろんそれでも(AP開発に苦労はしても)要求仕様を
満たせるだろうから、どっちでもいいし、どうでもいいんだけどね。

>>396
ふむ。「設定」が>>389の意味だとするならば、言っていることはだいたいわかる。
＃本当は「存在しうる」とか「エンティティ」と「属性」の違いなんかは明確ではないが、
＃ここではそれを措いても特に問題ない。

その上で反論だ。
(1)1:Nならば無条件でBに外部キーを設定することになっているが、こここそ、Bが
Aから独立して存在するかどうかで変わる部分だろう？そうでなきゃ、対応するAの
レコードが存在するBの外部キーはNULLになってしまう。
(2)一意性が必要かどうかは要件で決定されるって自分で書いていなかったか？
自分は必要ないケースはめったにないと思っているが、どちらにしても、エンティティ
ABの関係とは関係がない。
(3)ここは言葉の問題。候補キーは(1)の外部キーを含む場合と含まない場合が
あるが、どちらにしてもそのまま主キーになり得る。だから、外部キーを含まない
候補キーとの複合キーなどというものは考えなくていい。

>>395
>「主キーも設定する」という短い一文からそのような推測を期待するのは、
>ヒジョーに厳しすぎるんじゃないかと

「一般的なSE/PGのRDB設計」ならそう思うのが普通だと思うが
純粋な設計と言うよりは、実装方法論だがな
だからあえてRDB設計とかいう言葉じゃなくて、RDBMS上のテーブル設計って言葉をつかったんだ

>>397
なんか例がおかしくない？優待値引きとか個別値引きとかあるのになんで論理値なの？

それはそれとして、値引きテーブルに一意性が必要ない(=同じ値引きが複数存在してもよい)
と言うことであればそれはそれでありだと思うが、特定の値引きを削除するとか変更するなんて
要件があった場合は一意性が必要となる。
一方で、ここに1商品1レコードの在庫テーブルがあったとする。これはここで言う「属性」には
当たらないと思うが、一意性の要否については上の値引きテーブルと変わらない。
つまり、一意性の要否を判断する上で「エンティティ」か「属性」かは関係ない。

>>398

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

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

(3) この候補キーというのは、>>364の「子の主キーも設定する」というところのプライマリキーを
　指しているのですか？もしそうであり、なおかつプライマリキーが人工キーである、
　たとえば hoge_id のようにデータ型が自動インクリメントされる整数(つまり)であるなら、
　自動的に一意性は保証されるから複合キーは考えなくていいでしょう。
　自分は(なるべく)人工キーは作らず複合キーで実装する立場ですが、それはまた別の話です。

>>397
値引きオプションだって修正や削除の必要が発生する可能性はあるから、
当然主キーつけるに決まってるよ。
そもそも実務的には値引き伝票切るケースが多いけどな。

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

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

お前、いつの時代の人間なの？
最近のアプリケーションフレームワークなら、むしろプライマリキーをつけないほうが
特殊な処理過ぎて苦労するだろうが。

軽い実例を出してくれたほうが伝わりやすいことは業務をやってればわかることだと思うんだけど、
いつまで文字でがんばるのか。

>>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}と
する必要はない。
つまり、「外部キーと候補キーの複合キー」はいずれの場合でも必要ない。
候補キーの定義からして自明のはずなんだが。

うざいから、ER図付きでやってくれ

もともとの話は>>346に対する>>364の反論から始まってるんでしょ？

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

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

それだけの話だった（ように見える）のに、
以降の議論はただ話を難しくしてるだけのような。

なぜサロゲート？タグテーブルには候補キーが存在しない前提なの？

どういう候補キーがあると思う？

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

わざわざ書いてるってことは364氏の言ってる主キーには
外部キーを含んでないっていう前提があるんでしょ？
（あくまで推測ね。俺は364氏じゃないから。）

>>364の真意は知らんが、「主キーに外部キーを含めない」と限定していたようには
俺には読めなかったな。含んでいようがいまいがNOT NULLということだろ？

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

3.の疑問を持った時点で自分の推測を疑えよって話だな。

うん、まあ、そうかもしれんしそうじゃないかもしれん。
どっちにしろ、364氏の真意が分からんことには議論はできないよね。

364だけど、

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

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

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

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

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

正解。

もひとつ、>>346に聞きたいのは、>>346のルールとか、そのあと
改正した>>396のルールとか、これ教科書か何かに書かれたものなの?
であれば参考までにリファレンスを示してくれると嬉しい。

つまり、>>364の
「子の主キーも設定する。親への外部キーはNOT NULLで参照する。」
は以下の意味だってことだろうから、俺は特に異論はない。

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

346氏（=378氏？）は、単にサロゲートキー否定派なんじゃない？

>>413
そゆこと。ただし以下の下りはちょびっと。

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

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

>346氏（=378氏？）は、単にサロゲートキー否定派なんじゃない？
よくわからんす。自然キーでも人工キーでも、必要な場面で正しく
使えばどっちでもよいです。

「弱実体」でググると>>346が言いたかったことと、どこが間違っていたかがわかるかも。

>>396
> (2) もし存在しえないのなら、テーブルBは(エンティティではなく)属性を
>　　表現することになるから、テーブルBへのプライマリキーの設定は不要

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

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

> (3) その複合キーに対してUNIQUE制約を設定する。
なんでUNIQUE制約? PRIMARY KEY制約だとダメなのか? だってその
「複合キー」はテーブルB中の行を一意に選択出来るんでしょ? 主キー
の資格十分じゃん。
素のUNIQUE制約はNULL許可するけど、それでも良いの?

>>397

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

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

主キーつけるのに何を悩む必要があるのか、それが解らない。

>>378氏は一生懸命頑張って主キーがいるいらないの説明しているけど、
まず純粋にスキーマ設計の立場からいうと各テーブルの候補キーを特定
しておくことはマストだよね。でないと正規化が出来ん。

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

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

ましてや>>344は初心者だといっているのだから、教科書通りER図など
から主キーも含めたテーブル定義を導出する方法で良いじゃないか。

みんな教科書通りにやろうとしてるぜ
みてる教科書の分野が微妙に違うんだがな

>>417
関係従属性 -> 関数従属性。
関係モデルの超基本だ・・・釣ってくる・・・

話をサロゲートキーの話題に戻すが、

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

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

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

あと、階層関係があるマスタ、たとえば事業部マスタと部門マスタで
事業部と部門の紐付けが変更されうる。部門の名称変更がある等の理由で、
適用期間をおのおの持った場合、サロゲートキー（事業部ＩＤ）
だけでリレーションさせると、事業部マスタの世代が増えたタイミングで、
リレーションが破綻するわけだが、どうしたらいいんだろ。

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

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

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

どういうシチュエーションでどういう設計をしたら破綻するのか
全然イメージがわきません。
多分サロゲートキーじゃなくてお前の頭が悪いんだと思うよ。

>>421
サロゲートキーの使い回しをせず、商品コードの書き換えもマスタ
への追記で対応すれば(2)は本来不要なんじゃないのかな。

まず、この例で言うなら、商品コードが変わった場合
過去に登録されたトランザクションデータをどうしたいかを考えろよ

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

それだけの話だろ
違う要件に対する解決案をならべて同時に成り立たないって当然だろ

履歴とリアルタイムデータの区別が付いてないっぽいな

>>424
2にしてもトランザクションデータに追記する際に商品コードとか
商品名などを商品マスタの内容からコピペしているのであれば結局
1で対応出来るのだが。

商品マスタは基本追記で、最新フラグとか削除フラグとか付けて
古い商品レコードも全て保持するのは案外一般的だと思うけど。

サロゲートキーでよくわからないところがあるんだが
本来pkになるはずだった項目の制約はどうすんの？
前に張られたこのURLの例では、制約について一切触れてないから、そんな制約張りませんってことなのか・・・？
http://gihyo.jp/dev/serial/01/sql_academy2/000304

制約つければよくね。

NOT NULLとUNIQUEでいいじゃん

>>428
もともとpkにする予定だった項目には、例外なくuniqueを張りたいんだけど
>>427の例ならどうするべきですか？

>>427
場合によるとしか言いようがない。
挙げられた例だともともと主キーだったitem_noにUNIQUE制約とか
は付けられないよね。同じitem_noを使い回すので。

沢山の属性を組み合わせた複合キーをシンプルなサロゲートキーで
置き換えるような場合は、主キーこそサロゲートキーにしたとはいえ
元々の複合キーも未だに候補キー、つまりキーに含まれる属性値の
組み合わせはユニークなはずなので、UNIQUE制約を付けた方が良い。

>>430
item_no（商品ID）とitem_name（商品名）の組み合わせに対して
UNIQUEだろうね
しかし>>427の例って商品ID自体が自然キーじゃないよな

>>427のように、同じitem_noを使い回すのであればテーブルには更に
最新フラグとか削除フラグをつけることが多いと思う。
[id(サロゲートキー), item_no, item_name, deleted]みたいな感じで。

で、上記の例の場合は削除フラグdeletedがfalse、つまり現在有効な
行の中でitem_noのダブりがあると困るわけなのだけど、この制約を
書くのはちょっと面倒くさい。フラグ値を工夫するとか一般制約を
使うとかすれば書けるけど。
実際はアプリケーションレベルでタブりを事前確認するロジックを
書くことが多いんじゃないのかな。

>>431
＞つまりキーに含まれる属性値の組み合わせはユニークなはずなので、UNIQUE制約を付けた方が良い。
この部分がよくわからないんですが、もうちょっとスキルが低い人にもわかるようにお願いできませんか？

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

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

おそらく削除フラグを付けたほうがいいというのは、期間でなくフラグを参照することで
select文を発行するときの負荷が減るというのが目的ですよね？
重複チェックはなかなかミスが出るようなところじゃないから、アプリ側できっちりやれってことでしょうか？

>>434
プライマリキーのカラム数が5個ぐらいあって、Joinがしんどくてしんどくてしょうがないという理由から
ただの連番のカラムを作って、それをキーとするようにしてみた
という状態であれば、もともとの5カラムにユニーク制約つけたままで問題ないよ

>>432
それがUNIQUEになるなんてただの思いこみなんじゃないかって思う

>>435
すごくわかりやすい、ありがとう。
効果は開発効率のアップと、select文のコストが少し減るって感じかな？

その目的でサロゲートキーを使う場合
全てのテーブルにサロゲートキーを追加するんじゃなくて
pkの項目が多くなりそうなテーブルにだけ追加するのが良さそうですね。
サロゲートキーを使用するテーブルの場合、例外なく最初の列に「PK_テーブル名」というカラムを作り
それをサロゲートキーにするというルールで設計すれば、アプリチームの混乱も防げて良さそうですね。

>>434
例えば月給テーブル(社員ID, 年, 月, 給料)を考えてみる。
主キーは(社員ID, 年, 月)ね。

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

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

関係モデルでは一つのテーブルが複数の「候補キー」を持つことがあります。
この場合はSIDと(社員ID, 年, 月)の二つの候補キーがあります。
その中から「主キー」を一つだけ選ぶわけですが、だからといって残った他の
候補キーがキーでなくなるわけではありません。それらも引き続いてキーです。
なので上記の例だと候補キー(社員ID, 年, 月)にUNIQUE制約を付けておく
必要があります。

>>434
>おそらく削除フラグを付けたほうがいいというのは、期間でなく
>フラグを参照することでselect文を発行するときの負荷が減ると
>いうのが目的ですよね？

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

ただこの手の終了フラグを使った場合、商品IDのタブりを防ぐ制約は
やや凝った記述になりがちで、となると現状PRIMARY KEYなど基本
どころ除けばDBMS毎に書ける制約の表現力がバラバラなのが難しい。
MySQLなんてCheck制約は書けてもガン無視するとか、そんな仕様。
なんでアプリ側でチェックするロジックを書くことも多い気がします。

>>438
丁寧な説明ありがとう。
この板はIDが無いみたいなんで、どのレスをした人がどのレスを返してくれてるのかわからないけど
>>435と>>438は同じ事ですよね？


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

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


サロゲートキーの一つの利点である、pkに指定する項目が1つになるという部分は理解できました。
どこのページを見てもあんまり紹介されてませんが
unique制約が付けづらいというのはサロゲートキーのデメリットとして覚えておいた方が良さそうですね。

商品IDがダブらないなら本質的にサロゲートキーは不要かと…
やばいのは商品IDというか商品コードがメーカーによって使いまわされて、
ある製造日より別商品に割り当てられたが、
販売店の在庫管理としては商品コードと入荷日でしか
管理していなかったため、同一商品コードの違う製品が混在してしまって
何を販売したのか管理できず混乱するなどですよね。

>>441
得意先のマスタなんかは在庫とかって概念がないからどうゆうふうに設計してもなんとかなりそうなもんだけど
商品に関しては商品IDを使いまわす可能性があるならサロゲートキーは必須になるのか

すごーーーーく根本的な話になるんだけど
商品IDの使い回しを行いたい時ってどうゆう時？

得意先や部署はわかる。
合併やら統合やらあるもんね。
商品IDはわからん。

桁数だろう？
どれだけ必要になるかわからないからって
たとえば２０桁のコード体系をあらかじめ用意するのかってこと。
覚えられん…

>>443
古いシステムならコードのMAXが5桁とか普通に有り得るだろう。

えー・・・

くるくる回る商品IDなんてよくある。
ある時点においてユニークであれば、それで現場は回っていくんだよ。
なもんで、こっちとしてはサロゲートキーを作って、商品IDガン無視する。

たとえ今はいらなくとも、商品IDで検索したいってなったときに困らないように、
ある時点で有効な商品IDがどれかを特定できる情報を保持しておく。

俺の場合、
自社に決定権がないコード体系のマスタ（商品など）は、サロゲートキー
自社に決定権があるコード体系のマスタ（得意先マスタ）はナチュラルキー
ジャーナルのヘッダはサロゲートキー、
ジャーナルの明細はヘッダのＩＤ＋明細番号の複合主キー
とすることが多いが、これって古臭い？

雑誌コードなんか桁が足りなくて新規発番が出来なくなって使い回してるよな

そうゆうことか。
周辺システムが古くて桁数が少ないので
商品IDを使いまわさずを得ないと。

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

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

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

なんにせよ恐ろしい・・・
こうゆう運用ならサロゲートキーは必須だ・・・

>>448
その得意先マスタのキーって得意先IDみたいなの、つまりサロゲーとキーでは？
ナチュラルキーになりうるのってなんだろうとぐぐってみたところ、
上場企業限定ならISINコードというものがあるようだけど、これなのかなぁ

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

>>450
客から見て、在庫も含めると異なる商品に対して同じ商品IDがついているけれども、
業務を滞りなく行えているのであれば、何も悩む必要はないよね。
こちらとしてはサロゲートキーで処理をしてしまえばいいだけだよー

>>450
加えて、商品IDでの検索結果が複数出てきたなら複数出せばいいんだよ。
それで業務がまわっているということが不思議だなぁと思うことはあれど、
それを正としなければいけないしねｗ

>>451
>上場企業限定ならISINコードというものがあるようだけど、これなのかなぁ

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

たとえば、紙の受注伝票に記入する得意先コードや受注商品コードというのは、
自社特有の(自社で決定できる)自然キーである可能性が高い。
逆に、発注伝票に記入する発注商品コードというのは、
(自社では決定できないから)人工キーとせざるを得ない可能性が高い。

お前ら、商品ID商品ID言ってるけど、使いまわした時点でIDとしての役割を果たしてないだろうが
商品コードを使いまわす、が正しい用語だ

まぁ目安だよな。あくまでも、自分が定義したエンティティに対してそのコードが
一意であるがどうかで判断すべきであって。
・よそで定義されたコード→一意でない「可能性がある」
・自分で定義するコード→当然一意に「できる」

極端な話、実際の商品の品種と商品コードの一意性が一致しない場合であっても、
「商品」ではなく「商品コード」エンティティを作る分には商品コードをそのままキーと
してもぜんぜんかまわないわけだ。

>>453
＞自社特有の(自社で決定できる)自然キーである可能性が高い。
純粋な意味では、自然キーではないよね。ｗ

>>440
＞MySQLでcheck制約がきかないのは初めて知りました・・・なんと恐ろしい。
こわくないよ？

つーか、それっておいしいの？
MySQLしか使わないオレには、よく
わからん話なんだよな。

>>456
システムの外で定義されるのが自然キーだろ？コードが人工的かどうかじゃなくて。
そんなこといったら、人名とか市町村名なんてどっちか判断つかん。

>>457
知らない者にとっちゃ恐ろしいだろ。
定義できるのにまさか動かないとは思わないだろうし。

>>454
このスレでのID、コードの使い分けって一般的に通用するものなの？
いや、自分もそういうふうに使い分けてるんだけど、他の人がそんな風に気にしてるの見たことがないので。

>>460
基本的には普遍でユニークな社員番号(商品ID)と、変更可能な姓名(商品コード)、
みたいな形で一般人も接してはいる。

>>460
まあ、大概の人は混同してる。このスレでも混同してる人もいるしな
一般の人にとって、コード振ってあるのに別にIDとるのは無駄に思えるんじゃね

「混同」っていうと、まるで使い分けないのがおかしいみたいだな。
2行目をみるとそれぞれ別物のなにかを指しているというのはわかるんだが…

IDでもコードでも俺はどっちでもいいな。
使い分けてないプロジェクトがあっても、sql書く時に項目名間違えづらいなぁ程度にしか思わない。

>>458
システムの外で「独立して」定義されるのが
自然キーだろ？
顧客コードなんかデータベース以外に
ほとんど用途がないんだから。

>>463
ID=コードなシステムもまあよくある
というか、IDとコード別にもつシステムの方が少ないと思うけど

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

IDっていう用語の意味を考えると、厳密に区別できないとIDじゃないからな

>>465
この場合の「独立して」ってどういうことを意味しているのかな？
ここで挙げられた顧客コードってのは、「システムの外で定義されるけれども独立してない」例？

独立していない可能性がある、または随時変更される可能性があるコードなんじゃない？
客から見えるコードだと、コードを振りなおしたい要求って結構くるよね

>>465
>顧客コードなんかデータベース以外に
>ほとんど用途がないんだから。

ええぇっ！！、それが常識なの？
自分のいる世界とは別の異次元な世界の住人さんらしい.... hahaha

「データベース」の意味をどう捉えてるかによるだろうな

「データベース」でくくるとさすがにちょっと狭いと思うぞ
ほとんど「情報処理」とか「システム化」と同じぐらいまで解釈を広げればまあ納得しなくはないが

台帳をデータベースと呼ぶかどうか

>>469
そんな反応しなくてもｗ
そこだと、顧客コードは恒久的に変わらないことが前提で、顧客コードで会話等がされてるんでしょ。
その業務であればそのコードはIDであり、自然キーといっていいと思うよ。

どのスレが適当か探してみたんですが、スレ立てるまでもない質問スレが見つからなかったので、ここで質問させて下さい。
病院で働いているんですが、今、上司からの依頼で、内視鏡検査の画像をデータベース化する作業をしています。
現在のシステムに以降する前の約２年分、件数にして4000件ぐらいのデータです。
データ形式ですが、約３ヶ月分ずつのデータがDVDにまとまっていて、DVDの中に入っている.exeファイルを起動して閲覧する、というものを、何とか一つのデータベースにまとめたいと悩んでいます。

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

こういったデータを、Windows上で現在のシステムに移植するには、(オリンパスの出入り業者に確認した話ですが)一件一件検査オーダーを立てて、画像を指定する必要があるとのことでした。
自動でデータを読み出して全ての過去データDVDをデータベース化するか、現在のシステムに移植するには、どういうソフトを使えば可能でしょうか？
軽く調べたところ、SQLとやらいうスクリプトの話がでてきましたが、ド素人なので厳しいかと正直諦めかけてますorz
よろしくお願いします。

>>474
多分この内容だと情報が足りなすぎて誰もアドバイス出来ないと思う。
ファイルの格納の仕方は「なんだそれ」という感じではあるけれども
サルベージ出来ないわけでもない。多分ネックは、

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

の中身と

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

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

いずれにしても出来合いのソフトで出来そうな作業じゃない。
専用のマイグレーションのためのプログラムを書く必要はある。

>>475
レスありがとうございます。
やはり専用のプログラムが必要ですよね…
現在のシステムは、内視鏡サーバーに全て検査内容が直接スタックされるもので、オリンパスのsolemio というものです。
検査一件一件のデータをログから指定して、画面上の場所指定でオートクリック、ログ入力、画像指定が出来るソフトというと、オンラインゲームのチートソフトくらいしか思い付かず、それにしたってログを読み出すプログラムが別に必要になりそうな予感はしていました。

ちなみにログの抜粋がアウトなのは個人情報の関係ですか？

>>476
医療情報流出〜匿名掲示板でアドバイスを装って診察データを入手か〜

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

オリンパスにデータインポーター提供してもらうしかないんじゃない
のかなぁ

>>474
画像の格納方法に規則性があるなら、画像を取り出すことは出来るかもしらんが、
「患者名かIDか検査日を入力すると〜」がネック。おそらくこの他にも情報があるんだろうけど、これらのサルベージ方法が問題。
フォルダの中にテキストで埋めこまれてるとか言う間抜けな作りなら個人PGでも解析出来るだろうけど、さすがにそんなことはないだろうな・・。
そもそも元システムのライセンス的にどうかとかなりかねないし。

逆に解析を諦めるなら、最終手段で人がPC2台使って手入力でやれば出来る(つまり出入り業者の言う、「一件一件検査オーダーを立てて、画像を指定する」)。
この最終手段の可能性コミで、オリンパスに見積もってもらうのがベストだと思う。ただ人海戦術は安くないけどね。

>>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を設計すべきか？という、このスレ住人向きの話題にようやく辿り着く。

>>479の課題(3)で新規DB開発を決定した場合に限定される話だけど、
医療関係者が(外部の業者に頼らずに)自力でデータベース化を図るとしたら、
FileMaker Pro というDBアプリケーションがよく知られている。
FileMaker Pro は、Microsoft製であればAccessに相当するデスクトップDBソフトだけど、
SQLを憶える必要は無いし、テーブル設計/画面デザインからスクリプト作成まで
すべてGUIで操作できるから、簡易なDBであれば専門家でなくても開発できるのでお勧め。
（個人的にはシステム分析初期段階のラピッドプロトタイピングに活用している。）

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

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

FileMaker Proは試用版が無償で利用できるから、まずダウンロードして触ってみるのがいい。
質問等はビジネスsoft板に専用のスレがあるから、そちらへドーゾ。

「はてな」や楽天のポイント履歴を見ていて思ったのですが、
ああいう頻繁にレコードの追加が発生するコミュニティサイトって
1テーブルのフィールド構成をどうしているのでしょうか？
単純に「日付｜ポイント数｜対象ユーザID｜対象動作ID」
で分けてるだけでしょうか？

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

ポイントというお金と変わらないものですから、
「○件まで保存。後は削除」と言うことはなかなか出来ないと思いますし・・・

ヒント：それらのケースでは厳密なACIDは要求されない。
　　　　（もちろん楽天の商品注文処理には厳密なACIDは要求される。）

ショッピングサイトでのDB設計について
・注文テーブル、
・会員テーブル
があります。
会員が注文した場合は会員IDを外部キーとして注文テーブルに入れればいいのですが、
会員じゃない人からも注文が入るので、
注文テーブルに会員テーブルと同じようなフィールド（名前、送り先住所など）を入れて、
注文レコードに、会員ID（外部キー）が無い（NULLの)場合は、同じ注文レコードの名前や住所を参照しようと思っています。

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

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

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

どうするのが一番良いでしょうか

無駄すぎ
注文テーブルと会員テーブルだけでいいですがな

>>483
まず最初にモデル分析について。
前者は論外。注文テーブルでは注文に関する情報だけを定義すべき。
残る後者について、「会員の人」と「会員じゃない人」という概念は、
人に関する集合を意味するわけだけど、これら両方を包含した全体集合を考えなさい。
たとえば「取引先」という概念は一般に両者を包含するからよく用いられる。
あるいは全体集合を「会員」として位置付けて、部分集合を「正会員(会員の人)」と
「会員候補(会員じゃない人)」とに分割するという、逆の発想でもかまわない。

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

どちらの方法を選ぶにしても、注文テーブルの外部キーは取引先IDだけになるから、課題は解決される。

>>483
会員が自分の住所以外を送り先として注文することはないのかな?

>>485
前者は論外、とも言えないんじゃないのかなぁ。
会員IDがNULLの時だけ名前や住所の値を参照するという運用には
とても疑問があるけれども。

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

その場合には注文テーブルにも名前や住所などのカラムを作って
注文毎に会員情報から転記する方法と、少し前に散々議論された
会員情報をサロゲートキー使って管理する方法がある。

論理キー(複合キー)があるのに、わざわざID列を主キーに作るの勘弁してくれ。

単にSingle Table Inheritanceの典型的なケースではないの？

この辺を参考にすれば
http://capsctrl.que.jp/kdmsnr/wiki/PofEAA/?SingleTableInheritance

典型的なプログラマー脳orパッケージ屋さんか？

ではDB屋さん的な回答どうぞ。

・注文テーブル
・顧客テーブル
・会員テーブル

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

会員テーブルには、ID/パスワードなど、ログイン専用のデータだけを保存する。
こうすれば会員じゃない人は顧客テーブルの参照で済むし、
会員なら会員テーブルまで参照すれば良いだけのこと。

・注文テーブル (送り先の名前・住所入り)
・会員テーブル (会員の名前・住所入り)

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

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

判断は会員/非会員の注文の割合とか(非会員の注文が例外的か)
とかにも依存するけれども、単に注文毎に送り先を保存したい
場合は上のやり方が一番シンプルで良いと思うんだけど。

>>484
会員テーブルに、非会員フラグなどのフィールドを入れるということですね？

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

ということは、
>>492
の方法が一番良さそうですかね？
この>>492の顧客テーブルというのは、注文の住所や名前情報などがはいるんですよね？
注文レコードの数＝顧客レコードという認識ですが正しいでしょうか

>>493
この方法も良さそうですね

>>494
・注文テーブル　→　注文日時、ステータス、商品合計金額
・（注文商品テーブル）　→　注文した商品のIDと価格
・顧客テーブル　→　名前や住所
・会員テーブル　→　ログインIDやパスワード

こう考えてみたらどうだろう

>>490
？
めちゃくちゃDB設計の話だと思うけど

>>493の方法でいいかなと思っているのですが、
>>493の方法と比べて>>496の方法（顧客テーブルをはさむ）のメリットはなにがありますか？

>>498
>>493の方法の場合、例えば会員から注文があった場合には会員テーブル
から会員の名前や住所を送り先として注文テーブルに転記する必要がある。
会員の名前や住所はそうそう変わらないだろうから、同じ情報がテーブル
中に繰り返し現れるわけで、そういう意味では冗長でストレージの無駄。
>>496の場合は、これがない。

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

いずれにしても、会員/非会員の注文頻度の割合(非会員の注文も多い場合は
>>493のデメリットは相対的に小さくなる)、会員情報の更新頻度、あと
は注文データの件数によると思う。
ストレージの無駄さえ許容できれば>>493は一番シンプルな解だと思う。

そうか。顧客情報が変更になると注文情報も変更になるから
>>496だと整合性がとれなくなるよな。

>>493の方法は重複が出るけど、「過去○ヶ月のデータまで保存」
みたいな感じで、期限切れのデータは削除するかバックアップすれば
レコードの肥大化も極力抑えられる。

>>497
しかし>>489は回答にすらなっていない。
要件についてツッコミも考察も入れず「○○パターンで出来るよね〜」
なんて真っ先にのたまうのは典型的なプログラマ脳だ。手元の技術しか
見えていない。

「住所」が顧客の現住所(連絡先)なのか配送先なのか、はたまた配送先の
デフォルト値なのか、そういう分析がしっかりされないまま設計に入っても
議論がワヤになるといういい例だな。

みなさんありがとうございました。助かりました。

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

>>493の方法でいこうと思います。
これなら注文毎の住所が保存され、
会員の住所も保存できそうです。
会員の注文のときは、会員テーブルから住所をコピーして注文テーブルへ。
非会員の注文は、そのまま記載された住所を注文テーブルへ格納する。
という実装でいきたいと思います。

>>502
それは設計しながらでいいんじゃねーの？
仕様書作りながら「これはこういう可能性があるからこうしよう」
みたいな意見が生まれるじゃん。483のやりとり見ても生まれてるわけだし。

まてよ、
>>493
> ・注文テーブル (送り先の名前・住所入り)
> ・会員テーブル (会員の名前・住所入り)
この方法だと、例えば新たに「電話番号２」カラムを追加したいときに、
２つのテーブルをいじらないといけないので、保守性の面であまり良いと言えないかもしれませんね。。。

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

>>504のおっしゃるとおり、一人で開発しているので、
つくりながら仕様も決めていくような方式をとっているので、小出しになっていたら申し訳ないです

まとめると、
- 注文テーブル
　・テーブルXのID（外部キー）
- 会員テーブル
　・テーブルXのID（外部キー）
- テーブルX
　・名前
　・住所
　・電話番号
　　　　：
　　　　：

この、テーブルXで名前住所などはすべて管理して、
あらたに会員が「届け先住所２」を追加したい場合は、
テーブルXに新しいレコードを追加して、そのIDを
会員テーブルの「届け先住所２」カラムに外部キーとして保存する、といった形になります。

そもそも規模によっては住所２が必要ない場合あるぞ。
小規模、顧客1000人以下程度ならいらないと思うけどな。
必要な時に追加したら良いんだよ。

会員と非会員の注文比はどれぐらい?
非会員の注文数が多いようだと住所項目等を別テーブルに
切り出すメリットはかなり減るよ。

>>508
現行のショップは会員という概念がなかったので、
今回会員を実装してどれぐらい会員になるかは未知数ですね。
ただ、非会員で買い物をするメリットというはあんまり無いので、
（会員になってもパスワードという入力項目が増えるだけ／会員になると今後の住所入力不要）
会員になる人が多くなると予想はしています。
ただ本当に具体的な比率は未知数です。

会員になる人が多いか否かは商品によるんじゃね？
Amazonのように購入ペースが多いなら会員登録するだろうけど、
電化製品や服とかは、会員登録しなくても買いそうだけどな。

>>509
まず、

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

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

書かれている「新たに電話番号２カラムを追加したいときに」
の場合も、会員テーブルは変更する必要はあるかもしれない
けど、注文票にまで複数の電話番号を書き込む必要があるか?
というのは一度精査してみた方が良いと思う。

>>511
たしかに。
やっぱり>>493がシンプルで良さそうだなぁ。
ぶれまくりですが、とりあえず先に進んでみようと思います。
また問題が発見してから考え直します。

みなさんありがとうございました。

プログラマ脳はどこへ行った?

エンティティとか主キーの概念がなくて
なんでも１テーブルに押し込む、キーはID列のみみたいなのはマジ勘弁

>>514
大福帳テーブルは意外と重宝しますよ。

>>515
うん。する。

NoSQLの設計はまさにそんなかんじじゃない？

.NETのコンポーネントの制限で複合キーを諦めざるを得ない

複合キーは無いわ
全テーブルにid int auto_increment でおｋ

まさにプログラム脳

>>519
つけるべきUNIQUE制約を忘れるなよ。
つけなければならない理由も。

>>519
MySQL脳か。

今一緒にデータ移行の仕事してる人は業務的には複合キーのデータでも
キー値を１つにマージした列をわざわざ作ってるんだよなあ。

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

複合キーでもINDEX張ったりすれば遅くないですよって言っても信じてくれない。

複合キーでもサロゲートでもいいが、キー値のマージは一番アホ設計だと思うｗ

とりあえず日時型をキーに追加するアホが身近にいるので困る

正規化崩しもそうだけど、解っていない人ほど「この方が速い」とか
キリッとのたまうんだよなぁ。

会社マスタ
CompanyID(PK) , CompanyName
01　　　　　　　　　　　A社
02　　　　　　　　　　　B社
03　　　　　　　　　　　C社

支社マスタ
CompanyID(PK) , BranchID(PK) , BranchName
01　　　　　　　　　　　　　01　　　　　　本社
01　　　　　　　　　　　　　02　　　　　　埼玉支社
01　　　　　　　　　　　　　03　　　　　　神奈川支社
(略)

例示した支社マスタみたいな複合キーが使えない場合、
どういうキーを振るのが普通なの？
CompanyID+BranchIDの連結でやってるけどダメ？

ダメってことはないけど、CompanyIDとBranchIDを残してunique制約付けるなら
サロゲートキーは別に本来のキーと関係ある値にする必要はない。

>>527
なぜ複合キーが使えないのかわからん
その例なら、CompanyIDとBranchIDの複合キーじゃないのか？

その例なら単にBranchIDを支社マスタ内で一意になるように振れば良いだけだと思うけど

Companyコードはどこにあるの？

>>527
システム以外の都合でIDが決まる場合が少ない確率ながらある
（ID=1を本社にしたいとか、支社IDを使い回すとか）から、
やっぱり複合キーじゃなくて
全テーブルにIDを振るのがいいと思うんだがなぁ
なんでこのスレの人は否定するのかね

>>531
いや、普通に脳みそ足りなさそうな発想だから否定されて当然。

別に誰も代理キーを絶対に使うななんて言っていないでしょ。
要件をスキーマ設計に落とす過程で必要になった時に用法に注意
して使えば良いだけの話。
そのあたりをすっ飛ばしてトップダウンに「全テーブルにID振る」
なんて単細胞なアイデアを持ち出すから叩かれる。

支社マスタ
BranchID(PK) , BranchName
　　0101　　　　　　本社
　　0102　　　　　　埼玉支社
　　0103　　　　　　神奈川支社

複合キーが使えないケースならこうせざるを得ないだろ
無関係なサロゲートキーでどうやって会社マスタとの紐付けを取る気だ

サロゲートキーを使うならこうだろ。

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

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

「複合キーが使えない」というのが複数カラムのUNIQUEも使えないという
意味なら別だが。

複合キーが使えないってのがどういうことかわからんが
おそらく
CompanyID(PK) , BranchID(PK) , BranchName
01　　　　　　　　　　　　　01　　　　　　本社
02　　　　　　　　　　　　　01　　　　　　本社

みたいなことを想定してるんだと思うが、それなら
支社マスタって書いてるテーブルが、支社のマスタと
会社と支社のリレーション持ってるテーブルを兼用してるのが間違いだろ

それのどこが間違いなのかわからん。

多分どっちでもいいんだよ。
どっちかしか駄目という人が間違ってる

>支社マスタって書いてるテーブルが、支社のマスタと
>会社と支社のリレーション持ってるテーブルを兼用してるのが間違いだろ

なんで間違いなん？

>>535
それが間違いだとして、テーブルを分けたとしても、その場合
会社支社リレーションのテーブルで同じ問題が起こる
そこが間違ってるかどうかは本質じゃない

じゃあ本質は何かっていうと
>複合キーが使えない場合、どういうキーを振るのが普通なの？
ってことだ
複合キーが使えない理由がよくわからんが、複合キーがダメなら代理キー作るしかないわな
代理キーの値をどうするかだが、ぶっちゃけ一意になれば何でも良いわけで
システム的に一意な連番振る機能があれば、それが使われることが多い
その場合は一意であることをシステム側で保障できるから
CompanyID+BranchIDの連結とかでもいいけど、その場合、それが一意かどうか
自分でチェックしないと保障されない
まあどっちにしろ要件的にCompanyID+BranchIDで一意チェックは必要だと思うから
この二つで主キーにしとけばシステム的に一意性が担保されるわけだが

たいていの場合CompanyID+BranchIDが一意になるとは思うが
仮にCompanyIDないしBranchIDを変更することになった場合
キー値も変更しないと気持ち悪いことになる

連番使った場合はCompanyIDとBranchIDから代理キーの値を得るのに
支社テーブル上で逆引きをする必要があるけれども、CompanyIDと
BranchIDの連結をキーにした場合はアドホックに文字列処理でキーの
値が手に入るという利点は一応あるw

ただそういう設計や運用はあまり見ないよなぁ。やはり勘所は複合キー
が使えないという理由がよく分からん事だと思う。
ORMマッパー使っているからとか、DBMSの実装上の制約とか、上司の
オッサンが決めてしまったコーディング規則でそうなっているとか、
理由ごとに必要とされる答えも微妙に違う気がする。

>上司のオッサンが決めてしまったコーディング規則でそうなっているとか

これに500点

いや、単純にコンボボックスのデータソースに出来ないからだよ

CompanyIDを先に選択させりゃいいだろ

>>532
無知で悪いけど、
「全テーブルにID振る」
これのデメリットってなにがあるの？

>>545
何の解決にもなっていないから。

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

「全テーブルにID振る」は実装上の方法論にすぎず、その前段階として
要件の分析をすっ飛ばすことは出来ない
ちゃんと分析をやった上で全テーブルに代理キー振るのなら、いいん
じゃない? ただその場合は当然分析の結果として必要な代理キーと共に
冗長な代理キーも見えてくるはずで、その評価は出来るよね。

もう少し馬鹿にもわかりやすく答えてくれ

全テーブルにID振ること自体は「無駄」以外にデメリット無いよ。
OracleのROWID疑似列みたいな例もあるわけだし。

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

個人的には要件の見落としを防ぐ意味でも、まず初めに自然キーを
主体にしたスキーマ設計に落として、そこから必要に応じて代理キー
を導入するのが一番安全だと思う。
何度も言うけれども、自然キーはまず要件から決まるものだから。

＞表の更新時に自然キーから代理キーの値を得る無駄な逆引きが必要

いや別にいらんだろ
自然キーのユニークネスが保証されてるなら

外部キーとして持つ場合なんかの話だろ

CREATE TABLE tablename (keyid VARBINARY(50) , columnid VARBINARY(50) , value BLOB , PRYMARY KEY(keyid , columnid));
ですべてことたりる

その分アプリのロジックで苦労するわけだけれどもね。

>>551
ガリレオ・ガリレイ

このスレと
【より良い】データモデリング【モデルを】
http://hibari.2ch.net/test/read.cgi/db/1057509675/
こっちのスレって何が違うの？
上流の作業の違いがいまいちよくわからん
モデリング後に設計？設計後にモデリング？

住所の項目ってどうしてるよ？
都道府県と住所１と住所２（マンション名など）
って分け方が多いみたいだけど、
都道府県以外分ける必要ないよね

>>555
たとえばタックシールや送り状を作成する業務を考えると
住所が適当な長さで２行になってる方が都合がいいだろ

業務要件で住所が２行必要ならDB上も２項目でもつのは普通
つまり分ける必要があるかどうかは要件次第

２行かどうかなんてアプリケーション側の問題なんじゃ？

要件に二行で折り返すことが含まれているのであれば、どこで
折り返すのか区切りが解らないと困るじゃん。

改行入りの文字列を住所として突っ込むのもありだけど、住所と
マンション名その他に分けて二つのカラムに分けて入れることが
多いと思う。

アプリケーション側の問題？
データモデルが常にそれらから独立していられるわけでもないだろう。

>>555

+--id--+--henji--+--syugo--+--dousi--|
| １ | YES　 | I　 | DO |
+----------------------------------+

>>555
> 住所の項目ってどうしてるよ？
郵便番号が取得できるなら郵便番号DBを利用する
できないなら総務省の地域コードを使う
コード変換できない番地以下は各レコードに持たせる
最低でもこうしないと話にならない

DB的には住所をコード化するのが先決だわな

2行でタックシール(ｷﾘｯ)とか馬鹿じゃねえの

単に土地住所と建物住所じゃないの？

タックシールの馬鹿を見るだけで、全角英数は馬鹿という定説が正しいことがよく分かる

DB的には氏名をコード化するのが先決だわな

「コード化する」ってなに？

たっくんおかえり

(国)、都道府県、市町村、町域、建物その他で分けるだろ

郵便番号検索とかどうしてる？
新しい市町村増えたり、メンテが面倒そうなんだけど

そうだよ。
だから郵便番号検索機能が仕様にある場合はメンテ分も見越して金額が跳ね上がらないといけない。
現実は「簡単でしょ？付けてよ」でプロジェクト終わり。

要件確認せずに、「だろ」って決め付けてもねぇ。
地番は？住居表示はどうすべきだと思ってるの？

初心者ですDBの勉強もかねて、簡単なユーザ登録のできるBlogサイト作成しようと思っています。
日記のデータを保存するテーブルについて質問なのですが、一般的(他のサイトなど)に日記を保存している
テーブルというのは、1つのテーブルで全ユーザの日記のデータを保存しているのでしょうか？
例えば一般的には、ユーザID,日付,日記本文,(その他省略)という構造なのでしょうか？

この場合、ユーザ数が増えれば相当なデータサイズになり、1ユーザの日記を数日分、selectするのに時間が
かかるような気がします。(この辺が初心者で、時間がかかるのかもよくわかってないのですが・・・)

まぁそのためのデータベースだ
適切な設定なら100万レコードからでも一瞬で目的のレコードを探せるよ

それだと、日記が一日ごとにしか書けないな。

適当な質問には適当な回答しか無いだろ

お前ら、こういうDB設計の要件定義って、
仕事でやる場合どのくらい時間かける？最低1ヶ月はかかるよね

>>570
そういう情報ってどっかにAPI公開されてないのかな
もしくはデータが簡単にダウンロードできたり

>>577
データは郵便局サイトに
コンポーネントもググれば簡単に見つかる
大概↑データを使用する前提

つーか、ろくすっぽ調べず「郵便番号メンテが面倒」とか、「住所は二行でタックシールだ！」
とかその手の足りない子を見ると、正規化だのサロゲートキーだのを熱く語る前に、他にやるべき
ことあんじゃねえのって感じだな

なんか、面倒だな

それでも地球はまわっている

そして原発は冷却中である

>>568
そんなの、実データ使った解析でいかようにもできる。
客が入力したままの文字列を一つだけ保持しておけば、あとは正規化した住所を都度アプリ側で吐き出せばいい。

>>583
アプリに全部任せてDBは設計もクソもなくていいって聞こえるが・・・

座標保持するのが流行り

>>585
ダイレクトメールという文化はやがて滅びるから
企業の視点では、住所や所在地情報の地位は
低下し続けるに違いない。

>客が入力したままの文字列を一つだけ保持

こんなこと書いてるエセ設計者の言うことは無視でよろし

エセというか、ただの馬鹿だろ

せっかく公共団体の統一コードがあるのに文字列で持たせるとか正気か？
どうせAccessあたりで糞アプリ作ってる底辺プログラマだろけど

DM用や顧客用のデータなんだろ？
正規化用のデータを、持しても客が使うデータは、たとえ間違っていても入力のママで使うんだよ。
現場も知らない馬鹿が教科書通りに設計すると回らないから気をつけろw

正規化と言いたいだけの中小企業Access使いとか、底辺を見ても何の参考にもならないし、
時間の無駄だから、まともな知能を持った人は郵便番号DBや地方公共団体コードを使いましょー

馬鹿にしてるつもりなのかな？拙い日本語使って煽られてもねぇ・・・

ハンマーを持った子供には何でも釘に見える

地方公共団体コードなんて覚えたての子供は、「住所」と出てきたらコードを
使わなきゃ気が済まないんだよ。

まあ、要件も確認せずに何とかコードでOKとか言うやつは
まともな知能を持ってないってのは解る

あと底辺の人ほど他人を底辺だって決めつけるよな
バカっていうやつがバカ的な感じ

たっくんおかえり

>>590
名寄せのロジックの一部には郵便番号DBも使うが、あくまでも一部。
おまえ、日本全国の何百万という重複する住所の名寄せなんてしたことないだろ。
したことがあれば、あんな不完全なデータを錦の御旗にドヤ顔出来る訳がない。

>日本全国の何百万という重複する住所

具体例どぞ

>>596
どこそこ区の青葉台となになに市の青葉台で一例。
この組合わせを合計するとそんな数になりそう。

>>597
そういうのは都道府県が違うので重複とは言わない
もっと例示するにふさわしい具体例を挙げるよろし

>>596
数十万単位のユーザーが十数年にわたって複数回入力する住所の名寄せだよ。
当然ユーザーからしてみれば同じ住所でも入力パターンは間違いも含め多岐に渡り、市町村合併や郵便番号も変わるからね。

他にも英語表記やカタカナ、ひらがな表記も含む。
市区町村の区分も守られておらず(特に町と村。そもそものインターフェースが郡で区切ってたりする)、都道府県が空白なんてざら。
複数のインターフェース、複数の時代を経た巨大な住所データなんて蓋を開ければこんなもん。
入力時に住所が正規化される単一のシステムならなんの問題もないけど、そうでない上記のようなデータなら、住所は一旦すべて連結し、解析掛けるのが正確で早い。

だからコードにしておけば手入力を解析だ名寄せだとかキチガイじみた発想にならんのだって
ためしに通販サイトかなんか見てみろよ
大抵、プルダウンから選択か、郵便番号から選択だろが

逆に手入力のメリットがあるなら出してみろや

>>601
日本語分かるか？
入力時に正規化出来るなら問題ないがと書いてるだろ。
新規で開発するような話をしてるんじゃなくて、手書きも含め、複数のインターフェースが存在することが前提のデータ処理の話をしているんだが。

>>601
そして、コード化の一番のデメリットは過去の住所はにたいおうしづらい

>>601
失礼、途中で送信してしまった。

コード化のデメリットは過去のデータに対応しづらいという事。購入、決済データぐらいじゃそこまで気にする事はないし、下手すればそもそもの住所の正規化すら要らないケースが多いけど、
過去にさかのぼる名寄せみたいに、コード化よりも解析のほうが現実てきなケースがある事を知っておいて損はない。

>>602
> >>601
> 日本語分かるか？
> 入力時に正規化出来るなら問題ないがと書いてるだろ。
名無しIDなしでお前のレスがどれだかわかるわけねーだろw
つーか、DB設計の話をしてるのに名寄せだ解析だとか言い出すから、
頓珍漢に拍車がかかるんだっての

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

言ってることが支離滅裂だっつーのw

>>605
要するに何の話をしているんだい。

>>605
わざわざ599と入れてるのも分からない馬鹿かw
だから、DB構造としては、住所は一つまのカラムしかもってない(まあ郵便番号くらいは持つが)と言う事だよ。
一応、入力時は分割されてるが、それを連結したものが正式なデータとしてつかわれる。
正規家した住所は複数のカラムを持つが、それは都度都度の最新住所を吐きだすワークテーブル扱い。
高言う実例もあるんだよ。

>>606
・住所をまんまの文字列で持つメリットは全くない
・文字列を保持して解析とか言ってるのは池沼
・名寄せとかいきなり言い出してるのは馬鹿(同じやつだろうけど)
・タックシール(ｷﾘｯ

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

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

といことで逃亡

大変だなぁ。で、設計の話はどこ？

>>608
コンバーターは、それぞれの企業が自社で使う必要があって開発したものなことも知らないのか。
どんだけ小さな現場しか知らないんだよw
入力データを正規化して保持して、オリジナルを破棄出来るなら苦労はないんだよ。
自分の知らないしくみがあることは恥でもなんでもないのに、実例紹介してるのに信じないなら勝手にしろw

変換ソフトの稟議書作成じゃね？

>>610
設計の話しないなら帰れよ。

コンバータってこれか
http://www.addressmatch.jp/anormapp/do_anorm

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

でももう埼玉は住みたくない

正直、なぜこんなのでこの人たちがここまで熱くなれるのか疑問ではある

かつてクラス名簿を頼りに好きな娘の家の住所を探し歩いた経験からです

>>612
一応、設計上、住所がひとつの構造の実例もあるよ、という話だったが...
まぁ、確かにそろそろスレチだな。失礼。

スレチ以前になんの参考にならないからもう出てこなくていいお(^^

厳密に言えば設計じゃないのかも知れんが、要件定義、モデリングの話題としては興味深い。

市町村コードと住所正規化コンバータの存在は確かにためになった
サロゲート談義よりよっぽど

このスレ市町村コード知らない人が見てたのか

>>620
私は公的なものは大嫌いだから。

よくわからんけど、話題終了した方がよさそうなのはわかった

>>621
ねっこのおりん

「都道府県がなぜ北海道始まりなんだ！」と言われたらJISを参照する

>>621
ただの馬鹿ですね

まあ市町村コードなんて、馴染みのない人には全くない系統の知識だからね
いつなんどきどういう案件が降ってくるか分からないんだから、普段から
色んなことにアンテナを張っておくことが大切だってことさ

> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ

それで結論として、
住所はユーザが打ち込んだひとつの欄でいいね。
エラーがあるかとか、いろいろ解析するのが楽しみでね。

はいはい、タックシールタックシール

>>628
結論は、色々なケースがある、だろ。
住所一つ厨も、自分のケースは特殊と言ってたろ。

その場かぎりのアンケートみたいなのは使い捨てでいいんさ
顧客情報が絡んで将来的にDWH的な使い方がありえるんなら、
コード化にコストを費やすことを考えなくちゃならない
つか、そう提案すべき

ちょっとご相談というかむしろどのような方法が一般的なのか判らない状態での質問です。

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

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

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

カレンダーデータは

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

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

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

なんらかの定石的な方法があるのであればいいのですが、そのようなものは社内にないようでして・・・
何らかのヒント的なものでもいいので、お手すきの方がいらっしゃいましたらご教示いただければと思います。

>>632
種別が一つじゃ、臨時営業だけど、実は定休でなおかつ祝日の日とかどうすんだよw
種別は全部バラしてマスタにしろ。
それぞれの重み付けは固定ならアプリで持ってもいいし、変動するならこれもマスタにする。

>>632
今考えてみた
T/種別( ID 名称 )
T/ルール（ 月 日 曜日 何週 優先度 開始 終了 種別ID ）
T/カレンダー（ 年月日 開始 終了 種別ID ）
V/カレンダー（ 年月日 開始 終了 曜日@年月日 何週@年月日 種別ID ）
カレンダーをデフォルト値で1年分生成してからルールを適用する

俺ならこうするかも知れない

>>632
例えば、毎週休業日が年に三回変更になったとして、
そのルール・ログが残らないような設計はおかしい。

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

というようなテーブルを定義していくべき。

おはようございます。
>>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週)だけを持ち、
ビューやストアドなどで結果を返すほうがデータの無駄が無いかもしれませんが、
参照の回数とかを考慮して少しデータ量が増えますがあえてテーブルに書き込むようにしてみました。

設計て難しい、でもこれしっかりやらないとアプリがグダグダになってしまうので
妥協範囲を出来るだけあげてキッチリやっておきたいです・・・

曜日、何週をビューで定義したのはバグとミスオペでの変更を抑える為
634の形ではルール適用で必要になるから持ってる
636の形はよく理解できてないけどあんまり必要じゃない気がする
ぱっと見TM_祝日はハッピーマンデー対応できない気がするけど毎年修正するのか？

>>635
毎週休業日の変更とかどの業種でもかなり大きい変更だから年数回どころか数年に1回だと思うけど

>>637
TM_祝日は基本年次処理でつどつど祝日をyymmddで保持するっぽいから、ハッピーマンデーも問題ない気がする。

>>638
そこでやるのか〜
ずいぶん高度だな

>>639
高度というか、力技だな。単純だがそれがいい。
管理者も入れ替わり、運用がおざなりになったときに、日付の入力を忘れたり間違えたりして支障が出る可能性は高そうだがｗ

>>637-640
色々なご意見ありがとうございます。

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

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

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

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

PS.
仕様書・設計・レビュー・PG・デバッグ・設置と納品まですべて一人でやらなきゃいけないので頭が沸いてきました。

>プログラム内で1月1日は元旦、1月の第2月曜日は成人の日などの情報を持ち
>その部分をDLLなり設定ファイルなりにして
なぜそれをＤＢに格納しないのかね

>>642
年次更新のタイミングでその情報をDBへ格納します。
定義が変る可能性が高いので年次でギリギリまで登録待ってから登録→もし年内で変更あれば手動で変更
という予定です。

ハッピーマンデーも将来無くなる可能性がある。

祝日をyyyy/mm/ddで持つのもありだね。

>>643
その年が変わってから、
その年の休日が変わる可能性なんてないよｗ

>>643
>定義が変る可能性が高いので
変わる可能性が高い情報をプログラム側に持たすのか？
休日の定義もＤＢにもたせて、その定義から年次更新でマスタ作成すればいいだろ

休日の定義を持たせたら、その休日の定義の有効期間まで保持しなきゃならなくなる。
だったら、素直にyymmddで休日を持たせたほうが話が早い。

過去となった祝日は絶対に不変なのだから、yyyy-mm-ddで決め打ちでいいと思うけどな〜

祝日どころか全部過去適用なしなんだから有効期間ってのがなぜ必要なのか意味が分からない
単に、ルールで持てば？展開して日付で持てば？って話のような気がするけど

>>649
例えば、極端な話、元日が1月1日ではなく、1月10日に変更になったとする。
当然、過去の1月1日には適用できないので、いつから元旦が1月10日になったのか日付を保持する必要があるだろ。

別にないよ。
2010/01/01
2011/01/10
って持っとけばいいだけだから。

>>651
だから、それでいいじゃん、と言ってるわけだ。
休日のルールを定義づけして、DBで保持する必要はない。

>>650
ごめん、>>646の解釈が全然間違ってて見当違いなレスした

生成よりも反映でやった方が色々いい気がするけどなぁ
延々増え続ける祝日テーブルとか嫌だわ、俺は

おめーの好き嫌いはどうでもいい

>>654
ちょっと笑ったw
それにしても、ID出ないと議論もまともにし辛いね。
IDなしでもOKの理由ってなんかあるんだっけ？

>>653
反映ってのが、ルールを動的に適用するって言う意味なら
ハッピーマンデーや春分の日を動的に適用するのが難しい
逆に、定休日の変更とか考えると動的に適用する方がいいかもしれん
ただ、生成にしても反映にしても、過去分切り捨てないなら
延々増え続けるのに違いはないと思うが

生成あるいは反映されたカレンダーをどう使うかにもよるだろうけど
変更の頻度とカレンダーを使う際のパフォーマンスとか考えると
俺なら適当なタイミングで生成する

まさに今度の案件で、FROM年月日、TO年月日で営業日やそれ以外を保持する必要が出た。

祝日などは FROM:2011/01/01 TO:2011/01/01 名称：正月

夏休みでもないと1日単位の方が効率的な感じだな

こういうテーブルは差集合を取るために使うことが多いしな。
1日1レコードの方が何かと無難に思える。

ここのスレのひとたちのレベルとは違いすぎるんで恐縮なんですが、、、
インデックスって何に設定するのが良いんでしょうか。
たとえば、掲示板の投稿テーブルとかだとなににインデックスを設定したらいいでしょうか

検索キーに張ればいいよ。

>>661
検索対象となりえるフィールドってことでしょうか。
今は名前と、本文メッセージで検索できるようにしてるので、
それらにINDEXつけたらいいのかな？

名前はアリだろうけど、本文メッセージはインデックスの意味ないだろうね。

>>663
文章が長すぎるからですか？

あと、
postテーブル　（投稿
tagテーブル　（タグ
こういう２つのテーブルがあるとして、
postテーブルに複数のtagがつくような場合（多対多であってますか？）
postとtagを結びつけるテーブルが必要だと思いますが、
このテーブルの名前がいい感じのが思いつきません・・・。
みなさんこういうテーブルは何テーブルと名づけてますか？
post_tag_relation
とかかな？

テーブル名はそのものズバリの短い名称ならなんでもいい、SQLでの記述量が全体的に減る。
短くなるならローマ字表記もありだと思う。

＞postとtagを結びつけるテーブルが必要だと思いますが、
そもそも直に結び付かないのがなぜかと問いたいが。
関係性が複数あってアナリシスパターンみたいに知識レベルと操作レベルに分けたいならともかく。

>>665
短縮しようとすると必然的に漢字になる。

>>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
ありがとうございます。
え、%LIKE%でやってて、全く問題なく動いてるんですけど、
書き込み数が少ないからいけてるだけなのかな

LIKE句で早いかどうかはDB側のエンジンに依ると思います。

ネーミングは、『R_投タ』だろ？

件数とフィールドサイズ次第じゃね？

１　業務の区分番号で自然キー設計した
２　削除履歴も残したくて削除フラグを作った（行を複製して削除=1する)
３　削除フラグを立てた行を作るとキーが二つになってしまう！
４　履歴を沢山もてるように削除日を作った
５　（自然キー + 削除フラグ + 削除日）で複合キーに変更した
６　履歴行を除くためテーブルを結合してからwhere句で削除フラグ=0することに
７　クエリを１０段階くらいネストしてモリモリ書く
８　なんかデータが欠落してると思ってたら、INNER JOINしてることに気が付く
９　手の施しようがなくなって俺のとこにお鉢が回ってきた


こんなデータベース管理したくねーよカス。だから女は嫌いなんだ

>>674
8はたしかにバカだけど、ほかはまあ
しかたないんじゃね？

てか別に手の施しようがなくなってもない気が

クエリ10段階程度は、普通とは言わないけどたまにあるなー。
インデックスちゃんとはってたら結構パフォーマンスも出るし

> （行を複製して削除=1する)
なんで複製するの？

思うに区分番号を使いまわしたいんだろう
つまり、もともとも区分番号は候補キーじゃなかったって話で、
１から間違ってるってことだな

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

そこは自然キーじゃなくて区分番号だろうと突っ込みたいが
>>674は区分番号がキーじゃないとちゃんと解ってるのかね

何のテーブルとどう結合したのかよくわからんのだが、削除日だけだと
日付が絡んだ結合がかなり複雑になりそうな気が。
作成日も加えるとか、それこそサロゲートキー導入か。

削除した事実と日付、元データのログだけなら、削除テーブルに退避させるだけでいい。

>>678
よくわからないが、同一テーブル内に履歴があれば管理
しやすいと思った形跡がある。。テーブル開いてすぐ下に
履歴があるので、どう変更したか見やすいとか。

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

書き間違い。すまそ

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

>>681
普通の人間が考えればなそうだな。考えたやつが普通の
人間じゃないから困る。

ログ管理用のテーブル設計の難しさは異常

ＤＢ設計のコツは、「難しく考えるな。あきらめろ！」

>>683
何が難しいの？よければ要件を教えて。

>>683じゃないけど、全文検索のこととか考え出して、行き詰まってんじゃないの

モデリングの勉強をしているのですが以下のような場合、どんなモデルになるでしょうか？

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

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

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

よろしくおねがいすます

商品マスタと
発注先マスタと
受注テーブルを用意して適切に紐付け

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

おしまい

１つの受注には、いくつかの商品があり、その商品は発注先はバラバラです。

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

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

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

発注まではこんな感じだとおもっています

>>689
なぜ、「配送先住所」が「受注」と「発注」の両方にあるの？
なぜ、「数量」と「商品番号」が「受注明細」と「発注明細」の両方にあるの？
よく分からない。

>>689
一つの「顧客」は、一つの「配送先」を持つの？
それとも、一つの「顧客」は、複数の「配送先」を持ちえるの？

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

このあたりがはっきりしないと答えがだせないよ。

>>687
メインのフローは馬鹿でもできるから、適当に組んでもみんなほぼ同じモデルになる。
ちゃんと考えなきゃいけないのは、返品、誤配送、破損、誤発注、キャンセル、郵送先変更、在庫切れなどの例外処理のフロー。

>>692
勉強って書いてあるべさw
そこまで細かくやらんでしょ

サロゲートキーってのは調べてみると
「ユーザーが認知しない、業務的に意味をなさない連番とかのキーにせよ。」というのは理解したんだが
このサロゲートキーは検索画面の条件や帳票項目とかに利用していいのかしら？

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

この場合、伝票番号とは別にサロゲートキーを持つのか否か。どうおもう？

迷うまでもなく持つわ

＞このサロゲートキーは検索画面の条件や帳票項目とかに利用していいのかしら？
いい。サロゲートキーにする意味は、未来永劫不変で一意であることを保証することだから、
IDとか識別番号とかいう名前で利用することはある。

＞この場合、伝票番号とは別にサロゲートキーを持つのか否か。どうおもう？
伝票番号が一意のサロゲートキーになるならどっちでもいい。

どうもです。

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

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

ユーザーが認知すると、ユーザーの使い勝手で「伝票番号に日付入れてくれ！」とか言われたら
未来永劫不変で一意であることを保証できんな

伝票に日付、アルファベット、ゼロ埋めはザラにある変更

a

>>697
キーの一意性が変わるような変更に対して、サロゲートキーが対策になる
なんて思っていたら痛い目見るよ。

> キーの一意性が変わるような変更
？

「未来永劫不変で一意であることを保証」できなくなるような変更のことだろ。

>>700
キーって何のことだ？主キー？候補キー？

候補キーが、候補キーじゃなくなるような変更がありえるなら
（その前提がある段階で候補キーかどうかあやしいが）
その候補キーを主キーにしないでサロゲートキーを使うのは対策になるわけだが
お前の言う痛い目ってどんな事なんだ？

>>703
主キーを追加しなくてはならなくなることだろう。

>>704
サロゲートキーを使うっていうことは
当然そのサロゲートキーが主キーになってると思うんだが

サロゲートキーの一意性が保証できなくなるって話なのか？

そんな風にシステム内部で発行する人工キーだけが唯一の候補キーになっているテーブル
だらけで、投入するデータがinsertされるべきかupdateされるべきかわけがわからない状態に
なってしまったシステムは見たことがあるな。
キーが無いのと同じことなんで、注意深くやらないと破綻するのは目に見えているんだけどね。

>>706
> 投入するデータがinsertされるべきかupdateされるべきかわけがわからない状態に

サロゲートキー関係なくね？

関係ないよ。
「サロゲートキーで一意性を保証」するから大丈夫なんて言えない例。

魔法じゃないんだから、サロゲートキーに何期待してるんだよ (w

>>708
いいえ
バカ除けを施しても破綻させちゃう逸材が居る限り大丈夫なんて言えない例です

なんで、このスレのやつってサロゲート談義が大好きなん？

バカ除け？サロゲートキーしかキーが無いテーブルがバカそのものじゃん。

馬鹿寄せ呪文「サロゲート！」

サロゲ廚、自重しろ

fjのmalloc/free論争みたいなもんだな。季節の風物詩。

>>706
イメージできないから具体例あげてみて

このスレで使われている「主キー」という言葉は、
ほとんどの場合「候補キー」のことだよね？ｗｗ

>>716
(ID,NAME,VALUE)というテーブルがあって、IDがシステム内部で生成するキーで
これが唯一の候補キーだとする。ここで
(1,'田中',100)
(2,'田中',200)
というレコードが既に存在している状態で新たに('田中',300)というデータを
テーブルに反映させるとする。
このとき、ID=1を更新すべきかID=2を更新すべきか、あるいはID=3として
追加すべきか？

田中,300じゃ。IDがNullじゃん。
そんなデータ、入力段階でエラーにしろw
他の例を。

IDは自然キーじゃないんだからシステム側で発行しなきゃならんだろ。

>>718
それは業務要件によってきまるのであって、データモデルで決まるのではない
指定した行を更新する必要があるなら、行を特定する必要があるだけで
その特定が他のテーブルとの結合によるが、そのテーブルに自然キーがなければ
サロゲートキーが必要になるだけ

ちなみにこの例で、このテーブルだけみてID1を更新すべきかID2を更新すべきか判断できるなら
(NAME,VALUE)が候補キーでないと話がおかしいんだが

だから、「サロゲート」キーで一意性を保証していたとしても
それだけじゃあ何も解決しない例なんだが。

>>722をプロジェクトから外せば解決するんじゃね？

反論はできないけど、やり込められたままじゃ業腹だから何か言い返したいｗ

DB設計とは無関係。
はい論破

>>722
サロゲートキーで一意を保証していれば、
そのキーを使って他のテーブルと結合することで判断できる（可能性がある）
他に候補キーがなければ、サロゲートキーでしか結合できない

つまり、サロゲートキーがあるおかげで判断できるようになるんだから
サロゲートキーで解決する事象ですが？

もうさ、サロゲートキーｽﾚでもつくってそっちでやれよｗ

私には>>721が言い得て妙、という気がするのだが、違うのかな。

というか、サロゲートキーについて、一言言わせて欲しいんだけど、
連番･･･とか、ID･･･とか、意味不明な名前ではなくて、
それが単なる連番だったとしても、〇〇番号･･･みたいに、何かしら意味の通る名前にして、
それを表（画面とか）にだしたほうが絶対、設計的にも利用者的にも優しいと思うんだけどね。

それをやると、もうサロゲートキーの定義から外れるのかもしれないけど。

>>726
結合先のテーブルに本来のキー(サロゲートキーが代替する被代替キー)が
存在するという前提ならば、サロゲートキーを使わなくても解決できる話なんだが？

他に候補キーがなければって書いてあるぞ

他に候補キーがない2つのテーブルでの話？
だとしたら1テーブルの話と同じじゃん。結合したからといって何も変わらない。

>>718
なにがしたいのか全然わからんなw
でもサロゲート無かったら、
田中,100
田中,200
みたいな主キーが無いテーブルになるんでしょw
サロゲートあるほうが、マシじゃ無いの？

キーが存在しないことが問題であって、それに形式的なキーを追加しただけで
何かが改善すると思うことが間違い。

キーが存在しないことだけが問題なら、サロゲートキーで解決する
キーが存在しても意味がないなら、サロゲートキーも意味がない

>>718は後者な

スレたてて他所でやってよ
信者がいる訳でもないのにそこまで必死に否定することもないだろうに

>>736
どうせ他に話題も無くて過疎ってるのに、なぜそんなに嫌がる

>>735
なんだ？キーが存在しても意味がない場合って。

なんか設計ミスをどうフォローするか、
と言っているようにしか見えない。

ミスというか、718の例でどちらかの行しか更新してはいけないなら
キーをつけろとしか言い様がない

そのキーが問題なんだろ。>>718は一応キーが付けてあるわけだし。

一応キーが付いてるのであれば、
反映するデータが('田中',300)じゃ足らんでしょ、対象のIDもくれなきゃ

>>718は、もう少し業務を説明してよ。

(1,'田中',100)
(2,'田中',200)

「1」、「2」はシステムが自動で採番するキーだということは分かった。
「田中」、「田中」っていうのは、人の名字だと思うんだけど、1行目と2行目は同一人物なの？
田中だけなら、同一人物でない場合もあり得るよね？ｗ
「100」「200」っていうのは具体的に何の数字なの？ｗ

これはどういう単位で何を管理している、どういうテーブルなの？
全く意味が分からない。

こんな状態（情報がほとんどない状態）で、あるべき設計を語るなんて、できるわけが無い。
だから不毛な議論になる。

サロゲートキー云々以前の問題。

そういう分析がないとわけがわからないだろ？
そういう状態で、キーがないからといって連番のキーを追加して「これで一意を
保証できる」なんて言ってもなんの解決にもならないわけだ。
語っているのは「あるべきでない」設計の方。

>>744
何がいいたいのかわからないが、詭弁に聞こえる。

>>742
そのIDをどこから得るかっつー話だ。

大体IDが主キーなんだから更新ならIDでどれかを指定してこなきゃ。
ID無しで更新か挿入かわからないで「反映させる」って言ってる
時点で何かおかしいよ。この例ではIDを何にも使ってないんじゃ。
例えるなら、安全のためにブレーキを付けたけどブレーキを踏まず
事故りましたみたいな。
事故ったからブレーキは不要みたいな三段論法で攻めてくる人も
頭がおかしいよ。

まぁ根元の>>706からしておかしかったからな
人工キーを採用してるのに
このタプルに人工キー割り当てたかどうかわかりませんけどよろしくやってください
なんて言ってきたらぶち切れるわ

だから、キーがない/特定できないテーブルに一意のIDを付けたところで、
それだけで何か改善するわけじゃない。最初から言っていることなんだがな。
>>747
「ブレーキは不要」じゃなくて「それはブレーキじゃない」だな。

いい例えがあります。
0でも1でもないNULLの扱いについて
「ガソリンが空の自動車と、ガソリンを入れる場所が無い自動車は違う」

そろそろ次の問題に行こうよ。

>>749
おまえは本当に詭弁ばかりだな。

それはブレーキじゃないって、じゃあなんだよ。
事故りそうになったら勝手に止まったり、自動回避するのが
おまえのいうブレーキなのか？日本語しゃべれ

じゃあ、なにがどうブレーキになるのか説明してみな。

俺の言い方のほうが正しい
っていう話ならどっかよそでやってくれんかな

アクセスが失敗した場合にエラーメッセージを記憶する方法として

[アクセステーブル]
アクセスID PK NN AUTOINCREMENT
アクセス時 TIMESTAMP DEFAULT CURRENT_TIMESTAMP
エラーメッセージ TEXT

とするか

[アクセステーブル]
アクセスID PK NN AUTOINCREMENT
アクセス時 TIMESTAMP DEFAULT CURRENT_TIMESTAMP
エラーあったか？ BOOLEAN

[エラーテーブル]
アクセスID PK FK NN
エラーメッセージ TEXT

とするのはどちらがいいのでしょうか？
頻繁に失敗するようなものじゃないので
BOOLEANのほうがいいのかな？なんて思ってこうしました
エラーあったか？どうかのフラグ自体いらないでしょうか？

いらん。

>>756
真ん中の案は、エラーの有無が分かるのみで内容が分からない。
下の案は、エラーの内容はメッセージで分かるのだろうが、日時が分からない。

単純に情報量の観点から、上の案がよいのでは？

はい。次の問題お願い。

テーブルを1つにするか、2つに分けるか
聞いてるんじゃないの？
下の案でもいいけど、フラグはいらんな

>>756
それだけだと上側を使って、エラーなしの時はエラーメッセージを空にしておけば十分だと思う。

あと、下側のだけど、エラーあったかフラグは論理設計としては要らない(エラーテーブルを見ればわかるので)。
実装でも、(エラーテーブルの参照がボトルネックになるとか)よっぽどじゃない限り要らない。多分、ビューで十分。

論理設計としては、エラーに付随するデータが他にもあったり、追加される可能性が高いなら分割しておくと分かりやすい。
ただ、実装の場合、分割すると使い辛くなるので、1つのテーブルにまとめることも多い。
どこまで論理設計に近い形で実装するかは人によって優先順位が違うので、性能要件を満たす範囲で自分で決めて。

エラーなしなら、そもそも登録しなきゃいい。

みなさんどうもアドバイスありがとうございます
みなさんの意見を総合的に判断して
一番上の案でいこうと思います

create table a (
aa int primary key not null
);

create table b (
bb int primary key not null
);

create table c (
aa int foreign key references a(aa),
bb int foreign key references b(bb),
primary key(aa, bb)
);

create table d (
aa int foreign key references c(aa),
bb int foreign key references c(bb)
);

この時dのaaが参照してるのは結局aのaaということになるんでしょうか？

なんか色々勘違いしてました。
リファレンスってかいてたので、
親の値(aのaa)が変わったら子の値(cとdのaa)も変わると思ったら、
そういうもんじゃないみたいですね。

ON UPDATE を指定すれば、そういうこともできるけどね。
あと、スレ違いだよ。そういう質問は質問スレに行ったほうが良いよ。

ありがとうございます。
そちらのスレで質問かえてきいてみます。

他のテーブルで同じ列を扱う場合
名前は一緒にすべきですか？
そのへんのサイト見ると別の名前にしてたりするようですが・・・

CREATE TABLE foo ( foo_id INT(5) NOT NULL, PRIMARY KEY (foo_id) );
CREATE TABLE bar ( bar_id INT(5) NOT NULL, foo_id INT(5) NOT NULL, PRIMARY KEY (bar_id) ) ;

>>767
設計とペアで考える事柄です。
その2つのテーブルは関連性があるから同名の列項目があるんですよね？
たとえばmemberとmember_detailとか。

テーブル通しが親子関係なものであることを想像します。
（非常に関係が深い）

反対に同内容で別列名があるなら、子の関係にあるものが、
親とは違うタイプのどれかのテーブルの”親”である事を想像します。
（親と孫との関連性が低い）

どうでしょうか。

>>768
おっしゃるとおり関連性があるから同名の列項目があります
ただ外部キーとしてるわけでないので関連性があると言っていいのかよくわかりませんが
関連性を高めるために外部キーにすべきでしょうか？

>>767
自由。

個人的には、カラム名は、テーブルに
対して定義するものだと認識している。
つまり、他のテーブルと同じカラム名に
なるかどうかは、テーブルとカラムの
役所による。

>>767
ここで「他のテーブルで同じ列」と言っているのはfoo.foo_idとbar.foo_idのこと？
それらの定義域が同じ(bar.foo_id=1はfoo.foo_id=1と同じ値を意味している)ならば
同じ名前を使うのが自然だと思うが。

リバース出来るツールで名前解釈しかないのとかもあるしね

同じものを表してるのに
名前が違うのは不自然だろ

joinの結合条件にusingってのがあるが、
あれは、同じ項目名であることが前提
つまり結合に使うような同じ項目は同じ項目名にしておけってことかと

それ以外で同じ項目が違うテーブルに複数存在するのは設計的におかしいので
違う名前を付けるべき

>>767
「関連性がある」だけではなく、具体例を挙げてください。

例えば･･･

受注：（*受注番号、受注件名）
受注明細：（*受注番号、*連番、商品コード、数量、単価）
商品：（*商品コード、単価）

上記の場合、
受注と受注明細における「受注番号」は、当然同じ名前にすべきだと思う。

但し、
受注明細と商品における「単価」は、同じでもよいし、違っててもよい。
なぜなら、商品の単価は、現時点の単価であり、
受注明細の単価は受注時点の単価だから。

この単価の例の場合、
個人的には、列名は同じだとしても、せめて日本語名は（区別する意味で）違ってて欲しいと思ってる。
（受注時単価とするなど）

できるだけ他人に仕様を勘違いさせない･･･
という観点も、命名の上では大事だと思う。

hoge.id、FKでhoge_idとかついやってまう・・・
hoge.hoge_idはなんか冗長な感じがして

まぁ、どっちでも良いが、最初に決めたルールは守ってくれ。

>>775
DB設計は初心者です。質問です。
受注明細に*連番とありますが、なぜこの項目が
入っているのですか？

なかったら、明細行が特定できないじゃん。

>>778
DB構造=帳票レイアウトにしたいからじゃないの。

>>779
「商品コードで特定すればいいじゃないか？」･･･というのが、>>778の言いたいことだと思います。

>>778
>>775はあくまで例です。

実際のところ、「同一受注番号内に同一商品コードを持つ明細は複数存在しない」
･･･という前提があればご指摘のとおり、連番は不要でしょう。

･･･が、この前提を覆す状況はいろいろと考えられると思います。

例えば、
受注は明細単位で取消可能とする。
受注明細の取消は「数量にマイナスの数値を入れて登録することで管理する」
･･･という（少し無茶な）要求があったとしたら？

例えば、
同一の商品を10個受注した際に、「3個はA社、7個はB社から仕入れて販売します」
･･･という状況が業務上ありえるとして、それが事前に（受注登録時点で）分かっている場合は、
明細を分けて登録する運用としたい…という（これまた少し無茶な）要求があったら？

つまり、
「連番は無いのが正解」･･･ではなく
「いや連番はあったほうがよい」･･･でもなく
「>>775にある情報だけでは、一概に決められない」が正解だと思います。

>>776
RDBMSにおけるテーブルとカラムは、1:n関係ではなくn:m関係であると
激しく主張したい。

>>776の意味をどなたか解説して下さい

>>783
foo . id、bar . idと2つのテーブルにそれぞれidがあり、互いに関連性（例：親子関係）があるとき、
bar には bar . foo_idという列があるが、SQLを書くときは WHERE foo . id = bar . foo_idとなる。

同じものを表しているのに、名前が異なるので混乱する可能性が高い。

ただし、実際のOSSでもたまに見るので、上記の書き方で違和感が無いなら別にいいのでは？

>>783
CREATE TABLE User (id INT, PRIMARY KEY (id));
CREATE TABLE Profile (user_id INT, FOREIGN KEY (user_id) REFERENCES User(id));

恐らくこういう事かな？
RoRのActiveRecordがこの命名規則だったはず
俺は合理的で好きかも知れん

ORマッパーだとよくある規則だな。＞hoge_id
SQL自動生成時に都合がいいらしい。

ただいかにも「ORMを使うために決めたDB構造」で
俺は好きじゃないが。

もともとのRDBの考え方では、テーブルX(A,B)というのはAとBの間に何らかの
関係があるときにそれをXと表すということであって、「XのA」じゃないんだな。
それはエンティティやオブジェクトとしての考え方であって。
だから前者の考え方に立てば、X.idとY.idが同じものを表していないならば同じ名前を
付けるべきではない。
優劣をつけるつもりはないけど、どっちの考え方でいくかは意識しておいたほうがいい。

>>787
表は集合の境界ですか。目から鱗
その考え方ならば foo_id だけじゃなく他の属性も foo_name, foo_time
の様にしないと命名に一貫性がないような…

リレーショナルモデルではそう。foo_nameとbar_nameが別のnameを表すなら
そのようにしておくべき。逆にnameという属性がスキーマ内で唯一のものであれば
nameのままでもかまわんけど。

実際のとこ
nameとかだとちゃんと区別できるように別の名前にするんだが
IDとかそのままの場合が多いよね

>>789
nameだって変域に付けた呼び名だから、同一概念を指すなら共通にするべき。

この場合の「同一概念」ってのはどういう意味？

すべてのものに名札が貼ってあってその名札をnameと呼ぶ、みたいな。

氏「名」も市町村「名」も同一概念ってことか。
いわゆる森羅万象テーブルを作るならそうなるな。

>>794
そういうことになる。
四季{春,夏,秋,冬} が対象となるフィールドがあって、
このテーブルではもっぱら春と秋しか使わないに違いないから、
四季という名を使いませんというのもおかしいのではないか。

検索する予定がないカラムに複数の項目をカンマで区切って入れてもいいんでしょうか

ID 名前　 年齢　 好きな食べ物
001 山田太郎 13 いちご,みかん,りんご

ここでテーブルは関係ないな。
それはそれとして、つまり四季のフィールドも二十四節気のフィールドも
「季節」という同一概念だから同じ名前にすべきだってことだろ？

>>796
その項目でなにか処理しないんならいいんじゃね。

>>796
カラムは最小単位で作るのが基本

>>798
なにも処理しないならそもそも保存する必要すらないっていう

「最小単位」の捉え方しだいだな。
単にカンマが含まれたテキストとして扱うならば>>796のままでもかまわんし。

>>799,800
DBの処理はなにもしないんですが、そのテキストの言葉を利用して
phpで処理する場合カンマ区切りだと都合がいいのでそうしてるんですが、
使い方まちがってませんか?

別に間違ってないよ。

>>799
>なにも処理しないならそもそも保存する必要すらないっていう

単に表示するだけのフィールドとかあるでしょ。

このスレだから、わざさわざ「(SQL で) 処理しない」って書かなくても
理解できると思ったが...。

>>800
>>796はきっぱり「複数の項目をカンマで区切って」って書いてあるから
最小単位でカンマ区切りテキストが入ってるとは考えにくいと思うが

>>801,803
それは本来DB(SQL)でやるべき作業をアプリにやらせてる可能性が高いぞ

まあどこまでがDBでどこまでがアプリでやるべき作業かってのも
考え方によって変わるだろうし、やってみて不都合なければいいとも言えるが

>>804
カンマ区切りのほうが配列に一発で入るので便利かなと・・・。
それか普通に別のテーブルを用意するほうがいいのか迷っていたのです。

CSVならタブ区切りを使うな

カンマだと色々弊害が起きる

>>806
お前他スレでもTSV言ってたろｗ
CSVに親でも殺されたのか？

>>805
つまり

ＤＢに格納する前に、配列の各要素を結合する
ＤＢから取り出した後に、分解して配列の各要素に格納する
という処理を毎回行う

各要素に対する処理はアプリケーションで行う

これに疑問を感じない、そのほうが便利だって思うならそうすれば良いと思うよ

>>808
CSVならタブが良いと書き込んだだけで
人違いされたあげく親まで殺されるのか
キチガイにも程がある

>>809
疑問を感じたから質問したんじゃないの?
そのまわりくどい言い回しは何
ベストな方法を書いてやれよｗ

>>809
splitとかjoinとかで一撃な言語の方が多くね？
DBでもっと楽な解決できるのかいな

カンマ(タブ)エスケープはどうすんだとか、要素を検索しろとか要素でJOINしろとか
ちゃんと検討しての発言とは思えないな。

>>812
よく使うけどDB使う時にわざわざやらないなあ。
ちょっとしたバッチやアプリでは便利。

>>796

ID 名前　 年齢　 好きな食べ物
001 山田太郎 13 いちご,みかん,りんご

この例で、
「いちご、みかん、りんご」は表示するだけの情報であるならば、
カンマ区切りのテキストのままDBに格納しておくことで事足りるかもしれませんが、
この手法に違和感を感じるのも事実です。

加えて、表示するのみの情報であっても、
並び順を変えたいとか、言葉を変えたいとか、
好きな食べ物に関するデータの統計を取りたいとか、
いろいろな要望が今後出てくる可能性もあります。

ですので、保守性を考えて、やっぱり情報は分割すべきかと思います。

以下は例ですが、

食べ物をマスタ化しないなら、
-------------------------------------------
社員（*社員ID、名前、年齢）
好きな食べ物（*社員ID、*連番、食べ物名）
-------------------------------------------

食べ物をマスタ化するなら、
-------------------------------------------
社員（*社員ID、名前、年齢）
好きな食べ物（*社員ID、*食べ物コード）
食べ物（*食べ物コード、食べ物名）
-------------------------------------------

食べ物をマスタ化し、食べ物コードに変更を加えることなく、食べ物の並び順の変更に耐えうる形なら、
-------------------------------------------
社員（*社員ID、名前、年齢）
好きな食べ物（*社員ID、*食べ物コード）
食べ物（*食べ物コード、食べ物名、並び順）
-------------------------------------------

･･･などなど、いろいろ思いつきますが。

余談ですが・・・
「社員」に「年齢」という項目は、違和感がありますね。
毎年1回の基準日に全社員を対象に（？）
あるいは毎日その日が誕生日である社員を対象に（？）
インクリメントする必要がでてきてしまいます。
「年齢」ではなく「生年月日」がいいですね。本当に余談ですが・・・。

使われてない・使うかどうか分からないテーブルがあるほうが保守性が悪いよ。
今回のケースならテーブルを分けるのは、それが必要になることが分かった時点で充分だろう。

あいかわらず、予断で語る奴が多いなぁｗ

素人の素朴な疑問でここで聞いていいのかもよくわからないのですが、お願いします

サイトAで使われてるデータベースとその情報があり、
それとは別にサイトBで使われているデータベースとその情報があるとします。
で、新規にサイトCを作って、そこでAとB両方のデータベースの情報を取り扱うとき、
A,B,Cのデータベースはどういうふうに作ったら効率的なんでしょうか？

AもBもそれぞれ、webサーバ+DBサーバを一つのハードの中で動かしてる場合、
Cから同じ検索クエリをA,Bに送って帰って来た結果を表示することになると思うんですが
もっと賢いやり方はないのかなと。

たとえばヤフーで賃貸物件検索するのに、atHomeとかCHINTAIとか複数の
物件紹介サービスの情報を一括で抽出できると思うんですが、ああいうのはどうやってるんでしょうか？
両サービスのDBから定期的にヤフーのDBにバックアップを落として来てソコで検索してるとしたら
古い情報を検索することになりかねないし、リアルタイムで各サービスに問い合わせるとしたら
自前のDBに問い合わせるよりも遅くなったり「東京」を示すパラメータを各サービスのそれに
整形する手間などがかかりそうだし、一つのサービスが落ちてたときの処理が面倒そうだし…

ヤフーからの検索対象DBを専用に作って、各サービスはそこで（リアルタイムに？）
レプリケーションという奴をやっていて、ヤフーはそこを検索してるんでしょうか？
また、こういう複数のサービスでデータの乗り入れ？をする場合、DBサーバは
専用／共通のハードの中で動かした方が速いものなんでしょうか？
Mysql5を想定しています

リモートのデータベースに直接つなげるならそれでなにか問題が？と思うが。
ネットワーク的に遠いなら検索用DBを作るのはやってるだろう。

賃貸物件は例えが悪いな。
こんなもん1日何十回も更新するもんでもないだろうから定期的に情報を取得する仕掛けを作ればいいだけ。

あーゆーのは、Webサービス公開してて、Yahooはそれ呼んでるだけじゃないの？

>>805
各項目を固定長で入れておいて、viewで処理する手はある。
固定長に整形するアプリケーション側にコストがかかるが。

>>815
詳しい説明ありがとうございます。
年齢は生年月日にしてあとから計算するほうがよさそうです。

食べ物名の形式はとくにないので
例えば、いちごの場合はカタカナのイチゴかもしれないし半角のｲﾁｺﾞかもしれないし漢字の苺かもしれないし
イチゴ味のアイスかもしれないんので、
とんでもないことになりそうなんです。

>>822
であれば、>>815で提案した案のうち、
マスタ化する方法を取ればよいのではないでしょうか。

テーブル設計的には>>815のような感じで分けた方が良いけど、
プログラミング的には>>796の方が圧倒的に楽だよ（年齢は駄目だが）
SQLは簡単だし、抽出も早いし。

堅く作る必要が無いなら>>796の方で十分でしょ。
マスタ化した方が綺麗だけど、面倒この上ない。

ただ、自分ならセパレータはカンマじゃなく、コロンとかセミコロンとか"|"とかにするけどね。
カンマだとcsv化したくなった時に厄介。