10/11/24 23:43:33
こういう仕様は日本のSヨの飯のタネだからな。
218:NAME IS NULL
10/11/25 00:59:50
いやだから8/13～15に立った売上は8月第一週換算とかそんな感じ。
8月12日はお盆期間じゃないから第二週換算だけど、とか。
219:NAME IS NULL
10/11/25 02:30:12
あ。
お盆期間を8月1週とする、かと勘違いしてたorz
スマンカッター。
>>217
サマータイムとか旧正月とかあるし日本に限らないような気も。
220:NAME IS NULL
10/11/29 17:50:54
得意先マスタに訪問履歴1、訪問履歴2、訪問履歴3というカラムが。
何がしたいのか聞いてみたら、1回目の訪問時の内容を～、とのこと。
俺「3回以上訪問したら。。。？」
相手「その辺は運用で何とかします。大抵は3回分保持できれば十分ですので。」
だとさ。
221:NAME IS NULL
10/11/29 19:39:04
>>220
なんとでもなるのに何を難しく考えているんだろうな？ｗ
素直に訪問履歴ｘＮ回になっても大丈夫なように作ってくれって言えばいいのにｗ
222:NAME IS NULL
10/11/29 20:59:11
履歴とかいうから全部残さなくていいのおおおお？と思っちまうけど、要は「初回3回までの訪問日時」だろそれ。
最初の数回の挨拶とか紹介だかの日時のメモ書きであって、4回以上は捨てて問題ないってこと。
RDBとしてはうんこだけど実運用考えればそれはそれでありだろう。
223:NAME IS NULL
10/11/29 23:16:49
ほんとにメモ的な情報で良ければそれでもいいのだけど、
あとからとんでもなく重要な情報であることが発覚して、
大改修を迫られることになる。
さらに下請けの悲しさか費用は込みこみで；；
224:NAME IS NULL
10/11/29 23:29:58
大改修よりも運用で何とかしていたものを移行するのが死にそう。
過去データ登録機能を作って客に入れてもらうかｗ
225:NAME IS NULL
10/12/02 01:57:55
SQL質疑応答スレから誘導されてきました。
ｽﾚﾘﾝｸ(db板)
PHP＋MySQLなんですが、できるだけDBで処理しようと思っています。
お買い上げに応じて、ｎ％分を顧客にポイントを付与します。
これにはキャンペーンが存在して、水曜と日曜はポイント５倍、
７の付く日(7日、17日、27日)もポイント５倍、１日はポイント１０倍などあります。
１日が水曜日の場合は、倍率の大きい、ポイント１０倍が適用されます。
また、たとえば、クリスマス期間12月01日から12月26日まではポイント「さらに」１．５倍、三が日は一律１０倍などもあります。
こんな感じで、キャンペーンの曜日や期間、パーセンテージを自由に設定できるようにしたいです。
来月からは、水曜はポイント１０倍にしよう！なんてのもありえます。
よろしくお願いします。
226:NAME IS NULL
10/12/02 02:14:52
追加です。あんまり関係ないかもしれませんが。
先月の購入金額に応じて顧客にグレードがあり、
１万円以上の購入者は基本ポイントがｎ＋１％、
５万円以上の購入者は基本ポイントがｎ＋２％などとなります。
これもDBに格納させたいです。
227:NAME IS NULL
10/12/02 02:40:04
いや
肝心のなにが聞きたいのかがわからんし
228:NAME IS NULL
10/12/02 03:51:09
どういったテーブルの設計をすれば最適か伺いたかったのですが。。。
229:NAME IS NULL
10/12/02 04:02:27
「倍率が高いほうを優先」と「さらに」の2パターンしかないのかな。
230:NAME IS NULL
10/12/02 04:08:27 QCxu6itD
>>225
せめて誘導元の議論ぐらい貼れよ
656 655 [] 2010/12/01(水) 19:43:16 ID:0WLtPE6T Be:
現状、
・日別キャンペーンテーブル
・曜日別キャンペーンテーブル
・期間キャンペーンテーブル
とバラバラに作って、PHPで処理しています。
１か月分のパーセンテージ一覧を作るのに、１日ごとにSQLを複数実行して
かなり重いので、その辺も簡略化できる設計だと助かります。
657 655 [] 2010/12/01(水) 20:21:55 ID:0WLtPE6T Be:
自己レスだけど、こうゆう場合は
カレンダーテーブル(日付、計算済み％をカラムに持つ)を作ってあげて、
各種キャンペーンテーブルを更新するたびに１か月分とかカレンダーテーブルを更新する設計がいいんだろうか？
それだと、売り上げの度に％を取得するのが１回のSQLで済む。
ただし、時間帯別のキャンペーンが作れない(作りにくい)のと、設定忘れなどで、昔の期間にキャンペーンを設定するのが面倒な点が変わらない。。。
658 NAME IS NULL [sage] 2010/12/01(水) 20:43:49 ID:??? Be:
ビュー作れ
660 NAME IS NULL [sage] 2010/12/01(水) 21:01:28 ID:??? Be:
曜日があるからビューはかなりムリゲーだったわ・・。
1,2,3-31の日付だけ持つダミーテーブルを作って指定月の一ヶ月の一覧を取得するSQLをまず作る。
(SQLは多少メンドクサイが)単純な計算なのでこのまま使っても重いとは思えないが、
もし重ければ>>657の通り、月初なりキャンペーンテーブル更新時なりに別テーブルにinsert ～ select すりゃおｋ
661 NAME IS NULL [sage] 2010/12/01(水) 22:05:00 ID:??? Be:
キャンペーンごとのテーブルが必要な理由が分からない
カレンダーだけ作ってバッチ更新でいいだろ
663 NAME IS NULL [sage] 2010/12/01(水) 22:10:19 ID:??? Be:
>>661
そのバッチは何テーブルを見て更新するつもりだ？
665 NAME IS NULL [sage] 2010/12/01(水) 22:28:26 ID:??? Be:
>>663
そんな変なキャンペーンルールなんかバッチ側にもてばいい
666 NAME IS NULL [sage] 2010/12/01(水) 22:48:24 ID:??? Be:
>>665
例えばドトールのような不定期なキャンペーンを展開してるシステムとかどうするんだよ間抜け
毎月バッチリリースすんのかよｗ
667 NAME IS NULL [sage] 2010/12/01(水) 22:55:45 ID:??? Be:
水曜日のパーセンテージ変えようぜってやったら指定日以降の水曜日だけ変わってほしいよねきっと。
今曜日キャンペーンテーブルに期間もたせてるの？ないなら持たせないといけないんだよねぇ。
カレンダー的なメンテナンス画面作るのが楽だと思うなぁ。
668 655 [] 2010/12/02(木) 00:26:41 ID:u5kOJKQ0 Be:
曜日キャンペーンに期間は必要ですねぇ。
いまはまだ付けてないです。
参考にさせていただきます。
それでは、スレ違いだったようなので、別スレにて再度、投稿してきます。
231:NAME IS NULL
10/12/02 04:43:33
それぞれのキャンペーンで、パーセンテージを「５％に置き換え」「３％加算」「ｎ倍にする」といった種類をつけたいです。
キャンペーンで、決算キャンペーン12月は＋５％、クリスマス期間は「さらに＋５％（計１０％）」「１０％に置き換え」といったような、
期間が重複する場合も、期間の範囲が広いほうから狭いほうに順に計算したいです。
232:NAME IS NULL
10/12/02 07:16:56
キャンペーンテーブル作って
買い物ごとに適用されたキャンペーンＩＤ入れておけばいいだろ
±Ｘが％なのか○円以上で～なのかは多分ルールが変わるだろうからその辺は
その都度でいいんじゃね？（f(x)の形）
233:NAME IS NULL
10/12/02 16:41:21
複数のキャンペーンが適用される場合は？
234:NAME IS NULL
10/12/02 17:43:45
>>233
>>232に対してのレスだろうか。別途テーブル起こせってことじゃないかと思うんだけど、
そもそもの主眼は適用されるキャンペーンを楽に取得することだからなぁ。
235:NAME IS NULL
10/12/02 18:33:50
別テーブルかぁ。
１２月３日になって、「そういえば今月は決算キャンペーンだと発表してたのに、システムの設定忘れてた」
って場合はどうする？
236:NAME IS NULL
10/12/02 18:50:16
いまキャンペーンテーブルは日別、曜日別、期間別の３つに分かれているわけだけど、
これを１つにまとめちゃうスマートなアイディアは無いの？
237:NAME IS NULL
10/12/02 18:53:48
まとめればいいじゃん
開始日付,終了日付,キャンペーンID
そういう～別とかいうのは月次処理でやりゃいい
238:NAME IS NULL
10/12/02 18:55:13
発表した時点でキャンペーン情報を登録しておくべきだよねぇ。
忘れてた時どうするといわれても、どちらかというと別テーブルで保持したほうがバッチつくりやすそうには思うぐらいで、
めんどくさい作業が待ってることには違いないかな。
239:NAME IS NULL
10/12/02 18:56:21
このスレ質問者はIDを出す文化がないのか、とおもったけど質問スレじゃなかったな
240:NAME IS NULL
10/12/02 19:01:35
そもそもDB設計なんざ枯れてるんだから迷う要素なんてないだろ
設計というのも恥ずかしいぐらい簡単
241:NAME IS NULL
10/12/02 19:22:27
簡単すぎて書く気にもならないってレスはまだか？
242:NAME IS NULL
10/12/02 19:23:31
>>233
複数登録できるようにしたらいいんじゃない？っていうしなきゃダメだな
なんのキャンペーンが適用されてこの値段になったのかわからないとか最悪の結果だ
計算によって％だけ出して会計すませりゃいいって問題じゃないだろ
下手したら脱税で訴えられそう
243:NAME IS NULL
10/12/03 00:26:26
売り上げテーブル
+ID
+売り上げ金額
+ポイント額
キャンペーン適用テーブル
+売り上げID
+キャンペーンID
みたいな感じ？
244:NAME IS NULL
10/12/03 01:11:56
しらね
どういうＤＢ作りたいのか詳しく知りたくないからよく読んでない
キャンペーンは確実にその日すべての買い物に適用されるとかなるのか仕様がよくわかってない
タイムサービスとかないんだろか？とか結局なんの統計とりたいの？とかよくわかんねーし
やっぱ、この辺は担当者とお話してちゃんと仕様決めないとね
一般的な～ってないと思うよ
245:NAME IS NULL
10/12/03 02:02:02
え、今日ポイントどれくらいつくの？ってのを取得しやすい設計を知りたいんじゃないの？
俺はそれに応じたレスをいくつかしてはいるんだけれど。
統計とか何の話だろうって思うわ。
246:NAME IS NULL
10/12/03 07:27:23
>>245
追記で購入金額に応じたポイントまであるんだから全売上の詳細まで管理したいような感じもするけどね
247:NAME IS NULL
10/12/03 07:31:51
買い物客ごとにデータを保持しておいたほうがいいね
実運用では商品によってキャンペーン対象外商品がきっとある（でないと転売屋天国になるからな）
まあ、教科書的な答えだけほしいってんならテキトーでいいと思うけどねｗ
248:NAME IS NULL
10/12/03 09:57:47
キャンペーン複数適用するのに
たとえばAキャンペーンが1000円引き、
Bキャンペーンが1割引だったとしたら
正価から1000円引いてから1割引するのか、
1割引してから1000円引きなのか、とかも考慮する必要あるし
もっと仕様を詰めないといけないんじゃない？
逆に言えば仕様が固まればおのずとDBは決まると思うけど
249:NAME IS NULL
10/12/03 09:59:50
ああ、値引じゃなくてポイントか
まぁ話としては変わらんけど
250:225
10/12/04 02:47:21
>>248
それもPHPコードで決めうちじゃなくて、
計算順をDBに入れて、利用者が設定できるようにしたいですね。
251:225
10/12/04 03:04:53
例えば、キャンペーンにプライオリティカラムをつけて、
その順番に適用していくとか。
252:NAME IS NULL
10/12/04 07:05:44
結局どこで詰まってるんだか。
> １か月分のパーセンテージ一覧を作るのに、１日ごとにSQLを複数実行して
> かなり重いので、その辺も簡略化できる設計だと助かります。
3テーブルあって、月次バッチ処理をしているとして、1日ごとに実行したとしても、90回の抽出と30回の挿入だよね。
なんでそんなのが重くなるんだ？
DB今のままでちょっとチューニングしたら終わるんでないの。
253:NAME IS NULL
10/12/04 07:58:31
IPアドレスの管理表をおこしたいのですが、IPアドレス毎に、使用者情報、inbound接続ができる
(=開いてる)ポート番号のリストを持たせようと思っています。
使用者情報まではいいのですが、開いてるポート番号の情報はどのように持てばいいでしょうか？
この開いてるポート番号情報は例えば 22,80,443,3024-3054 といった情報になります。
そして、このポート番号情報にからめて「xx番が開いている未使用のアドレス」という検索がで
きるようにしたいと考えています。
扱うIPアドレス数はたかだか1000件も扱えれば充分なのですが、「0-65535(ポート全開)」とい
うアドレスも扱わなければならないので、悩んでいます。
テーブル1(ip_table)
|ID|IPアドレス|使用者情報など|
テーブル2(opned_tcp_port_table)
|ID|ip_table.ID|ポート番号|
と割っておいて、select 時には join してから select する手もありますが、(ポート全開)な
アドレスの扱いがえらいこと(65536行に膨らむ＆opned_tcp_port_tableに65536行分入れておか
ないといけない)になりそうで、ここが悩みのポイントです。
254:NAME IS NULL
10/12/04 08:18:26
テーブル2
ID ip_table.ID ポート番号下 ポート番号上
1 1 0 65535
2 2 22 22
3 2 80 80
4 2 3024 3054
select ip_table.ID from テーブル2 where xx between ポート番号下 and ポート番号上
255:NAME IS NULL
10/12/04 09:30:17
>>254
between何てのがあったと！
それをip_tableにjoinすれば使いたいポートが開いてるアドレス一覧が取れると。
ありがとうございました。
256:NAME IS NULL
10/12/04 12:08:16
>>255
開いてる)ポート番号が飛び飛びだったらどうすんの？
257:NAME IS NULL
10/12/04 12:18:45
16ビットで表現できるな。
258:NAME IS NULL
10/12/04 15:10:22
IPアドレスマスタ
IPAddress(PK) , ValidFlag
IPアドレス使用者テーブル
IPAddress(PK),SeqNum(PK),UserAccount,ValidDate,InvalidDate
こんな感じじゃダメなんか
259:NAME IS NULL
10/12/04 19:14:51
給与の締め日と支払い日を管理するDB設計は、どういった形がよいでしょうか？
月ごとに25日締め翌月5日払いとか、
週ごとに締めて、翌水曜日払いとか、
２週ごとに締めて、翌水曜日払いとか。
こういった要件を自由にカスタマイズできるようにしたいです。
260:NAME IS NULL
10/12/04 19:23:23
タイプ：月、週、日
締日
支払日
こんだけ
261:NAME IS NULL
10/12/04 19:25:38
二週ごと、とか無理だろ。
DBでやるのは無理だから、ビジネスロジックでやるもんじゃね？
262:NAME IS NULL
10/12/04 20:02:41
給与の締め日ってどんな感じで色々かわんのかね？
パッケージ向けってつーことかい
263:NAME IS NULL
10/12/04 20:31:05
>>256
偶数番号のみ全開とかは泣ける…
>>258
IPアドレスマスタの ValidFlag はもしかして、65536bitのポート開いてる閉じてるフラグ？
264:NAME IS NULL
10/12/04 20:43:27
>>253
悩むのは6500万件のテーブルが「えらいこと」かどうか確認してからでいいだろ。
265:NAME IS NULL
10/12/04 20:46:42
65536bit・・・ だめだこりゃ。
266:NAME IS NULL
10/12/04 22:41:40
>>255
betweenじゃなくても、
ポート番号下 <= xx and xx <= ポート番号上
で同じことになるよ。
267:NAME IS NULL
10/12/05 08:23:47
>>259
DBに計算式のスクリプトを直接突っ込んでる
268:NAME IS NULL
10/12/06 01:27:26
>>263
ああ、外部公開用WANじゃなくて、クライアントのIPアドレスの話か
ならLANが前提だろからIPアドレスは主キーには出来ないのでFQDN見るしかない
NICの複数差しも考慮しなくちゃいけない
クライアントマシン公開ポートテーブル
FQDN(PK),NicNum(PK),SeqNum(PK),IPAddress,Protocol,StartPortNum,EndPortNum
ユーザーは別テーブルでFQDNと紐付けて、ポートの重複とか論理整合はストアドで取ればいいんじゃね？
269:NAME IS NULL
10/12/06 02:57:25
なんだこの展開
270:NAME IS NULL
10/12/06 10:05:28
しばらく見てなかったらえらい複雑な展開になっているみたいで申し訳ない。
後出しで申し訳ないんだけど、やりたいアプリは/24程度のFWの裏にいるグロー
バルアドレス持ちなネットワークのアドレス管理なのですよ。
FWでアドレス毎にinboundの接続設定が異なっているので、それの管理用アプ
リに、と思った次第。
基本 アドレス、利用者、開いてるポート番号 の要素を管理しておきたくて、
このネットワークの利用者からは「××番が開いてるアドレスなーい？」とか
「全開のアドレス空いてない？」いう問い合わせが多いので、ポートの状況で
検索というのが要件に挙がったと。
ここまででいくつかアイデア頂いてるので、それぞれ試作して検討してみます。
なので一旦closeということで。
271:NAME IS NULL
10/12/24 18:04:55 CmCii1Ay
誘導されました
記事が著者、カテゴリ、タグとそれぞれ多対多の関係になる場合次のどっちが使いやすい、パフォーマンスがいい、ですか（検索など）？
記事の分類が増えることはなく、著者はただの分類でログイン等は持ちません。
記事: id, body
著者: id, name
カテゴリ: id, name
タグ:id, name
著者関係: 著者id, 記事id
カテゴリ関係: カテゴリid, 記事id
タグ関係: タグid, 記事id
記事: id, body
taxo: id, name, type
taxo関係: taxoid, 記事id
※taxo.typeは著者、カテゴリ、タグのいずれか
ｽﾚﾘﾝｸ(db板:888-889番)
272:NAME IS NULL
10/12/24 23:16:31
>>271
前者じゃないかな。あと、気持ちの問題だけど、記事idを先頭に持って行きたい
273:NAME IS NULL
10/12/26 07:58:53
個人的にば、一つの事象を一つのエンティティとして切り出すほうが好きなので、前者で作って、
著者名、カテゴリ名、タグ名から透過的に検索するために、taxo関係をビューにするかな。
274:271
10/12/26 15:36:39 xB/ukp6t
>>272-273
ありがとうございます。
> taxo関係をビューにするかな。
これのやり方がわからないんで教えてもらっていいですか？
275:NAME IS NULL
10/12/26 15:56:32
>>274
単にJOINしたSQLをビューにしておくっていう意味以上のものはないと思うぞ
276:NAME IS NULL
10/12/26 15:58:15
あ、つまり↑の作りの場合のデメリットはテーブルが増えすぎてわけわかんなくなるかも、ってことだから
ビューをあらかじめ作っておこうという嗅覚が働いたという話かと。
277:271
10/12/26 16:11:28
テーブル数は気にならないのでとりあえず上で行って見ます。
ありがとうございました。
278:NAME IS NULL
10/12/29 19:53:07 7r5KYmdf
テーブルAのある列の値がXのときだけ、テーブルBに対応するレコードが存在する。X以外では存在しない、
っていう制約がある場合、アプリ側だけで制御してる？トリガーとかでDB側でも制御してる？
279:NAME IS NULL
10/12/29 21:56:30
>>278
その制約が破られたときの金銭的損失、瑕疵として損害賠償請求されたときの想定金額次第
280:NAME IS NULL
10/12/30 04:15:29
>>278
俺的にはDB側にあんまり制約つけるの好きじゃないんだが
そのDBが一つのアプリ（システム）からしか利用されないならそのアプリで制御する
複数のシステムで共有されるようなDBなら、DB側になんらかの制御を入れる
ぐらいの基準かな
281:NAME IS NULL
10/12/30 09:39:51
あるDBが複数のアプリから利用された場合を想定して、DB側でも制御、だなぁ。
とあるシステムで、顧客情報をWebアプリからも登録されるし、
オフラインのFaxやハガキからも登録される、っていうシステム見たんだけど、
オンラインからはメールアドレス必須なのに、Faxなんかには入ってなくって、
オンライン側でバグる、みたいなことが立て続けに発生してた。
282:NAME IS NULL
10/12/30 11:07:18
個人的には仕様書がないときにバイナリしか残ってないアプリからじゃなにも分からないけど、
DB側に実装しておいてもらえれば、最悪でも仕様だけは知ることが出来るからDB側で実装してほしい。
283:NAME IS NULL
10/12/30 13:24:19
新任の後任者が仕様変更で一方のロジックしか直さず
顧客をブチ切れさせるのが通過儀礼となる図
284:NAME IS NULL
10/12/30 13:27:35
そもそもそんな設計が悪い、とか言い出す奴がそろそろ登場する悪寒。
285:NAME IS NULL
11/01/01 06:48:29 ZTfqWojz
・ユーザ情報テーブル（画像1枚）
・店舗情報テーブル（画像複数）
上のような複数のテーブルに、
それぞれアップロードされた画像の情報を持ちたいんですが、どうするのが一般的/スマートでしょうか。
それぞれ画像が1枚だけなら、そのテーブル自体に画像情報フィールドでもつくればいいのですが、
複数の場合があるので悩んでいます。
自分で思いついたのは、
・画像情報テーブル
を作って
そのテーブルに
foreign_id INT UNSIGNED /* 外部キー */
forein_type enum('user', 'shop') /* どのテーブルの外部キーかの値 */
てな感じで、外部キーをもたせつつ、その外部キーがどのテーブルのものかを判断する値も持たせれば
良いかなと思ったのですが、
もっと良い方法ありますか？
286:NAME IS NULL
11/01/01 10:29:45
>>285
・ユーザ画像テーブル
・店舗画像テーブル
をもっちゃいけないの？
画像テーブル一つにまとめて画像データすべてに対してなんらかの処理をしたいなら
一つにまとめるのもアリだと思うけど・・・
普通はint情報テーブルとかもたないよねｗ・・・
287:NAME IS NULL
11/01/01 11:30:36 ZTfqWojz
>>286
それだと、今後別のテーブルにまた画像が必要なときにまた画像テーブルをつくるはめになるので、、、
１つのテーブルに画像情報がまとまっていれば、
そのテーブルに対するモデルさえあれば、
今後どんなテーブルに画像が必要になっても対応できるので、
なるべく１つのテーブルで管理したいんですよね
288:NAME IS NULL
11/01/01 11:48:57
画像情報テーブルにユニークなキーがあれば、
それがユーザーのものか店舗のものかは気にしなくていいんじゃない？
何のために、どのテーブルのものかを判断するの？
289:NAME IS NULL
11/01/01 12:05:43 ZTfqWojz
>>288
例えば店舗情報を表示するページで店舗画像を取ってくるわけですが、
画像テーブルの外部キーが店舗のIDなのか、ユーザのIDなのかがわからないためです
290:NAME IS NULL
11/01/01 12:21:08
ダメだこりゃ。
291:NAME IS NULL
11/01/01 15:40:51
その「画像データ本人」が自分が店舗画像下ユーザ画像なのかを知ってる必要はないよね。
292:NAME IS NULL
11/01/01 18:42:11 ZTfqWojz
>>291
すいません、完全に理解できないです・・・。申し訳ない。
画像データが店舗のものかユーザのものか判断するのは
どのテーブルのフィールドが担うんでしょうか？
画像が必要なテーブルに、
画像IDを外部キーとして保持するとしても、
複数画像に対応できない気がしますが、認識が間違ってますか？？
293:NAME IS NULL
11/01/01 19:00:55
・画像情報関連テーブル
ユーザか店舗のキー 画像のキー
これでなんか問題あるの？
294:NAME IS NULL
11/01/01 19:04:06
>>292
画像がユーザーあるいは店舗に従属するのであれば、ユーザーと店舗の
テーブルを分けた時点で画像の方も分けなければならない。
どうしても画像テーブルを一つにしたいのであれば、手としては2つある。
・ユーザー・店舗の共通エンティティを用意する
→ただし、ユーザー画像は常に1つ、店舗画像は複数可、などは表現できない
・ユーザー―画像、店舗―画像という連関エンティティを別に用意する。
→場合によっては素直にユーザー画像テーブル、店舗画像テーブルの方が簡単
295:NAME IS NULL
11/01/01 21:28:19 ZTfqWojz
>>293
店舗とユーザのIDは別テーブルなので重複する可能性がありますね。わかりづらくてすいません
>>294
> 画像がユーザーあるいは店舗に従属するのであれば、ユーザーと店舗の
> テーブルを分けた時点で画像の方も分けなければならない。
うーんやはりそうかぁ。
素直に
・ユーザ画像テーブル
・店舗画像テーブル
を作ろうかな。
ありがとうございました。
296:NAME IS NULL
11/01/01 21:36:49
店舗とユーザのどっちかを判別できるキーにすりゃいいだけだろ
アプリ側からしたらユーザか店舗かはJOIN時に分かりきってるんだから
解決したならもういいけどさ
297:NAME IS NULL
11/01/02 13:20:56
>>295
教科書的な作り方なら
・ユーザ＆画像関連テーブル（ユーザ識別＋画像ＩＤ）
・店舗＆画像関連テーブル（店舗識別＋画像ＩＤ）
・画像テーブル
の３つが必要
298:NAME IS NULL
11/01/03 04:07:50 5FnD8U9u
>>297
あ～こっちのほうがいいですね。
これでいきます！
どうもです
299:NAME IS NULL
11/01/08 17:11:01
今Excelに以下のような形でデータを保存しています
A列 保存場所 e.g F:\data\～\～
B列 ファイル名 e.g [xxxx] dddddd.doc
C列 作者名 B列ファイル名のxxxxの部分
D列 タイトル名 B列ファイル名のdddddd.docの部分
E列～G列 ジャンル D列の作品がどういうジャンルに属しているか
H列 コメント
E列～G列のジャンルについては現在最大3つ（別にそれに縛られる必要はないのですが）で、最低限1つは必ずあります。
H列についてはあれば記載
で、勉強も兼ねてテーブル化しようと思っているのですが。
作者テーブル
作者名
読み
ジャンルテーブル
ジャンル
は思いついたのですが、
メインのデータテーブルはどのように持てば？という事で
教えていただけたら m(_ _)m
※データテーブルにはファイルをバイナリで入れる事はせずA列の保存場所を
持っていれば良いと思っています
300:NAME IS NULL
11/01/08 17:17:20
メインは↓みたいな感じでいいんじゃね？
ID、タイトル名、保存場所、ファイル名、作者ID、ジャンルID、コメント
301:299
11/01/08 19:59:44
有難うございます
まぁそういう形になるのかなぁと。
それで試しに作ってみます。
302:NAME IS NULL
11/01/09 09:23:28
・ひとつの「タイトル」は、3つ(?)の「ジャンル」を持つ
・ひとつの「ファイル」に、「タイトル」はひとつ
・ひとつの「タイトル」で、複数の「ファイル」がある
・「タイトル」が同じでも、別のファイルなら、作者名、コメントは別？
タイトル { タイトルID, タイトル名 }
ファイル { ファイルID, タイトルID, 保存場所, ファイル名, 作者ID, コメント }
タイトルジャンル { タイトルID, ジャンルID }
303:299
11/01/09 10:28:16
・ひとつの「タイトル」は、3つ(?)の「ジャンル」を持つ
現在はジャンルを3つにしていますが、3つに限定しないといけない理由は
ないです。ただ最低限1つはかならず持つという事で
・ひとつの「ファイル」に、「タイトル」はひとつ
タイトルは1つです
・ひとつの「タイトル」で、複数の「ファイル」がある
・「タイトル」が同じでも、別のファイルなら、作者名、コメントは別？
複数の作者で同じタイトルという可能性はあります。ただしその場合
ファイルは別々ですが。
304:NAME IS NULL
11/01/11 17:00:09 3vuTbP2k
すんごい基本的な事なんだけど、毎回悩む。
たとえば、男、女 の様なマスターが欲しいとき、IDはふった方が良いんですかね？
男、女 をそのままデータテーブルで保存するようにしても欠点が分からない。
容量の削減にはなるとは思うが、クエリなどでわざわざマスターからリンクしなくてもよい
という利点もあるし。
ただ、マスターテーブルが不恰好な気がするが…。
うーん、、
305:NAME IS NULL
11/01/11 17:06:04
最近は性別も更新される可能性のある属性ですｗｗｗ
306:NAME IS NULL
11/01/11 18:10:31
マスターの方を変えたらジェンダーフリーすぎだろｗ
307:NAME IS NULL
11/01/11 18:16:12
性別欄が必須でないデータってのもよくある話で、
男性、女性、中性、（未選択）
くらいはあってもよい気がする。
308:NAME IS NULL
11/01/11 18:20:43
JISで性別のコードって規定されてなかったか
309:NAME IS NULL
11/01/11 19:23:54
男 男性 M Male のように表現がいろいろあるから残念な気持ちになりつつ、男と女の2レコードを作っておくといいんじゃないかな
310:NAME IS NULL
11/01/11 23:41:02
>>304
どっちでもいいんじゃない？
プログラム組んでてもそういう問題ってあるじゃない
311:NAME IS NULL
11/01/12 10:09:47
>>304
自分の個人的な判断基準は、その値が表示するだけ（帳票に出ればいいだけ）なのか、検索やグルーピングで使うかかな。
後者なら一応IDにしておく。
312:NAME IS NULL
11/01/12 23:24:06
二つだから気になるんだ
オカマとオナベもつけておけば気にならない
313:NAME IS NULL
11/01/12 23:55:36
>>308
JISは廃止された（はず）だけど、ISO/IEC 5218:2004 はまだ生きてるかな。
314:NAME IS NULL
11/01/13 15:55:10
外部テーブルにすれば外部キー制約が使えるが生データだと使えない
検索はインデックス張っておけばIDもvarcharも大差ない。
315:NAME IS NULL
11/01/13 17:26:19
キー＝データになるんだから外部キー制約は使えるんじゃないか？
316:NAME IS NULL
11/01/14 03:55:41
>>314
チェック制約じゃまずいの？
317:NAME IS NULL
11/01/14 08:43:52
MySQLはCHECKねえじゃん
318:NAME IS NULL
11/01/14 11:53:52
MySQL前提だったとは。
319:NAME IS NULL
11/01/15 12:11:14
標準はティムポウェアだよ
320:NAME IS NULL
11/02/09 06:46:45
目指してる 未来が違うｗｗｗｗｗｗ ｂｙシャープ
URLﾘﾝｸ(twitter.com)
321:NAME IS NULL
11/02/15 06:01:04
使用DBはOracleです。
■生徒テーブル
１．生徒NO→表の中で一意かつnullを許さない
２．クラスNO→nullを許さない
３．出席番号→クラス内で一意かつnullを許さない
４．生徒名→nullを許さない
1番にはPK、2,4番にはnot null制約をつければいいとして
3番はどうすれば良いのでしょうか？
322:321
11/02/15 06:08:14
解決策として、「クラスNO」と「出席番号」を結合した「クラス別出席番号」という列を作り
ユニーク制約を付けようと思ってます。
もう少しスマートな方法があれば教えてください。
323:NAME IS NULL
11/02/15 06:10:40
check制約でもいいと思うけどね
324:NAME IS NULL
11/02/15 06:42:00
>>323
チェック制約だと他の列を参照することはできても、他の行を参照することはできないので
要件を満たせないんじゃないですか？
325:NAME IS NULL
11/02/15 07:07:42
普通にout_of_line_constraintでunique制約つければいい
326:NAME IS NULL
11/02/15 08:35:30
>>325
ユニーク制約は複数列指定できたんですね。
1番スマートな方法ですね。
ありがとうございます。
327:デフォルトの名無しさん
11/02/19 16:24:44 rzbDbHjB
汎用マスタとか名称マスタとか呼ばれてるごった煮管理なOTLTなテーブルって
いまだに現役？
328:NAME IS NULL
11/02/19 16:45:15
現役のところ知っているけど
聞いてどうするの？
329:デフォルトの名無しさん
11/02/20 13:11:42.68
その手のマスタにもサロゲートキーをつけて、
ジャーナルデータにはサロゲートキーを埋める形にするべきなのか迷ったので。
あと、適用期間をもって世代管理をしているマスタで親子関係があった場合、
子側のマスタには親のコードを要素として持つべきか否かで迷ってる。
330:NAME IS NULL
11/02/20 14:15:42.10
サロゲートキーを使っている現場に出くわしたことない。
サロゲートキーを使おうとしていた現場はあったけど、
キーマンの一言「意味わからん」でお蔵になった。
331:NAME IS NULL
11/02/21 16:11:30.78
だいたいどのページ見ても、総合的に見てサロゲートキーは良いみたいに書いてあるけど
実際はそこまでサロゲートキーを使ってるところが多くないのはなんでだ？
332:NAME IS NULL
11/02/21 22:04:24.48
この間は複合キーの方が自然だからって押し切られたな。
変更に強い->そんな変更はあり得ない。あったらどうせ大改修だから意味がない。
ORMで楽->フレームワーク側の都合で設計するのは如何なものか。
333:NAME IS NULL
11/02/21 22:11:50.75
実際なくてもいい類のものだからな。冗長になることで面倒事も増えたりするし。
流行とか嗜好、メンバーのレベルで臨機応変に変えて問題ないものだから、
その押し切ったリーダーや「意味わからん」つったキーマンが無能というわけではない。
334:NAME IS NULL
11/02/21 22:55:57.34
>>331
設計上不自然な値がキーになってしまうから直感的に避けられてる
335:NAME IS NULL
11/02/21 23:43:07.58
>>332
そこは説明のしかた次第なんだろうけど、条件をつけずに「変更に強い」とか、
あたかも万能みたいに言ったらそりゃ眉唾で見られるだろうな。
336:NAME IS NULL
11/02/21 23:52:10.02
>>334
なんか気持ち悪い・・・ってやつか。
webや書籍で、サロゲートキーについて触れてるのないかな？
具体的にテーブルの定義情報がいくつかあって
どこがどうゆうふうに変更された場合、サロゲートキー使ってる場合は
こうゆう手順で改修ができる。
複合PKを使ってる場合は、こうゆう手順で改修を行う必要があるみたいな
具体的な作業内容が見たい。
できれば筆者の経験談を元に書いてるのがいいな。
337:NAME IS NULL
11/02/22 00:24:45.79
SQLアタマアカデミー：第3回 テーブル設計のグレーゾーン～毒と薬は紙一重 （4）サロゲートキーVSナチュラルキー｜gihyo.jp … 技術評論社
URLﾘﾝｸ(gihyo.jp)
338:NAME IS NULL
11/02/22 00:51:45.64
サロゲートキーと何でも一括りにするのって良くないと思うんだ。
人工キーを導入するにしても場面場面でその理由は異なるはずで、
そこを個別の事例ごとにきちんと区別して捉えないと、何でも
サロゲートキーマンセーとかいう困ったちゃんが出てくる。
改修に強くするためという理由でサロゲートキーを導入するのは
元々のデータモデルに時間不変な一意キーが無かったからだよね。
この場合サロゲートキーとはいっても元のデータモデルに修正を
入れているし、下手すりゃビジネスフローのところまで戻って
考え直した方が良いのかもしれない。
でも例えばパフォーマンス等の理由で複合キーを回避するために
使うという場合はサロゲートキーを導入するとはいえ、やりたい
こと自体は元のデータモデルと等価なことだよね。この場合既に
正規化されたスキーマに新たにキーを追加することで大抵は
第三正規形が崩れる。そこを意識して制約とかを加えないと後で
ハまる。
流行とかじゃなくて、ケースバイケースで丁寧に検討する必要が
あると思う。
339:NAME IS NULL
11/02/22 15:36:28.74
>>337
なぜか図11では開始時点と終了時点のカラムの値が編集されていないが
これだと商品ID001で検索すると2つhitして
一応代理キーの値が大きいほど新しいということである程度わかるが
いつからいつまで001がガムテープだったのかがわからんよね。
さらにこのサロゲートキーの使い方だと、商品IDにユニーク制約付けられないから
アプリでミスったらどうにもならなくなるな。
怖すぎるんだが。
おれんとこは、得意先の合併とかで、得意先マスタの得意先NOの使い回しが行われるような場合に備えて
トランザクションのデータを作った時の名称も同時にトランザクションのテーブルに埋め込んじゃうんだが。
サロゲートキーも使ってない。
■受注明細
商品NO
商品名称
得意先NO
得意先名称
日時
上記のようなテーブルにしといて、検収まで終わった「過去」の受注明細を「参照」するときは
テーブルを結合せずに得意先名称をひっぱってきたりする。
不細工な形だが、わかりやすいんだ・・・
340:NAME IS NULL
11/02/22 16:12:26.97
履歴的なテーブルならまぁそういうやり方のとこが多いんだろうね
過去に遡って洗い替えとかあると死ねるけど
341:NAME IS NULL
11/02/22 18:41:41.93
ちなみに商品IDの付け替えってありなの？
なにかと面倒だし、大した手間でもないから必ず新しいの作ってもらったほうがいいと思うんだが。
得意先は合併とかあるからお客さんの要望次第って感じだが。
342:NAME IS NULL
11/02/22 20:54:07.27
顧客要望によってはないこともない
正確には商品IDじゃなくて商品コードの付け替えだがな
343:NAME IS NULL
11/02/22 21:13:38.22
コードの桁数が３桁固定とか決まってる場合はどっかでリセットする仕様な場合はあるね。
ただ３桁のみがキーになることも滅多にないと思うが。
344:NAME IS NULL
11/02/23 04:06:56.64
DBは初心者です
テーブルA,Bの関連が1:1?または1:N*なテーブルは、相手が存在しない可能性もあるので
1．AとBに主キーを設定し、テーブルCにAとBの関連を入れる
2．Bの主キーをAの外部キーとして持たせ、Aの外部キーにnull値を許容する
のとどちらが良いと思いますか？
また、他のケースについて、今のところ
1:N*の場合は1を選択
1:1の場合と1:N+の場合は2.でnullを許容しない
N*:N*やN*:N+、N+:N+はA,Bどちら側からも検索する可能性があるなら1のみ(にこ動のタグとか)
そうでないなら検索する可能性がある項目を持つ側に外部キーを持たせる設計も検討する
という指針を考えてるのですが、大丈夫でしょうか
速度よりも修正容易性を重視したほうがよさそうな環境なので、基本サロゲートキーを付けてます
345:NAME IS NULL
11/02/23 05:47:09.64
どういうことだ？
346:NAME IS NULL
11/02/23 06:29:33.66
>>344
テーブルA,Bの関連が 1..N(Nは0以上) の基本を以下に書くよ。
o テーブルAに主キーを設定し、テーブルBには(テーブルAを参照する)外部キーを設定する。
o テーブルBに主キーが必要か否かは、エンティティA無しにエンティティBが存在しうるか否かで決める。
テーブルBの外部キーとしてNULL値を許容するとか、関連テーブルが必要かとかを検討する必要があるのは、
エンティティAも存在しないこともあるという関連 M:N(M,Nとも0以上) の場合だけだよん。
347:NAME IS NULL
11/02/23 14:48:31.30
テーブル名やカラム名にマルチバイトの文字って使う？
とんでもなく長いsqlとか書いてるとわけわかんなくなるから、マルチバイト使いたいような気もするし
もしかしたら今後のアップデートとかでマルチバイトが祟ってエラー吐くかもしれないから
あんまりマルチバイトを使いたくないって気持ちもある。
カラム名はシングルバイトでコメントの部分だけにマルチバイトってありかな？
これなら多少ましにはなると思うんだが、中途半端感が否めない。
348:NAME IS NULL
11/02/23 16:39:26.64
オラクルだと結構日本語テーブル日本語カラム見かける気がする
349:NAME IS NULL
11/02/23 19:20:11.70
客先でコンソールでデータとろうとしたときに詰むのが怖すぎる
350:NAME IS NULL
11/02/23 19:23:18.26
確かにリモートでつなげないような環境でデータを見る可能性があるならシングルバイトのほうが良さそうだね。
俺んとこはそうゆう事は一切ないから気づかなかった。
351:NAME IS NULL
11/02/23 19:37:11.95 iyykSQn2
以前働いていてたとこ、DB名、テーブル名からカラム名まで全て日本語 w
352:NAME IS NULL
11/02/23 19:50:08.25
>>351
それで具体的に何が困ったかｋｗｓｋ
353:NAME IS NULL
11/02/24 02:03:54.85
最近の自動生成系の機能がついたIDEなんかだと日本語変数名にもつながっていくので
規約で変数名にマルチバイト文字使っちゃダメとかやると面倒くさい。
逆に積極的にマルチバイトを使うように決めてしまえばあるいは。
354:NAME IS NULL
11/02/24 02:14:58.82
MySQLの公式ツールが落ちるからマルチバイトは使わないなぁ
コメントの日本語だけで詰むｗ
supplier.id ほげ.仕入れid hoge.siireid
こんなDB見た事がある
355:NAME IS NULL
11/02/24 03:46:34.08
>>354
MySQLってそんなにマルチバイトに弱いの？
一昔前までは、世界的なシェアで見ると、MySQL＞PostgreSQLだが
日本ではMySQL＜PostgreSQLだった。
PostgreSQLに比べてMySQLは、最初のころはマルチバイトに弱いとかで人気が出なかったが
だんだんそのへんが良くなって来てるから、PostgreSQLとトントンくらいのシェアになってるとか
どこかで読んだ気がするんだが。
公式ツールで扱えないんじゃMySQLではマルチバイトでカラム名を付けるなんてことは考えられないなｗ
356:NAME IS NULL
11/02/24 07:27:19.12
トントンくらいになったが、PostgreSQLの改善速度がかなり早く、MySQLはまた引き離されてしまった印象。
357:NAME IS NULL
11/02/24 12:17:16.70
>>354
公式っても、GUIツールだろ。
そりゃあしかたない。
他は全然安定してるから問題ない。
あんまり。
358:NAME IS NULL
11/02/24 12:43:23.84
サポートされてる機能を使っちゃいけないってのもおかしな話だしな
359:NAME IS NULL
11/02/24 16:58:43.49
>>357
仕方なくないだろ。
あきらかにマルチバイトは軽く扱われてるじゃん。
OracleやSQLServerですら稀に問題が起こるのに
MySQLで問題が起こらないとは到底思えないな。
360:NAME IS NULL
11/02/24 18:31:35.55
マルチバイトのテーブル名だの、項目名だの欲しがるのは、開発側じゃなくて大抵客。
だから、マルチバイトにしたビューを用意すればいいだけ
361:NAME IS NULL
11/02/24 22:29:28.02
Oracleだとマルチバイトのカラム名は""で括らないと動かん場合がある
362:NAME IS NULL
11/02/24 23:14:03.56
>>361
Oracleで""で括ってないって理由で動かないSQLを1度だけ見たことがある。
SQLServerは""で括らなくても問題ないの？
363:NAME IS NULL
11/02/25 23:38:18.25
>>346
ありがとうございます。
>o テーブルAに主キーを設定し、テーブルBには(テーブルAを参照する)外部キーを設定する。
なるほど、これが一番良さそうです
>o テーブルBに主キーが必要か否かは、エンティティA無しにエンティティBが存在しうるか否かで決める。
主キーについてまだ理解が足りてなかったみたいです
では、DB設計時は1:NやN:Nといった関連と、
単体で存在しうるか、という軸でも整理しておく必要があるってことですね
今作っているテーブルの該当部分は親子関係(子がない場合もあり、子単体は存在しない)なので
親への外部キーのみ設定して、子の主キーは設定しなくても良さそうです
364:NAME IS NULL
11/02/26 02:25:39.36
>>346, 363
訳が分からない。
> テーブルBに主キーが必要か否かは、エンティティA無しに
> エンティティBが存在しうるか否かで決める
なんでテーブルBに主キーが無くて良いことがあり得るの?
> 親への外部キーのみ設定して、子の主キーは設定しなくても
> 良さそうです
子の主キーも設定する。親への外部キーはNOT NULLで参照する。
そんだけ。あと初心者は気軽にNULL使わない。三値論理を理解して、
その面倒くささを理解してから使うこと。
365:NAME IS NULL
11/02/26 10:04:45.13
>>364
>なんでテーブルBに主キーが無くて良いことがあり得るの?
>>346で書いたように「A無しにBが(単体で)存在しえない」場合があるから。
具体的には、エンティティAの属性(attribute)としてテーブルBを表現するケース。
より抽象的に(モデル分析的視点で)、トップダウンな考え方を以下に説明する。
あるエンティティAが存在し、そのエンティティAは複数の属性を持つ。ここで各属性について、
(1) エンティティAがその属性を「ただ一つだけ(only one)」持つのなら、
その属性をテーブルAのカラム(フィールド)として表現する。
(2) エンティティAがその属性を「いくつか(zero or more)」持つのなら、
その属性をテーブルBとして表現し、テーブルBには(テーブルAを参照する)外部キーを設定する。
(3) エンティティAがその属性を「たかだか一つ(zero or one)」持つのなら、
その属性をテーブルBとして表現し、テーブルBには(テーブルAを参照する)外部キーを設定し、
更にその外部キーにはUNIQUE制約を設定する。
いずれの場合でも、テーブルBは「(単体で存在しうる)エンティティを表現」しているのではなく、
エンティティAが持つ「属性を表現」しているのだから、テーブルBに主キーは必要無い。
366:NAME IS NULL
11/02/26 10:16:03.18
>>365
BがAに依存する属性だったとしても、Bに主キーがなければ
その属性を一意に特定することができないってことだろ？
「主キー」の意味するところが違う？
367:NAME IS NULL
11/02/26 10:56:57.58
>>366
テーブルBの個々の行(ロウ)を一意に特定する必要があるのなら、
そのテーブルBは(属性ではなく)エンティティを表現していることになる。
もしテーブルBでエンティティを表現したいのであれば、当然のことながら
テーブルBに主キーは必要になるよ。
368:NAME IS NULL
11/02/26 11:18:19.70
複数存在するのに一意に特定する必要のない属性って、想像しにくいんだが。
それってたとえばどんなもの？
もしかして、BのエンティティキーをAと独立に持つかどうかという話じゃないのか？
369:NAME IS NULL
11/02/26 12:04:19.62
>>368
想像しにくいというのが理解しがたいのだけれど、要望とあれば。
たとえばエンティティAが楽曲や書籍のような著作物であるとする。
この場合、作者(作曲家/作詞家/著者/原作者/翻訳者..etc)は属性であり、
ある著作物に複数の作者が関わることがあるから、複数の属性になる。
370:NAME IS NULL
11/02/26 12:23:57.65
いや、問題は「一意に特定する必要がない」ということの方なんだが。
作曲家と作詞家、あるいは作曲家が2人いてもそれらは個々に特定
できなきゃならんのが普通だろ。
主キーを持たないということは、仮に同じ曲に同姓同名の作曲家が
2人いたとして、それを区別する術がないということだ。
371:NAME IS NULL
11/02/26 12:32:11.67
>>370
>それらは個々に特定できなきゃならんのが普通だろ。
特定する/しないという判断は、与えられた問題(要求仕様)によって変わる。
「普通だろ」というのは設計者の勝手な意図(思いつき)にすぎない。
もしも特定しなくてもいいという問題であるのもかかわらず一意性を作り込んだのなら、
それは過剰な設計(設計ミス)ということになる。
372:371
11/02/26 12:35:49.91
>>371を一部訂正する。
X: もしも特定しなくてもいいという問題であるのもかかわらず
O: もしも特定しないという問題であるのもかかわらず
373:NAME IS NULL
11/02/26 12:40:50.21
別に本人が必要ないと思ってるんならいいんじゃない？
こんな頭の固いやつにいくら言っても無駄。宗教と同じ
374:NAME IS NULL
11/02/26 12:48:42.38
あらゆるテーブルには主キーが存在しなければならないという考え方が、「頭の固い」発想だと思う。
どちらにせよ、人格攻撃に走ることしかできないのなら、漏れは議論から降りるよ。
375:NAME IS NULL
11/02/26 12:53:18.72
だからさ、そんなもの見たことがないからどんな例があるか聞いてみたんだが？
RDBでは主キーがないテーブルも許されるが、設計論としてはリレーショナル
モデルにおいて主キーがないなんてことはありえないし。
376:NAME IS NULL
11/02/26 13:02:13.25
>>371
ん？しかし>>346では「エンティティA無しにエンティティBが存在しうるか否かで決める」と言っているが？
377:NAME IS NULL
11/02/26 18:27:05.81
あまり読んでないけど、
AなしにBが存在し得ない状況では外部キーが主キーと同じ意味を成すといいたいのかな。
そんなことないけど。
378:NAME IS NULL
11/02/26 19:18:11.77
>>375
>だからさ、そんなもの見たことがないからどんな例があるか聞いてみたんだが？
重複を許す(=一意性を保証しない)属性テーブルというのは、普通に存在するよ。
なるべく分かりやすい例を挙げたつもりだし、重複の可否(=一意性の保証/無保証)を決めるのは、
DB設計者ではなく与えられた問題(要求仕様、つまり顧客)であることも書いた。
ここまで説明してもなお、自分は見たことが無い/経験した事が無いので想像がつかないと
言われたら、自分としてはショボーンとするしかない。
>RDBでは主キーがないテーブルも許されるが、設計論としてはリレーショナル
>モデルにおいて主キーがないなんてことはありえないし。
まず、関係論理/関係代数の世界においては、タプルに一意性が存在することを仮定しているから、
タプルの重複はありえない。ただし、残念ながらリレーショナルモデルというのは、
タプルの重複を許す多重集合(マルチセットまたはバッグ)なんだ。だからタプルの重複はありえるし、
従って一意性は必ずしも保証されない。必要であれば明示的な一意性制約の宣言が必要になる。
次に、RDB実装における主キー(プライマリキー)と、リレーショナルモデルにおける主キー
(行の一意性を保証する候補キーの集合)とを混同して理解しているように見える。
379:NAME IS NULL
11/02/26 19:24:09.00
（>>378の続き）
たとえば>>365の(2)でテーブルBに一意性が必要であるならば、設定した外部キーと候補キー
(例えば作者名カラム)との組(くみ, タプル)に対してUNIQUE制約を設定するのが正しいDB設計。
この場合、外部キーと候補キーの組を「主キーとみなす」。(「主キーを設定する」とは言わない。)
>>364のようにテーブルBへ主キー(プライマリキー)を設定した場合には、RDB実装における
テーブルの一意性は保証されても、リレーショナルモデルにおける一意性(作者名の非重複保証)は
実現できないから、誤ったDB設計であると思う。
380:378
11/02/26 20:12:53.64
>>326,327
個別にはレスしないが、二人とも「単体での存在性(エンティティなのか？属性なのか？)」と
「主キーの有無(タブルの一意性を保証するのか？しないのか？)」を混同してるように見える。
381:378
11/02/26 20:15:43.69
アンカをミスった。
>>326,327は間違いだ。>>376,377に訂正する。
382:NAME IS NULL
11/02/26 20:18:00.38
>>378
そういう一般論を言ったら、Aに関係なくBが存在する場合だって
必ずしも主キーは必要ないってなるんじゃね？
383:NAME IS NULL
11/02/26 20:25:44.02
>>380
それを混同したのが>>346だと思うんだが。
384:378
11/02/26 20:36:57.54
>>382
それでも良いと思う。どこに(普通か普通じゃないかという)境界線を引くか、という話になるね。
>>383
えーと、>>346で書いた「主キーを設定する」という表現は、すべてDB実装における
主キー(プライマリーキー)のことだよ。それが読み取れないということは、やっぱり混同してるんだね。
385:NAME IS NULL
11/02/26 20:54:52.06
つまり「主キー」という言葉には2種類の意味があって、自分が意図していたのは
違う方の意味だとｗ
>>379では「設定する」と「みなす」なんて言い換えまでしてご苦労なこったな。
386:NAME IS NULL
11/02/26 21:41:24.92
小難しい表現の割にはどうでもいい話だったな
387:378
11/02/26 21:44:24.81
>>385
えーと、困ったな。言葉の「使い分け」はしてるけど、「言い換え」はしていないつもりだよ。
「言い換え」とは、同じ事柄を別の方法で表現するという意味だよね。
>>346のテーブルAは、RDB実装における主キー(プライマリキー)とリレーショナルモデルにおける
主キー(一意性)が一致しているから「主キーを設定する」という表現をしても誤解されることはない。
それに対して、>>379のテーブルBはリレーショナルモデルにおける主キー(一意性)は存在しているけど
RDB実装における主キー(プライマリキー)は存在しないから、誤解の無いように「主キーとみなす」と
表現方法を「使い分けた」。
日本語って難しいね。
388:378
11/02/26 21:55:30.25
>>386
>>379では、「>>363のDB設計は誤りであり>>379が正しいDB設計である」と
言い切っちまっているんだけど、これはそのまま放置しといていいのかな？
それとも、これすら「どうでもいい話」なのかな？
「いいや、....だから>>364が正しい」とか「自分ならこうする」というような
反論/異論を期待してたんだけど....。
389:NAME IS NULL
11/02/26 22:09:32.49
彼の言う「主キー」と、「主キーを設定する」という用語は
一般的なSEやプログラマがRDBMS上でのテーブル設計をする際のそれと
意味合いが違うってことです
一般的なRDBMS上のテーブル設計では、そのテーブルの行を個別に識別できる項目（の組み合わせ）を
システム的に指定することを主キーを設定するといい、その指定された項目を主キーと呼びます
そういう意味では、行を識別必要があるする全てのテーブルにおいて、主キーを設定することが推奨されます
つまり、全てのテーブルに主キーがあるべきであると言う主張が成り立つわけです
390:NAME IS NULL
11/02/26 22:11:18.60
もうどうでもいい。
Ｔ字形の論理編ぐらい、どうでもいい。
391:378
11/02/26 22:14:41.27
いけね、また間違えた。
X:「>>363のDB設計は誤りであり
O:「>>364のDB設計は誤りであり
392:NAME IS NULL
11/02/26 22:19:21.49
もともと「設定する」と「みなす」を別の意味で使っていたのなら、>>346のテーブルAも
「設定する」と「みなす」場合両方があるわけだろ？
それを誤解がないからと勝手に片方だけ書いたら逆に誤解するわ。
じゃあ聞くけど、もう一度言葉の定義を明確にして>>346を正しく書き直したらどうなるの？
393:386
11/02/26 22:48:50.20
>>388
たとえば伝票と明細のケースでいえば
明細テーブルでは行を一意に識別する主キーはいらないってのがお前の立場なんだろ？
それで要件満たせるんなら別に問題ないと思うけど、
普通は明細の各行単位で修正入れたいケースとか必ず出てくるから、
現時点で必要ないように見えても必ず主キーは設定するように俺はする。
それがサロゲートキーなのか複合キーなのかは別にどっちでもいい。
ただ、現時点での要件を満たせるんなら後で修正すればいいだけだから、
別にお前のやり方でも俺はかまわない。
お前みたいなやつを説得するのは経験的に難しいとわかってるから、
機能的に不具合が出ないんなら議論なんかせずに迎合する。
要するにどっちでもいいし、どうでもいい。
394:NAME IS NULL
11/02/26 23:01:47.25
>>387
モデルの一意性は存在してるけど実装のプライマリーキーが存在しない状態ってなんだよそれ。
つか、そもそも設計段階でそんなもん考慮するのか？
395:378
11/02/26 23:28:17.16
>>389
つまり、一般的なSE/PGのRDB設計とは>>375が言うところの設計論としての
リレーショナルモデルとは意味合いが違うってことなんだな。
だから、>>379のような「主キーとみなす」という表現は普通じゃないってことか。
うん、よく分かった。これからは注意しよう。
ところで、>>364では
>子の主キーも設定する。親への外部キーはNOT NULLで参照する。そんだけ。
とあるのだけれど、この「主キーも設定する」という表現は、自分は
単純に「プライマリキーを設定する」という意味であると(勘違いして)解釈しました。
でも、これは>>389によれば「適切な候補キー(たとえば作者名カラム)と外部キーとの
組合せに対し個別に指定できるよう主キーとして(UNIQUE制約を)システム的に指定する」と
解釈すべきなのかな？
分かっている人には当たり前なのかもしれないけど、>>344,363のような初心者に対して
「主キーも設定する」という短い一文からそのような推測を期待するのは、
ヒジョーに厳しすぎるんじゃないかと思うんですが、いかがですか？（自分も勘違いしたし....。）
いや、それすら「一般的なSE/PGのRDB設計」なら普通なのかな？
396:378
11/02/26 23:29:45.71
>>392
>>346を書き直してみた。これなら誤解はしないかな？
>>>344
>テーブルA,Bの関連が 1..N(Nは0以上) の基本を以下に書くよ。
>
>(1) テーブルAにプライマリキーを設定し、テーブルBには(テーブルAを参照する)外部キーを設定する。
>(2) 次にテーブルBにプライマリキーが必要か否かは、エンティティA無しにエンティティBが存在しうるか
> 否かで決める。ここで、もし存在しえないのなら、テーブルBは(エンティティではなく)属性を
> 表現することになるから、テーブルBへのプライマリキーの設定は不要になる。
>(3) 最後に(エンティティまたは属性)Bの一意性について検討する。もしBに一意性が必要とされるなら、
> (1)で設定した外部キーと適切な候補キー(たとえば作者カラム)との複合キーをリレーショナルモデル上の
> 主キーであるとみなし、その複合キーに対してUNIQUE制約を設定する。
>
> （以下は同文なので省略）
397:378
11/02/27 00:12:42.89
>>393
いいや、その伝票と明細のケースで言えば、明細テーブルの各行は普通にエンティティだと思う。
だからリレーショナルモデルにおける主キー(一意性)は存在するよ。ただし、RDB実装における
主キー(プライマリキー)は設定せず、(明細テーブルを参照する)外部キーと候補キーとなる
行番号カラムとの組(から成る複合キー)をリレーショナルモデルにおける主キーとみなすという
違いはあるかもしれないけどね。
このケースで属性となるのは、ある行を構成する各桁の値だ。ここで、(>>365で書いたように)
行エンティティがその値を「ただ一つだけ(only one)」持つのなら、その値は行エンティティの
カラム(フィールド)として表現する。ここまでは問題無いと思う。意見が分かれるのはこの先だ。
もしも行エンティティがその値を「いくつか持つ(zero or more)」のなら、その値は
属性テーブルとして表現するものとし、属性テーブルには(行テーブルを参照する)外部キーのみを
設定し、プライマリキーは設定しない。更に、もしも与えられた問題下でその値に一意性が
必要であるのなら(=必要な場合に限り)、外部キーと値の組を主キーとみなしてUNIQUE制約を設定する。
具体的な例を挙げれば、値引きオプション、つまり「論理値の集合」で値を表現するケースになる。
ある行が商品を表現するとして、その商品に対する様々な値引き(優待顧客値引き/個別値引き...etc)を
0個以上の任意の組合せで表現することになるだろう。
この場合、>>393であれば、どのようにDB設計をしますか？やっぱり値引きテーブルにも
プライマリキーを設定するのかな。もちろんそれでも(AP開発に苦労はしても)要求仕様を
満たせるだろうから、どっちでもいいし、どうでもいいんだけどね。
398:NAME IS NULL
11/02/27 00:15:40.50
>>396
ふむ。「設定」が>>389の意味だとするならば、言っていることはだいたいわかる。
＃本当は「存在しうる」とか「エンティティ」と「属性」の違いなんかは明確ではないが、
＃ここではそれを措いても特に問題ない。
その上で反論だ。
(1)1:Nならば無条件でBに外部キーを設定することになっているが、こここそ、Bが
Aから独立して存在するかどうかで変わる部分だろう？そうでなきゃ、対応するAの
レコードが存在するBの外部キーはNULLになってしまう。
(2)一意性が必要かどうかは要件で決定されるって自分で書いていなかったか？
自分は必要ないケースはめったにないと思っているが、どちらにしても、エンティティ
ABの関係とは関係がない。
(3)ここは言葉の問題。候補キーは(1)の外部キーを含む場合と含まない場合が
あるが、どちらにしてもそのまま主キーになり得る。だから、外部キーを含まない
候補キーとの複合キーなどというものは考えなくていい。
399:389
11/02/27 00:22:38.04
>>395
>「主キーも設定する」という短い一文からそのような推測を期待するのは、
>ヒジョーに厳しすぎるんじゃないかと
「一般的なSE/PGのRDB設計」ならそう思うのが普通だと思うが
純粋な設計と言うよりは、実装方法論だがな
だからあえてRDB設計とかいう言葉じゃなくて、RDBMS上のテーブル設計って言葉をつかったんだ
400:NAME IS NULL
11/02/27 01:01:50.65
>>397
なんか例がおかしくない？優待値引きとか個別値引きとかあるのになんで論理値なの？
それはそれとして、値引きテーブルに一意性が必要ない(=同じ値引きが複数存在してもよい)
と言うことであればそれはそれでありだと思うが、特定の値引きを削除するとか変更するなんて
要件があった場合は一意性が必要となる。
一方で、ここに1商品1レコードの在庫テーブルがあったとする。これはここで言う「属性」には
当たらないと思うが、一意性の要否については上の値引きテーブルと変わらない。
つまり、一意性の要否を判断する上で「エンティティ」か「属性」かは関係ない。
401:378
11/02/27 01:49:22.13
>>398
(1) AとBが 1:N の関係であるなら、N側であるBから見ると1側であるAは必ず「ただ一つだけ(only one)」
存在しているはずだと思います。だから、Bの外部キーがNULLになるケースが想像できないのですが？
(2) まず(2)では(一意性ではなく)存在性について述べているので、自分には論旨が不明です。
ただし一意性については指摘のとおり、(存在性と同様に)その必要性を決めるのは要件(要求仕様)です。
この点については、>>396への追加記述が漏れていました。
(3) この候補キーというのは、>>364の「子の主キーも設定する」というところのプライマリキーを
指しているのですか？もしそうであり、なおかつプライマリキーが人工キーである、
たとえば hoge_id のようにデータ型が自動インクリメントされる整数(つまり)であるなら、
自動的に一意性は保証されるから複合キーは考えなくていいでしょう。
自分は(なるべく)人工キーは作らず複合キーで実装する立場ですが、それはまた別の話です。
402:386
11/02/27 02:16:30.65
>>397
値引きオプションだって修正や削除の必要が発生する可能性はあるから、
当然主キーつけるに決まってるよ。
そもそも実務的には値引き伝票切るケースが多いけどな。
その例えはお前の主張したいことからして全く適切じゃない。
もっとちゃんとした例を出せ。
> プライマリキーを設定するのかな。もちろんそれでも(AP開発に苦労はしても)要求仕様を
> 満たせるだろうから、どっちでもいいし、どうでもいいんだけどね。
お前、いつの時代の人間なの？
最近のアプリケーションフレームワークなら、むしろプライマリキーをつけないほうが
特殊な処理過ぎて苦労するだろうが。
403:NAME IS NULL
11/02/27 03:53:37.69
軽い実例を出してくれたほうが伝わりやすいことは業務をやってればわかることだと思うんだけど、
いつまで文字でがんばるのか。
404:NAME IS NULL
11/02/27 07:35:09.08
>>401
(1)確かに、1:0..Nと書いていたな。それを前提としているならばここはその通り。
(2)この文章は存在性を述べているわけではなく、存在性を条件に一意性の要否を
述べているんだろ？その上で、前提が(1)の通りであるならばBは常にAなしに存在
し得ないわけで、その条件は意味がないことになる。つまり「(2)Bにはプライマリー
キーは不要」とだけ書いても同じこと。
(3)やっぱり具体例がないと伝わらないか。
例えばテーブルBが{X,Y,Z}だとして、XがAへの外部キーだとしよう。
ここで候補キーが{X,Y}の場合、それをそのまま主キーとすることができる。
また、候補キーが{Y,Z}だとした場合であっても、主キーをXとの複合キー{X,Y,Z}と
する必要はない。
つまり、「外部キーと候補キーの複合キー」はいずれの場合でも必要ない。
候補キーの定義からして自明のはずなんだが。
405:NAME IS NULL
11/02/27 10:13:02.26
うざいから、ER図付きでやってくれ
406:NAME IS NULL
11/02/27 10:17:07.66
もともとの話は>>346に対する>>364の反論から始まってるんでしょ？
例えばブログの記事にタグ付けするような場合、
記事テーブル（記事IDがPRIMARY KEY）と
タグテーブル（記事IDがFOREIGN KEY）を作るとして、
364氏はタグテーブルでは何をPRIMARY KEYにするんだろう？
「子の主キーも設定する。親への外部キーはNOT NULLで参照する。」
と言っているからサロゲートキーを作るって話なんだろうな。
それだけの話だった（ように見える）のに、
以降の議論はただ話を難しくしてるだけのような。
407:NAME IS NULL
11/02/27 11:23:29.66
なぜサロゲート？タグテーブルには候補キーが存在しない前提なの？
408:406
11/02/27 11:37:17.75
どういう候補キーがあると思う？
記事IDとタグの組み合わせを主キーにするってのは考えられるけど
それだと「親への外部キーはNOT NULLで参照する」っていうのを
わざわざ書く必要がない。（主キーなら必ずNOT NULLだから。）
わざわざ書いてるってことは364氏の言ってる主キーには
外部キーを含んでないっていう前提があるんでしょ？
（あくまで推測ね。俺は364氏じゃないから。）
409:NAME IS NULL
11/02/27 13:07:55.88
>>364の真意は知らんが、「主キーに外部キーを含めない」と限定していたようには
俺には読めなかったな。含んでいようがいまいがNOT NULLということだろ？
1. わざわざNOT NULLと書いたから主キーには含まないんだろう
2. だとすると候補キーもないんだろう
3. じゃあ何をPRIMARY KEYにするんだろう？
4. たぶんサロゲートキーを作るんだな
3.の疑問を持った時点で自分の推測を疑えよって話だな。
410:406
11/02/27 13:22:03.68
うん、まあ、そうかもしれんしそうじゃないかもしれん。
どっちにしろ、364氏の真意が分からんことには議論はできないよね。
411:NAME IS NULL
11/02/28 15:56:49.49
364だけど、
>>406
「タグテーブル」が記事に対するタグ付けを表す(記事ID, タグID)、かつ
タグの順序に意味はないとして、同じタグを同じ記事に複数回付けられ
ないのであれば(普通の仕様だと思う)主キーは(記事ID, タグID)。
「[これはすごい][これはすごい][これはすごい]...」みたいに、同じ記事
に同一タグを複数回認める酔狂な仕様なのであればサロゲートキーも
必要。
後者は純粋に関係モデル的にはそもそもこのようなキーがないとデータ
を表現出来ない(setだから)。SQL的にはsetではなくbagだから無くても
表現できるけど、大抵は無いと更新時に填る。
>「子の主キーも設定する。親への外部キーはNOT NULLで参照する。」
>と言っているからサロゲートキーを作るって話なんだろうな。
いや全然。そんな話じゃない。
外部キー参照は仮に主キーを参照していてもNULLは入れられる。
「子単体は存在しない」、すなわち必ず親を持つのであれば明示的に
NOT NULLは宣言する必要がある。
>>409
>含んでいようがいまいがNOT NULLということだろ？
正解。
412:NAME IS NULL
11/02/28 16:15:31.13
もひとつ、>>346に聞きたいのは、>>346のルールとか、そのあと
改正した>>396のルールとか、これ教科書か何かに書かれたものなの?
であれば参考までにリファレンスを示してくれると嬉しい。
413:406
11/02/28 18:47:49.98
つまり、>>364の
「子の主キーも設定する。親への外部キーはNOT NULLで参照する。」
は以下の意味だってことだろうから、俺は特に異論はない。
「子の主キーも設定する。
ただし、要件によってはサロゲートキーとすることもあり得る。
親への外部キーはNOT NULLで参照する。
ただし、子の主キーが親への外部キーを含む複合キーである場合は、
明示的にNOT NULLを指定する必要はない。」
346氏（=378氏？）は、単にサロゲートキー否定派なんじゃない？
414:NAME IS NULL
11/02/28 19:49:10.77
>>413
そゆこと。ただし以下の下りはちょびっと。
>ただし、子の主キーが親への外部キーを含む複合キーである場合は、
>明示的にNOT NULLを指定する必要はない。
必要ないし意味的にはダブるかもしれないけど、それでも明示的に
指定するかな。ごくごく個人的には、単に作法として。
テーブル定義を読んでも、parent_id *** NOT NULLと直接書いて
あった方がparent_idの取り得る値の制限としては解りやすいし。
>346氏（=378氏？）は、単にサロゲートキー否定派なんじゃない？
よくわからんす。自然キーでも人工キーでも、必要な場面で正しく
使えばどっちでもよいです。
415:NAME IS NULL
11/03/01 00:15:51.62
「弱実体」でググると>>346が言いたかったことと、どこが間違っていたかがわかるかも。
416:NAME IS NULL
11/03/01 01:34:29.60
>>396
> (2) もし存在しえないのなら、テーブルBは(エンティティではなく)属性を
> 表現することになるから、テーブルBへのプライマリキーの設定は不要
逆にエンティティA無しにエンティティBが存在しうるとすればどう
するの? プライマリーキー定義するの? どう決めるの?
> (3) 候補キー(たとえば作者カラム)
それは部分キーだ。候補キーじゃない。他のレスでも間違っている。
言葉遣いの問題だが、関係モデルの超基本だ。
> (3) その複合キーに対してUNIQUE制約を設定する。
なんでUNIQUE制約? PRIMARY KEY制約だとダメなのか? だってその
「複合キー」はテーブルB中の行を一意に選択出来るんでしょ? 主キー
の資格十分じゃん。
素のUNIQUE制約はNULL許可するけど、それでも良いの?
417:NAME IS NULL
11/03/01 01:43:38.21
>>397
> 具体的な例を挙げれば、値引きオプション、つまり「論理値の集合」で値を
> 表現するケースになる。ある行が商品を表現するとして、その商品に対する
> 様々な値引き(優待顧客値引き/個別値引き...etc)を 0個以上の任意の組合せで
> 表現することになるだろう。
関係従属性(商品, 値引きオプション) -> 適用可能[true or false]が存在。
なので値引きテーブルは(商品ID, 値引きオプションID, 適用可能)。
主キーは(商品ID, 値引きオプションID), 商品ID・値引きオプションIDに
外部キー制約。ちなみにBCNF。完璧じゃん。
主キーつけるのに何を悩む必要があるのか、それが解らない。
418:NAME IS NULL
11/03/01 02:10:41.89
>>378氏は一生懸命頑張って主キーがいるいらないの説明しているけど、
まず純粋にスキーマ設計の立場からいうと各テーブルの候補キーを特定
しておくことはマストだよね。でないと正規化が出来ん。
次に正規化が完了した関係スキーマをSQLで実装するときには候補キーに
対応する属性やその組に適切な制約をつけておくことは作法だよね。
でないとデータの整合性をアプリケーションレベルで保証する必要がある。
次に、それでも更新時のパフォーマンスの問題などで制約を外したい事は
無いわけじゃないよね。でも基本的にキーに対する制約を外すとテーブル
中の各行をアトミックに更新出来ることをDB側で保証できなくなる。
なのでその部分はアプリ側で制約するとか、更新の対象や単位を詳細に
見極めて判断したりする必要がある。
ましてや>>344は初心者だといっているのだから、教科書通りER図など
から主キーも含めたテーブル定義を導出する方法で良いじゃないか。
419:NAME IS NULL
11/03/01 03:10:14.37
みんな教科書通りにやろうとしてるぜ
みてる教科書の分野が微妙に違うんだがな
420:NAME IS NULL
11/03/01 04:11:06.16
>>417
関係従属性 -> 関数従属性。
関係モデルの超基本だ・・・釣ってくる・・・
421:デフォルトの名無しさん
11/03/04 00:09:48.83 nwTUgCQG
話をサロゲートキーの話題に戻すが、
①商品マスタの商品コードが変わったときの話だが、
サロゲートキーにしておけば、コードの付け替えが楽。
②トランザクションにてその時点のマスタ値を保障する方が安全
つまりトランザクションには、商品ＩＤ、商品コード、商品名等を
すべて保持する。
①と②は明らかに同時に成り立たないわけだが、
この矛盾はみんなどうしてる？
あと、階層関係があるマスタ、たとえば事業部マスタと部門マスタで
事業部と部門の紐付けが変更されうる。部門の名称変更がある等の理由で、
適用期間をおのおの持った場合、サロゲートキー（事業部ＩＤ）
だけでリレーションさせると、事業部マスタの世代が増えたタイミングで、
リレーションが破綻するわけだが、どうしたらいいんだろ。
422:NAME IS NULL
11/03/04 00:38:25.10
> ①と②は明らかに同時に成り立たないわけだが、
> この矛盾はみんなどうしてる？
矛盾なんかしてません。
馬鹿じゃないの？
> 適用期間をおのおの持った場合、サロゲートキー（事業部ＩＤ）
> だけでリレーションさせると、事業部マスタの世代が増えたタイミングで、
> リレーションが破綻するわけだが、どうしたらいいんだろ。
どういうシチュエーションでどういう設計をしたら破綻するのか
全然イメージがわきません。
多分サロゲートキーじゃなくてお前の頭が悪いんだと思うよ。
423:NAME IS NULL
11/03/04 00:55:03.15
>>421
サロゲートキーの使い回しをせず、商品コードの書き換えもマスタ
への追記で対応すれば(2)は本来不要なんじゃないのかな。
424:NAME IS NULL
11/03/04 01:36:28.45
まず、この例で言うなら、商品コードが変わった場合
過去に登録されたトランザクションデータをどうしたいかを考えろよ
過去データを塗り変えたいなら１が便利
過去データはそのまま保持したいなら２が便利
それだけの話だろ
違う要件に対する解決案をならべて同時に成り立たないって当然だろ
425:NAME IS NULL
11/03/04 01:39:40.34
履歴とリアルタイムデータの区別が付いてないっぽいな
426:NAME IS NULL
11/03/04 01:57:35.75
>>424
2にしてもトランザクションデータに追記する際に商品コードとか
商品名などを商品マスタの内容からコピペしているのであれば結局
1で対応出来るのだが。
商品マスタは基本追記で、最新フラグとか削除フラグとか付けて
古い商品レコードも全て保持するのは案外一般的だと思うけど。
427:NAME IS NULL
11/03/04 20:05:10.85
サロゲートキーでよくわからないところがあるんだが
本来pkになるはずだった項目の制約はどうすんの？
前に張られたこのURLの例では、制約について一切触れてないから、そんな制約張りませんってことなのか・・・？
URLﾘﾝｸ(gihyo.jp)
428:NAME IS NULL
11/03/04 20:14:23.32
制約つければよくね。
429:NAME IS NULL
11/03/04 20:25:51.61
NOT NULLとUNIQUEでいいじゃん
430:NAME IS NULL
11/03/04 20:28:03.50
>>428
もともとpkにする予定だった項目には、例外なくuniqueを張りたいんだけど
>>427の例ならどうするべきですか？
431:NAME IS NULL
11/03/04 20:35:13.01
>>427
場合によるとしか言いようがない。
挙げられた例だともともと主キーだったitem_noにUNIQUE制約とか
は付けられないよね。同じitem_noを使い回すので。
沢山の属性を組み合わせた複合キーをシンプルなサロゲートキーで
置き換えるような場合は、主キーこそサロゲートキーにしたとはいえ
元々の複合キーも未だに候補キー、つまりキーに含まれる属性値の
組み合わせはユニークなはずなので、UNIQUE制約を付けた方が良い。
432:NAME IS NULL
11/03/04 20:36:53.99
>>430
item_no（商品ID）とitem_name（商品名）の組み合わせに対して
UNIQUEだろうね
しかし>>427の例って商品ID自体が自然キーじゃないよな
433:NAME IS NULL
11/03/04 20:55:19.98
>>427のように、同じitem_noを使い回すのであればテーブルには更に
最新フラグとか削除フラグをつけることが多いと思う。
[id(サロゲートキー), item_no, item_name, deleted]みたいな感じで。
で、上記の例の場合は削除フラグdeletedがfalse、つまり現在有効な
行の中でitem_noのダブりがあると困るわけなのだけど、この制約を
書くのはちょっと面倒くさい。フラグ値を工夫するとか一般制約を
使うとかすれば書けるけど。
実際はアプリケーションレベルでタブりを事前確認するロジックを
書くことが多いんじゃないのかな。
434:NAME IS NULL
11/03/04 21:06:10.73
>>431
＞つまりキーに含まれる属性値の組み合わせはユニークなはずなので、UNIQUE制約を付けた方が良い。
この部分がよくわからないんですが、もうちょっとスキルが低い人にもわかるようにお願いできませんか？
>>432
名称もunique制約に含めるって、普通に行われることですか？
見たことが無いのでちょっと抵抗があるんですが。
それから、>>427の例の商品NOは、人口キーのようなどうでもいい文字列ってわけじゃなく
お客さんのなんらかの都合により使いまわされる事がある、お客さんも把握してる文字列なわけですから
自然キーの典型的な例だと思うんですが、違うんでしょうか？
>>433
変なデータができあがっちゃうとまずいんで
私が見たことのあるDBでは2重に重複チェックしてました。
具体的には、プログラム側でマスタを更新するまえにDBに問い合わせてチェック→重複してるようならweb画面にエラーを出す
プログラム側のチェックを通ったあとも、unique制約により、DB側でチェックが行われ、これも通れば更新されるといった仕組みでした。
おそらく削除フラグを付けたほうがいいというのは、期間でなくフラグを参照することで
select文を発行するときの負荷が減るというのが目的ですよね？
重複チェックはなかなかミスが出るようなところじゃないから、アプリ側できっちりやれってことでしょうか？
435:NAME IS NULL
11/03/04 21:30:12.87
>>434
プライマリキーのカラム数が5個ぐらいあって、Joinがしんどくてしんどくてしょうがないという理由から
ただの連番のカラムを作って、それをキーとするようにしてみた
という状態であれば、もともとの5カラムにユニーク制約つけたままで問題ないよ
436:NAME IS NULL
11/03/04 21:32:21.28
>>432
それがUNIQUEになるなんてただの思いこみなんじゃないかって思う
437:NAME IS NULL
11/03/04 21:35:44.50
>>435
すごくわかりやすい、ありがとう。
効果は開発効率のアップと、select文のコストが少し減るって感じかな？
その目的でサロゲートキーを使う場合
全てのテーブルにサロゲートキーを追加するんじゃなくて
pkの項目が多くなりそうなテーブルにだけ追加するのが良さそうですね。
サロゲートキーを使用するテーブルの場合、例外なく最初の列に「PK_テーブル名」というカラムを作り
それをサロゲートキーにするというルールで設計すれば、アプリチームの混乱も防げて良さそうですね。
438:NAME IS NULL
11/03/04 21:41:20.76
>>434
例えば月給テーブル(社員ID, 年, 月, 給料)を考えてみる。
主キーは(社員ID, 年, 月)ね。
で、理由はともあれ誰かさんが属性3つの複合キーなんて非効率的だ!
サロゲートキーにしろ! と叫んだとする。で、サロゲートキーSIDを追加して
月給テーブル(SID, 社員ID, 年, 月, 給料)、主キーSIDにしましたと。
で、このテーブルをよく見てみると、確かにSIDはキーですが、元々の主キー
(社員ID, 年, 月)もテーブル内の行を一意に特定出来るキーなんですね。
というか一意に特定出来ないと困る。でないと同じ社員が同じ年・月に複数回
給料もらえちゃいます。
関係モデルでは一つのテーブルが複数の「候補キー」を持つことがあります。
この場合はSIDと(社員ID, 年, 月)の二つの候補キーがあります。
その中から「主キー」を一つだけ選ぶわけですが、だからといって残った他の
候補キーがキーでなくなるわけではありません。それらも引き続いてキーです。
なので上記の例だと候補キー(社員ID, 年, 月)にUNIQUE制約を付けておく
必要があります。
439:NAME IS NULL
11/03/04 22:00:25.24
>>434
>おそらく削除フラグを付けたほうがいいというのは、期間でなく
>フラグを参照することでselect文を発行するときの負荷が減ると
>いうのが目的ですよね？
例えばサロゲートキーを使った商品マスタテーブルを使って実際に
トランザクションデータを書き込むとき、伝票に書かれた商品IDから
サロゲートキーを逆引きする必要があります。
しかし>>427のテーブルの場合、商品ID001からサロゲートキーを
逆引きすると二つサロゲートキーの値が出てきます。これはで困る。
なのでフラグを付けて現在も有効なレコードだけから検索するように
する必要があります。
もちろん特別にフラグを設けずに、例えば有効期間を表す列に「現在も
有効」を表す特別な値(>>427の例だと"9999")が仕様として定義されて
いる場合はこれを使って絞り込んでもよいわけです。
ただこの手の終了フラグを使った場合、商品IDのタブりを防ぐ制約は
やや凝った記述になりがちで、となると現状PRIMARY KEYなど基本
どころ除けばDBMS毎に書ける制約の表現力がバラバラなのが難しい。
MySQLなんてCheck制約は書けてもガン無視するとか、そんな仕様。
なんでアプリ側でチェックするロジックを書くことも多い気がします。
440:NAME IS NULL
11/03/04 22:26:37.03
>>438
丁寧な説明ありがとう。
この板はIDが無いみたいなんで、どのレスをした人がどのレスを返してくれてるのかわからないけど
>>435と>>438は同じ事ですよね？
>>439
MySQLでcheck制約がきかないのは初めて知りました・・・なんと恐ろしい。
>>427の場合は、トランザクションテーブルに書き込む商品の情報は
商品IDじゃなくてsrg_key（サロゲートキー）じゃないですか？
>>427の例の仕様ではこうなってるはず
・マスタのpkはサロゲートキーを使用する。
・トランザクションテーブルの外部参照をする列に格納するキーは、参照先のサロゲートキーを入れる。
・過去に入力された名称は、その時点で入力された名称をマスタから取得する。
・unique制約は付けない。
サロゲートキーの一つの利点である、pkに指定する項目が1つになるという部分は理解できました。
どこのページを見てもあんまり紹介されてませんが
unique制約が付けづらいというのはサロゲートキーのデメリットとして覚えておいた方が良さそうですね。
441:デフォルトの名無しさん
11/03/04 22:32:56.51
商品IDがダブらないなら本質的にサロゲートキーは不要かと…
やばいのは商品IDというか商品コードがメーカーによって使いまわされて、
ある製造日より別商品に割り当てられたが、
販売店の在庫管理としては商品コードと入荷日でしか
管理していなかったため、同一商品コードの違う製品が混在してしまって
何を販売したのか管理できず混乱するなどですよね。
442:NAME IS NULL
11/03/04 22:45:47.53
>>441
得意先のマスタなんかは在庫とかって概念がないからどうゆうふうに設計してもなんとかなりそうなもんだけど
商品に関しては商品IDを使いまわす可能性があるならサロゲートキーは必須になるのか
443:NAME IS NULL
11/03/04 22:50:32.51
すごーーーーく根本的な話になるんだけど
商品IDの使い回しを行いたい時ってどうゆう時？
得意先や部署はわかる。
合併やら統合やらあるもんね。
商品IDはわからん。
444:デフォルトの名無しさん
11/03/04 23:00:00.52
桁数だろう？
どれだけ必要になるかわからないからって
たとえば２０桁のコード体系をあらかじめ用意するのかってこと。
覚えられん…
445:NAME IS NULL
11/03/04 23:10:09.40
>>443
古いシステムならコードのMAXが5桁とか普通に有り得るだろう。
446:NAME IS NULL
11/03/04 23:18:26.31
えー・・・
447:NAME IS NULL
11/03/05 00:12:24.71
くるくる回る商品IDなんてよくある。
ある時点においてユニークであれば、それで現場は回っていくんだよ。
なもんで、こっちとしてはサロゲートキーを作って、商品IDガン無視する。
たとえ今はいらなくとも、商品IDで検索したいってなったときに困らないように、
ある時点で有効な商品IDがどれかを特定できる情報を保持しておく。
448:NAME IS NULL
11/03/05 00:39:28.99
俺の場合、
自社に決定権がないコード体系のマスタ（商品など）は、サロゲートキー
自社に決定権があるコード体系のマスタ（得意先マスタ）はナチュラルキー
ジャーナルのヘッダはサロゲートキー、
ジャーナルの明細はヘッダのＩＤ＋明細番号の複合主キー
とすることが多いが、これって古臭い？
449:NAME IS NULL
11/03/05 01:22:17.28
雑誌コードなんか桁が足りなくて新規発番が出来なくなって使い回してるよな
450:NAME IS NULL
11/03/05 01:28:21.09
そうゆうことか。
周辺システムが古くて桁数が少ないので
商品IDを使いまわさずを得ないと。
>>441みたいな場合ってどうなるの？
頻繁に商品IDが付け替えられて、古いほうの在庫も残る可能性がある。
同じ商品IDで、商品そのものも名称もまったく違う商品が存在する。
Web画面で商品を入力するためのボタンがあって、ポップアップで検索ボックスみたいのが出てきて
IDで検索すると同じ商品が複数出てくる。
それを選択してもらう。
Webの入力画面でコードを手打ち入力した場合の動作は？
ajaxとかで名称ひっぱりたいとこだけど、複数出てきた場合は新しい方を出したりするのかな？
なんにせよ恐ろしい・・・
こうゆう運用ならサロゲートキーは必須だ・・・
451:NAME IS NULL
11/03/05 02:15:11.10
>>448
その得意先マスタのキーって得意先IDみたいなの、つまりサロゲーとキーでは？
ナチュラルキーになりうるのってなんだろうとぐぐってみたところ、
上場企業限定ならISINコードというものがあるようだけど、これなのかなぁ
>>449
休刊して番号温存だね。あるある。
>>450
客から見て、在庫も含めると異なる商品に対して同じ商品IDがついているけれども、
業務を滞りなく行えているのであれば、何も悩む必要はないよね。
こちらとしてはサロゲートキーで処理をしてしまえばいいだけだよー
452:NAME IS NULL
11/03/05 02:17:08.29
>>450
加えて、商品IDでの検索結果が複数出てきたなら複数出せばいいんだよ。
それで業務がまわっているということが不思議だなぁと思うことはあれど、
それを正としなければいけないしねｗ
453:NAME IS NULL
11/03/05 02:30:08.03
>>451
>上場企業限定ならISINコードというものがあるようだけど、これなのかなぁ
>>448の言う「自社に決定権があるコード体系」というのは、
そういった業界標準コード体系を意味しているのではなく、
業務の中で自然に発生する自社特有のコードを指していると思う。
たとえば、紙の受注伝票に記入する得意先コードや受注商品コードというのは、
自社特有の(自社で決定できる)自然キーである可能性が高い。
逆に、発注伝票に記入する発注商品コードというのは、
(自社では決定できないから)人工キーとせざるを得ない可能性が高い。
454:NAME IS NULL
11/03/05 16:14:51.45
お前ら、商品ID商品ID言ってるけど、使いまわした時点でIDとしての役割を果たしてないだろうが
商品コードを使いまわす、が正しい用語だ
455:NAME IS NULL
11/03/05 17:59:31.77
まぁ目安だよな。あくまでも、自分が定義したエンティティに対してそのコードが
一意であるがどうかで判断すべきであって。
・よそで定義されたコード→一意でない「可能性がある」
・自分で定義するコード→当然一意に「できる」
極端な話、実際の商品の品種と商品コードの一意性が一致しない場合であっても、
「商品」ではなく「商品コード」エンティティを作る分には商品コードをそのままキーと
してもぜんぜんかまわないわけだ。
456:NAME IS NULL
11/03/07 20:06:48.91
>>453
＞自社特有の(自社で決定できる)自然キーである可能性が高い。
純粋な意味では、自然キーではないよね。ｗ
457:NAME IS NULL
11/03/07 20:11:28.00 OIEGkLgo
>>440
＞MySQLでcheck制約がきかないのは初めて知りました・・・なんと恐ろしい。
こわくないよ？
つーか、それっておいしいの？
MySQLしか使わないオレには、よく
わからん話なんだよな。
458:NAME IS NULL
11/03/07 20:53:11.82
>>456
システムの外で定義されるのが自然キーだろ？コードが人工的かどうかじゃなくて。
そんなこといったら、人名とか市町村名なんてどっちか判断つかん。
459:NAME IS NULL
11/03/08 05:36:45.40
>>457
知らない者にとっちゃ恐ろしいだろ。
定義できるのにまさか動かないとは思わないだろうし。
460:NAME IS NULL
11/03/09 01:13:08.54
>>454
このスレでのID、コードの使い分けって一般的に通用するものなの？
いや、自分もそういうふうに使い分けてるんだけど、他の人がそんな風に気にしてるの見たことがないので。
461:NAME IS NULL
11/03/09 01:47:19.22
>>460
基本的には普遍でユニークな社員番号(商品ID)と、変更可能な姓名(商品コード)、
みたいな形で一般人も接してはいる。
462:NAME IS NULL
11/03/09 15:48:40.12
>>460
まあ、大概の人は混同してる。このスレでも混同してる人もいるしな
一般の人にとって、コード振ってあるのに別にIDとるのは無駄に思えるんじゃね
463:NAME IS NULL
11/03/09 20:21:29.21
「混同」っていうと、まるで使い分けないのがおかしいみたいだな。
2行目をみるとそれぞれ別物のなにかを指しているというのはわかるんだが…
464:NAME IS NULL
11/03/10 06:07:06.59
IDでもコードでも俺はどっちでもいいな。
使い分けてないプロジェクトがあっても、sql書く時に項目名間違えづらいなぁ程度にしか思わない。
465:NAME IS NULL
11/03/10 09:17:01.62
>>458
システムの外で「独立して」定義されるのが
自然キーだろ？
顧客コードなんかデータベース以外に
ほとんど用途がないんだから。
466:NAME IS NULL
11/03/10 15:38:23.73
>>463
ID=コードなシステムもまあよくある
というか、IDとコード別にもつシステムの方が少ないと思うけど
IDとコードもつシステムの例はコード使いまわされるようなやつとか
「その他」とか「一般小口」とかのコードもってるシステムとか
IDっていう用語の意味を考えると、厳密に区別できないとIDじゃないからな
467:NAME IS NULL
11/03/10 22:58:24.84
>>465
この場合の「独立して」ってどういうことを意味しているのかな？
ここで挙げられた顧客コードってのは、「システムの外で定義されるけれども独立してない」例？
468:NAME IS NULL
11/03/11 04:29:35.90
独立していない可能性がある、または随時変更される可能性があるコードなんじゃない？
客から見えるコードだと、コードを振りなおしたい要求って結構くるよね
469:NAME IS NULL
11/03/11 07:32:25.94
>>465
>顧客コードなんかデータベース以外に
>ほとんど用途がないんだから。
ええぇっ！！、それが常識なの？
自分のいる世界とは別の異次元な世界の住人さんらしい.... hahaha
470:NAME IS NULL
11/03/11 11:13:05.74
「データベース」の意味をどう捉えてるかによるだろうな
471:NAME IS NULL
11/03/11 11:34:03.00
「データベース」でくくるとさすがにちょっと狭いと思うぞ
ほとんど「情報処理」とか「システム化」と同じぐらいまで解釈を広げればまあ納得しなくはないが
472:NAME IS NULL
11/03/11 13:15:03.35
台帳をデータベースと呼ぶかどうか
473:NAME IS NULL
11/03/11 13:18:57.55
>>469
そんな反応しなくてもｗ
そこだと、顧客コードは恒久的に変わらないことが前提で、顧客コードで会話等がされてるんでしょ。
その業務であればそのコードはIDであり、自然キーといっていいと思うよ。
474:NAME IS NULL
11/03/13 03:34:25.71
どのスレが適当か探してみたんですが、スレ立てるまでもない質問スレが見つからなかったので、ここで質問させて下さい。
病院で働いているんですが、今、上司からの依頼で、内視鏡検査の画像をデータベース化する作業をしています。
現在のシステムに以降する前の約２年分、件数にして4000件ぐらいのデータです。
データ形式ですが、約３ヶ月分ずつのデータがDVDにまとまっていて、DVDの中に入っている.exeファイルを起動して閲覧する、というものを、何とか一つのデータベースにまとめたいと悩んでいます。
各データは一件あたり数十枚で、たとえば34枚だとすると、フォルダ名00001、その中にjpeg画像00001から00034が３４枚格納されていて、つぎの件はフォルダ名00035となり、その中にまた画像一枚ずつに数字でファイル名がふってある形でした。
閲覧ソフトに患者名かIDか検査日を入力すると、画像が閲覧できます。
DVDに入っているのは画像フォルダ、恐らく画像とひも付けしたログファイルのフォルダ、あと閲覧ソフトです。
こういったデータを、Windows上で現在のシステムに移植するには、(オリンパスの出入り業者に確認した話ですが)一件一件検査オーダーを立てて、画像を指定する必要があるとのことでした。
自動でデータを読み出して全ての過去データDVDをデータベース化するか、現在のシステムに移植するには、どういうソフトを使えば可能でしょうか？
軽く調べたところ、SQLとやらいうスクリプトの話がでてきましたが、ド素人なので厳しいかと正直諦めかけてますorz
よろしくお願いします。
475:NAME IS NULL
11/03/13 03:48:10.98
>>474
多分この内容だと情報が足りなすぎて誰もアドバイス出来ないと思う。
ファイルの格納の仕方は「なんだそれ」という感じではあるけれども
サルベージ出来ないわけでもない。多分ネックは、
>恐らく画像とひも付けしたログファイルのフォルダ
の中身と
>Windows上で現在のシステムに移植するには
の「現在のシステム」が分からないと、どうにもならないかと。
ただ間違ってもログファイルの抜粋をこのスレに貼り付けたりは
しないでね。
いずれにしても出来合いのソフトで出来そうな作業じゃない。
専用のマイグレーションのためのプログラムを書く必要はある。
476:NAME IS NULL
11/03/13 04:30:03.11
>>475
レスありがとうございます。
やはり専用のプログラムが必要ですよね…
現在のシステムは、内視鏡サーバーに全て検査内容が直接スタックされるもので、オリンパスのsolemio というものです。
検査一件一件のデータをログから指定して、画面上の場所指定でオートクリック、ログ入力、画像指定が出来るソフトというと、オンラインゲームのチートソフトくらいしか思い付かず、それにしたってログを読み出すプログラムが別に必要になりそうな予感はしていました。
ちなみにログの抜粋がアウトなのは個人情報の関係ですか？
477:NAME IS NULL
11/03/13 04:37:50.27
>>476
医療情報流出～匿名掲示板でアドバイスを装って診察データを入手か～
・・・なんてニュースになりたくないでしょw
オリンパスにデータインポーター提供してもらうしかないんじゃない
のかなぁ
478:NAME IS NULL
11/03/13 05:08:53.69
>>474
画像の格納方法に規則性があるなら、画像を取り出すことは出来るかもしらんが、
「患者名かIDか検査日を入力すると～」がネック。おそらくこの他にも情報があるんだろうけど、これらのサルベージ方法が問題。
フォルダの中にテキストで埋めこまれてるとか言う間抜けな作りなら個人PGでも解析出来るだろうけど、さすがにそんなことはないだろうな・・。
そもそも元システムのライセンス的にどうかとかなりかねないし。
逆に解析を諦めるなら、最終手段で人がPC2台使って手入力でやれば出来る(つまり出入り業者の言う、「一件一件検査オーダーを立てて、画像を指定する」)。
この最終手段の可能性コミで、オリンパスに見積もってもらうのがベストだと思う。ただ人海戦術は安くないけどね。
479:NAME IS NULL
11/03/13 06:48:05.90
>>474
ざっと読んでみて、まず基本的な課題を挙げてみる。
(1) ストレージ管理
4000件のデータで各データが数十枚のDVDに格納されているというデータ量が膨大なケースだけど、
それらコンテンツのカタログ(目録)だけをデータベースすればいいのか(= カタログDB化)？あるいは
すべてのコンテンツをストレージ(要はハードディスク)内に格納するのか(= 画像DB化)？という判断。
もし前者であればソフトウェア(アプリケーション開発)だけ対応できるけど、
後者の要求を叶えるとすれば専用のストレージハードウェア導入も検討対象になる。
(2) 遺産データのデータ形式仕様
DVDに格納されている過去データについて、そのデータ形式仕様を把握する必要性があるという課題。
データ形式仕様には、(a) DVDボリューム構成、(b) DVD内のディレクトリ/ファイル構成、
(c) ログファイルのデータ構造などがある。この課題を、より具体的な副課題に分解してみる。
(2-1) その遺産データの作成者から仕様書を入手
作成した外部の業者(あるいは院内の担当者？)に問い合わせて入手できるのが理想。
もし入手不可であれば、自力で分析する、いわゆるリバースエンジニアリングという作業が必要。
(2-2) 入手した仕様書と(DVDに格納された)実データに一貫性があるかを検証
理想的には、すべての実データが仕様書に従って作成されていれば、
(相対的に)単純なスクリプト(プログラミング)でデータ移行処理が可能になる。
最悪なのは、手作業でDVDボリューム名/ディレクトリ名などを決めて焼いていたケース。
(2-3) ログファイルのデータ構造について機械可読性を確認
理想的なのは、XMLのような形式的なテキスト形式で保存されている場合。
もしも独自のバイナリ形式であれば、(2-1)のデータ形式仕様書の入手が必須になる。
最悪なのはフリーなテキスト形式のケースで、一件ずつ手作業で編集しなければならなくなる。
(3) 新規アプリケーション開発の必要性
理想的には、(2)の作業を経て準正規化(機械処理可能化)された中間データを、現行の(OLYMPUS?)
システムへ移行する(相対的に単純な)変換プログラムを作成することで、課題が解決できるケース。
もしもそれが不可であると判断されたなら、その中間データを元に新規DBの開発を検討する。
その場合には、どのようにDBを設計すべきか？という、このスレ住人向きの話題にようやく辿り着く。
480:479
11/03/13 07:23:59.19
>>479の課題(3)で新規DB開発を決定した場合に限定される話だけど、
医療関係者が(外部の業者に頼らずに)自力でデータベース化を図るとしたら、
FileMaker Pro というDBアプリケーションがよく知られている。
FileMaker Pro は、Microsoft製であればAccessに相当するデスクトップDBソフトだけど、
SQLを憶える必要は無いし、テーブル設計/画面デザインからスクリプト作成まで
すべてGUIで操作できるから、簡易なDBであれば専門家でなくても開発できるのでお勧め。
（個人的にはシステム分析初期段階のラピッドプロトタイピングに活用している。）
たとえば以下の医療画像管理アプリはソースも公開されている。
・マイコミジャーナル：ファイルメーカ選手権（第一回）月間優秀賞：患者画像記録
URLﾘﾝｸ(journal.mycom.co.jp)
FileMaker Proは試用版が無償で利用できるから、まずダウンロードして触ってみるのがいい。
質問等はビジネスsoft板に専用のスレがあるから、そちらへドーゾ。