11/04/05 21:20:38.76
正直、なぜこんなのでこの人たちがここまで熱くなれるのか疑問ではある
615:NAME IS NULL
11/04/05 21:28:27.96
かつてクラス名簿を頼りに好きな娘の家の住所を探し歩いた経験からです
616:599
11/04/05 21:31:55.96
>>612
一応、設計上、住所がひとつの構造の実例もあるよ、という話だったが...
まぁ、確かにそろそろスレチだな。失礼。
617:NAME IS NULL
11/04/05 21:37:41.55
スレチ以前になんの参考にならないからもう出てこなくていいお(^^
618:NAME IS NULL
11/04/05 23:55:16.74
厳密に言えば設計じゃないのかも知れんが、要件定義、モデリングの話題としては興味深い。
619:NAME IS NULL
11/04/06 00:54:23.79
市町村コードと住所正規化コンバータの存在は確かにためになった
サロゲート談義よりよっぽど
620:NAME IS NULL
11/04/06 09:28:28.56
このスレ市町村コード知らない人が見てたのか
621:NAME IS NULL
11/04/06 09:29:53.92
>>620
私は公的なものは大嫌いだから。
622:NAME IS NULL
11/04/06 09:42:58.98
よくわからんけど、話題終了した方がよさそうなのはわかった
623:NAME IS NULL
11/04/06 09:50:12.87
>>621
ねっこのおりん
624:NAME IS NULL
11/04/06 20:40:10.84
「都道府県がなぜ北海道始まりなんだ！」と言われたらJISを参照する
625:NAME IS NULL
11/04/07 16:18:49.41
>>621
ただの馬鹿ですね
626:NAME IS NULL
11/04/07 20:22:35.53
まあ市町村コードなんて、馴染みのない人には全くない系統の知識だからね
いつなんどきどういう案件が降ってくるか分からないんだから、普段から
色んなことにアンテナを張っておくことが大切だってことさ
627:NAME IS NULL
11/04/08 01:02:53.18
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
> 色んなことにアンテナを張っておくことが大切だってことさ
628:NAME IS NULL
11/04/08 04:33:07.53
それで結論として、
住所はユーザが打ち込んだひとつの欄でいいね。
エラーがあるかとか、いろいろ解析するのが楽しみでね。
629:NAME IS NULL
11/04/08 08:59:30.25 UUNyLKi3
はいはい、タックシールタックシール
630:599
11/04/08 09:52:11.62
>>628
結論は、色々なケースがある、だろ。
住所一つ厨も、自分のケースは特殊と言ってたろ。
631:NAME IS NULL
11/04/08 12:25:56.73 UUNyLKi3
その場かぎりのアンケートみたいなのは使い捨てでいいんさ
顧客情報が絡んで将来的にDWH的な使い方がありえるんなら、
コード化にコストを費やすことを考えなくちゃならない
つか、そう提案すべき
632:NAME IS NULL
11/04/11 17:06:53.99 9HYaTenG
ちょっとご相談というかむしろどのような方法が一般的なのか判らない状態での質問です。
DBはSql鯖2008R2 アプリはC# WinFormで作成しています。
現在開発中物件で 営業時間・毎週休業日・祝祭日・臨時休業・臨時営業 の設定が必要なシステムを作成する事になりました。
今考えているのは各設定を年度毎にもち
確定された時点で1年分のカレンダーデータを一気に作成(1年分のレコードを作成)
修正された場合、修正日以降のカレンダーデータを変更する
ような感じで設計してみようと考えています。
カレンダーデータは
年月日
営業開始時間
営業終了時間
種別(0営業 1臨時営業 2定休 3祝日 4臨時休業 )
のような感じで1年分を作成し保持しようかと・・・
伝えたいことがうまく伝えにくいのですが、休日を柔軟に設定する事が出来て、
営業時間・休日のデータが簡単に取り出せる・判定できるようなテーブル設計を行いたいのです。
なんらかの定石的な方法があるのであればいいのですが、そのようなものは社内にないようでして・・・
何らかのヒント的なものでもいいので、お手すきの方がいらっしゃいましたらご教示いただければと思います。
633:599
11/04/11 23:53:09.51
>>632
種別が一つじゃ、臨時営業だけど、実は定休でなおかつ祝日の日とかどうすんだよw
種別は全部バラしてマスタにしろ。
それぞれの重み付けは固定ならアプリで持ってもいいし、変動するならこれもマスタにする。
634:NAME IS NULL
11/04/12 00:25:33.31
>>632
今考えてみた
T/種別( ID 名称 )
T/ルール（ 月 日 曜日 何週 優先度 開始 終了 種別ID ）
T/カレンダー（ 年月日 開始 終了 種別ID ）
V/カレンダー（ 年月日 開始 終了 曜日@年月日 何週@年月日 種別ID ）
カレンダーをデフォルト値で1年分生成してからルールを適用する
俺ならこうするかも知れない
635:NAME IS NULL
11/04/12 07:21:40.99
>>632
例えば、毎週休業日が年に三回変更になったとして、
そのルール・ログが残らないような設計はおかしい。
毎週休業日
---------------------------
休業日起点 | 休業日終点 | 曜日
というようなテーブルを定義していくべき。
636:NAME IS NULL
11/04/12 10:01:08.49
おはようございます。
>>633->>635
お時間を割いていただきありがとうございます。
皆さんの意見を参考に考え直してみました。
結果以下のような感じに・・・皆さんから見るとまだまだ設計力が足りませんが
TM_祝日(年月日{pk}、祝日名)
※祝日は基本固定なんで年更新処理で1月n週や固定日などから生成し、変更可能に
TM_毎週休業日(適用開始日{pk}、適用終了日{pk}、曜日番号{pk})
※休日は現在毎週n曜日のみでいいらしい。毎月n日とかその他のが出たらマスタ増やして対応
TM_臨時休業(年月日、備考[理由])
TM_臨時営業(年月日、営業開始時間、営業終了時間、備考[理由])
TM/営業時間(適用開始日、適用終了日、曜日、営業開始時間、営業終了時間)
※毎週土曜は半ドンらしくこういった持ち方もあり？
TM_カレンダー(年月日{pk}、{pk}に対する曜日、{pk}に対する第hoge週,営業開始(null有)、営業終了(null有)、備考)
※開始・終了のいずれかがnullなら営業してない(片方だけnullはありえない)
※備考は祝日\r\n臨時営業とかの情報をマスタ変更時に残すようにする
上記TM系のマスタ条件でカレンダーを生成
マスタ変更時は影響範囲のカレンダレコードだけを同時に書き換え
(優先度は 臨時営業>臨時休業>定休>祝日 カレンダーデータ作成時に固定となる)
TM_カレンダーは(年月日{pk}、{pk}に対する曜日、{pk}に対する第hoge週)だけを持ち、
ビューやストアドなどで結果を返すほうがデータの無駄が無いかもしれませんが、
参照の回数とかを考慮して少しデータ量が増えますがあえてテーブルに書き込むようにしてみました。
設計て難しい、でもこれしっかりやらないとアプリがグダグダになってしまうので
妥協範囲を出来るだけあげてキッチリやっておきたいです・・・
637:634
11/04/13 00:29:50.20
曜日、何週をビューで定義したのはバグとミスオペでの変更を抑える為
634の形ではルール適用で必要になるから持ってる
636の形はよく理解できてないけどあんまり必要じゃない気がする
ぱっと見TM_祝日はハッピーマンデー対応できない気がするけど毎年修正するのか？
>>635
毎週休業日の変更とかどの業種でもかなり大きい変更だから年数回どころか数年に1回だと思うけど
638:NAME IS NULL
11/04/13 00:48:02.58
>>637
TM_祝日は基本年次処理でつどつど祝日をyymmddで保持するっぽいから、ハッピーマンデーも問題ない気がする。
639:NAME IS NULL
11/04/13 00:57:50.12
>>638
そこでやるのか～
ずいぶん高度だな
640:NAME IS NULL
11/04/13 05:27:11.25
>>639
高度というか、力技だな。単純だがそれがいい。
管理者も入れ替わり、運用がおざなりになったときに、日付の入力を忘れたり間違えたりして支障が出る可能性は高そうだがｗ
641:NAME IS NULL
11/04/13 09:51:31.28
>>637-640
色々なご意見ありがとうございます。
>>637
いや、正直日付から週数や曜日は簡単に出るんですが、試しに入れてみたらそのデータがあるとDBを生で見たりする場合に
判りやすじかったのでパクらせてもらいました。
祝日に関してですが
年次更新時にデフォルトできっちりデータは入れてやります。(全て入力とかは間違えるし厳しいと思うので)
その為にプログラム内で1月1日は元旦、1月の第2月曜日は成人の日などの情報を持ち
その情報からレコードを作成してやります。
基本的に祝日定義や名称の変更があるんでその部分をDLLなり設定ファイルなりにして
変更時にアップデートでファイルの差し替え、年次更新時にそのデータ利用して一覧を作る
という感じです。
祝日の定義が変る可能性が非常に高いので、もし何らかの理由でこちらの対応が間に合わない場合、
何かユーザー側での変更可能な方法が必要かなと思いベタベタな実装にしました。
（今の政府は年度開始時に年度末の休日定義とか平気で変えてきそうなので・・・）
※地方によって祝日定義変わるとかホント勘弁してください。 ほんと苦肉の策です ありがとうございました。
後他の入力に関してですが
正直オペミスはあるとおもいます。なので入力チェックとかキツキツにする必要はあると思います。
(年次更新時に定義の範囲が今年度にかぶってない場合は出来ないとか)
PS.
仕様書・設計・レビュー・PG・デバッグ・設置と納品まですべて一人でやらなきゃいけないので頭が沸いてきました。
642:NAME IS NULL
11/04/13 10:00:34.82
>プログラム内で1月1日は元旦、1月の第2月曜日は成人の日などの情報を持ち
>その部分をDLLなり設定ファイルなりにして
なぜそれをＤＢに格納しないのかね
643:NAME IS NULL
11/04/13 10:14:53.39
>>642
年次更新のタイミングでその情報をDBへ格納します。
定義が変る可能性が高いので年次でギリギリまで登録待ってから登録→もし年内で変更あれば手動で変更
という予定です。
644:NAME IS NULL
11/04/13 23:30:26.66
ハッピーマンデーも将来無くなる可能性がある。
祝日をyyyy/mm/ddで持つのもありだね。
645:NAME IS NULL
11/04/14 20:42:54.35 2zZWkF3S
>>643
その年が変わってから、
その年の休日が変わる可能性なんてないよｗ
646:NAME IS NULL
11/04/14 20:55:04.90
>>643
>定義が変る可能性が高いので
変わる可能性が高い情報をプログラム側に持たすのか？
休日の定義もＤＢにもたせて、その定義から年次更新でマスタ作成すればいいだろ
647:NAME IS NULL
11/04/14 21:18:24.25
休日の定義を持たせたら、その休日の定義の有効期間まで保持しなきゃならなくなる。
だったら、素直にyymmddで休日を持たせたほうが話が早い。
648:NAME IS NULL
11/04/14 22:15:42.63
過去となった祝日は絶対に不変なのだから、yyyy-mm-ddで決め打ちでいいと思うけどな～
649:NAME IS NULL
11/04/14 22:51:22.94
祝日どころか全部過去適用なしなんだから有効期間ってのがなぜ必要なのか意味が分からない
単に、ルールで持てば？展開して日付で持てば？って話のような気がするけど
650:NAME IS NULL
11/04/14 23:07:13.39
>>649
例えば、極端な話、元日が1月1日ではなく、1月10日に変更になったとする。
当然、過去の1月1日には適用できないので、いつから元旦が1月10日になったのか日付を保持する必要があるだろ。
651:NAME IS NULL
11/04/14 23:11:40.13
別にないよ。
2010/01/01
2011/01/10
って持っとけばいいだけだから。
652:NAME IS NULL
11/04/14 23:17:29.01
>>651
だから、それでいいじゃん、と言ってるわけだ。
休日のルールを定義づけして、DBで保持する必要はない。
653:NAME IS NULL
11/04/14 23:57:19.08
>>650
ごめん、>>646の解釈が全然間違ってて見当違いなレスした
生成よりも反映でやった方が色々いい気がするけどなぁ
延々増え続ける祝日テーブルとか嫌だわ、俺は
654:NAME IS NULL
11/04/15 00:20:06.76
おめーの好き嫌いはどうでもいい
655:NAME IS NULL
11/04/15 00:54:12.36
>>654
ちょっと笑ったw
それにしても、ID出ないと議論もまともにし辛いね。
IDなしでもOKの理由ってなんかあるんだっけ？
656:NAME IS NULL
11/04/15 05:30:37.26
>>653
反映ってのが、ルールを動的に適用するって言う意味なら
ハッピーマンデーや春分の日を動的に適用するのが難しい
逆に、定休日の変更とか考えると動的に適用する方がいいかもしれん
ただ、生成にしても反映にしても、過去分切り捨てないなら
延々増え続けるのに違いはないと思うが
生成あるいは反映されたカレンダーをどう使うかにもよるだろうけど
変更の頻度とカレンダーを使う際のパフォーマンスとか考えると
俺なら適当なタイミングで生成する
657:NAME IS NULL
11/04/16 00:12:24.94
まさに今度の案件で、FROM年月日、TO年月日で営業日やそれ以外を保持する必要が出た。
祝日などは FROM:2011/01/01 TO:2011/01/01 名称：正月
658:NAME IS NULL
11/04/16 16:59:35.02
夏休みでもないと1日単位の方が効率的な感じだな
659:NAME IS NULL
11/04/16 17:41:05.38
こういうテーブルは差集合を取るために使うことが多いしな。
1日1レコードの方が何かと無難に思える。
660:NAME IS NULL
11/04/17 09:08:09.05
ここのスレのひとたちのレベルとは違いすぎるんで恐縮なんですが、、、
インデックスって何に設定するのが良いんでしょうか。
たとえば、掲示板の投稿テーブルとかだとなににインデックスを設定したらいいでしょうか
661:NAME IS NULL
11/04/17 09:13:32.97
検索キーに張ればいいよ。
662:NAME IS NULL
11/04/17 09:31:24.55
>>661
検索対象となりえるフィールドってことでしょうか。
今は名前と、本文メッセージで検索できるようにしてるので、
それらにINDEXつけたらいいのかな？
663:NAME IS NULL
11/04/17 09:35:35.93
名前はアリだろうけど、本文メッセージはインデックスの意味ないだろうね。
664:NAME IS NULL
11/04/17 09:59:15.72
>>663
文章が長すぎるからですか？
あと、
postテーブル （投稿
tagテーブル （タグ
こういう２つのテーブルがあるとして、
postテーブルに複数のtagがつくような場合（多対多であってますか？）
postとtagを結びつけるテーブルが必要だと思いますが、
このテーブルの名前がいい感じのが思いつきません・・・。
みなさんこういうテーブルは何テーブルと名づけてますか？
post_tag_relation
とかかな？
665:NAME IS NULL
11/04/17 11:55:47.26
テーブル名はそのものズバリの短い名称ならなんでもいい、SQLでの記述量が全体的に減る。
短くなるならローマ字表記もありだと思う。
666:NAME IS NULL
11/04/17 12:58:08.73
＞postとtagを結びつけるテーブルが必要だと思いますが、
そもそも直に結び付かないのがなぜかと問いたいが。
関係性が複数あってアナリシスパターンみたいに知識レベルと操作レベルに分けたいならともかく。
667:NAME IS NULL
11/04/17 13:26:25.07
>>665
短縮しようとすると必然的に漢字になる。
668:NAME IS NULL
11/04/17 13:58:57.30
>>666
postテーブル
id title name message
1 投稿テスト ななし てすです。
tagテーブル
id name
1 タグ１
2 タグ２
post-tagテーブル（ナイスなネーミングが思いつかない）
id post_id tag_id
1 1 1
1 1 2
↑
表にするとこんな感じです。
3つ目のテーブルがないと結びつかないと思いますが・・・できます？？
669:NAME IS NULL
11/04/17 15:01:12.87
いや、あってるよ。
それと、本文を高速に検索するには形態素解析とか別の技術がいる。
670:NAME IS NULL
11/04/17 15:05:04.50
>>669
ありがとうございます。
え、%LIKE%でやってて、全く問題なく動いてるんですけど、
書き込み数が少ないからいけてるだけなのかな
671:NAME IS NULL
11/04/17 17:00:42.33
LIKE句で早いかどうかはDB側のエンジンに依ると思います。
672:NAME IS NULL
11/04/17 17:19:18.92
ネーミングは、『R_投タ』だろ？
673:NAME IS NULL
11/04/17 17:31:36.42
件数とフィールドサイズ次第じゃね？
674:NAME IS NULL
11/04/19 00:35:20.25
１ 業務の区分番号で自然キー設計した
２ 削除履歴も残したくて削除フラグを作った（行を複製して削除=1する)
３ 削除フラグを立てた行を作るとキーが二つになってしまう！
４ 履歴を沢山もてるように削除日を作った
５ （自然キー + 削除フラグ + 削除日）で複合キーに変更した
６ 履歴行を除くためテーブルを結合してからwhere句で削除フラグ=0することに
７ クエリを１０段階くらいネストしてモリモリ書く
８ なんかデータが欠落してると思ってたら、INNER JOINしてることに気が付く
９ 手の施しようがなくなって俺のとこにお鉢が回ってきた
こんなデータベース管理したくねーよカス。だから女は嫌いなんだ
675:NAME IS NULL
11/04/19 08:28:01.29
>>674
8はたしかにバカだけど、ほかはまあ
しかたないんじゃね？
676:NAME IS NULL
11/04/19 15:53:11.76
てか別に手の施しようがなくなってもない気が
677:NAME IS NULL
11/04/19 21:02:38.78
クエリ10段階程度は、普通とは言わないけどたまにあるなー。
インデックスちゃんとはってたら結構パフォーマンスも出るし
678:NAME IS NULL
11/04/21 07:14:14.64
> （行を複製して削除=1する)
なんで複製するの？
679:NAME IS NULL
11/04/21 11:13:26.69
思うに区分番号を使いまわしたいんだろう
つまり、もともとも区分番号は候補キーじゃなかったって話で、
１から間違ってるってことだな
ただ、
>（自然キー + 削除フラグ + 削除日）で複合キーに変更した
らしいので、別にそれで何とかなるだろって話
そこは自然キーじゃなくて区分番号だろうと突っ込みたいが
>>674は区分番号がキーじゃないとちゃんと解ってるのかね
680:NAME IS NULL
11/04/21 17:50:16.56
何のテーブルとどう結合したのかよくわからんのだが、削除日だけだと
日付が絡んだ結合がかなり複雑になりそうな気が。
作成日も加えるとか、それこそサロゲートキー導入か。
681:NAME IS NULL
11/04/21 17:55:47.87
削除した事実と日付、元データのログだけなら、削除テーブルに退避させるだけでいい。
682:NAME IS NULL
11/04/21 21:31:10.43
>>678
よくわからないが、同一テーブル内に履歴があれば管理
しやすいと思った形跡がある。。テーブル開いてすぐ下に
履歴があるので、どう変更したか見やすいとか。
>>679
×（自然キー + 削除フラグ + 削除日）で複合キーに変更した
○（区分番号 + 削除フラグ + 削除日）で複合キーに変更した
書き間違い。すまそ
>>680
最初からそうしとけと
>>681
普通の人間が考えればなそうだな。考えたやつが普通の
人間じゃないから困る。
683:NAME IS NULL
11/04/21 22:10:23.27
ログ管理用のテーブル設計の難しさは異常
684:NAME IS NULL
11/04/29 00:43:58.61
ＤＢ設計のコツは、「難しく考えるな。あきらめろ！」
685:NAME IS NULL
11/05/01 01:24:07.02
>>683
何が難しいの？よければ要件を教えて。
686:NAME IS NULL
11/05/02 10:42:57.33
>>683じゃないけど、全文検索のこととか考え出して、行き詰まってんじゃないの
687:NAME IS NULL
11/05/02 17:27:10.54 Ym6L+dps
モデリングの勉強をしているのですが以下のような場合、どんなモデルになるでしょうか？
商品の卸売のようなシステムで
1．顧客からはは随時、受注がくる
2．ある時点で、受注を束ねて、顧客商品別に発注先に発注
3．発注先が直接顧客へ商品を配送して、完了報告をしてくる
という業務フローです。
自分のシステムでは、受注を受けるだけで、出荷は商品ごとの発注先任せといった感じです。
よろしくおねがいすます
688:NAME IS NULL
11/05/02 17:33:37.85
商品マスタと
発注先マスタと
受注テーブルを用意して適切に紐付け
任意のタイミングで商品別に集計出して発注アクション
その時に受注テーブルにあるレコードに発注済みフラグを立てる
おしまい
689:NAME IS NULL
11/05/02 17:46:15.64
１つの受注には、いくつかの商品があり、その商品は発注先はバラバラです。
受注：キー 受注番号 非キー 顧客番号、配送先住所
受注明細：キー 受注番号、受注明細番号 非キー 商品番号、数量、発注先
発注：キー 発注番号 非キー 発注先、顧客番号、配送先住所
発注明細：キー 発注番号、発注明細番号 非キー 受注番号、受注明細番号、商品番号、数量
リレーションは
受注：受注明細 １：N
発注：発注明細 １：N
受注明細：発注明細 １：１
発注まではこんな感じだとおもっています
690:NAME IS NULL
11/05/03 00:29:54.01 6I8m/Wta
>>689
なぜ、「配送先住所」が「受注」と「発注」の両方にあるの？
なぜ、「数量」と「商品番号」が「受注明細」と「発注明細」の両方にあるの？
よく分からない。
691:NAME IS NULL
11/05/03 00:35:37.80
>>689
一つの「顧客」は、一つの「配送先」を持つの？
それとも、一つの「顧客」は、複数の「配送先」を持ちえるの？
全ての受注は必ず発注されるの？
仮にそうだとした場合、
「商品番号」が決まれば「発注先」は自然と決まるの？
このあたりがはっきりしないと答えがだせないよ。
692:NAME IS NULL
11/05/03 01:05:27.07
>>687
メインのフローは馬鹿でもできるから、適当に組んでもみんなほぼ同じモデルになる。
ちゃんと考えなきゃいけないのは、返品、誤配送、破損、誤発注、キャンセル、郵送先変更、在庫切れなどの例外処理のフロー。
693:NAME IS NULL
11/05/03 03:49:27.10
>>692
勉強って書いてあるべさw
そこまで細かくやらんでしょ
694:NAME IS NULL
11/05/11 23:35:39.63 +dDfImqi
サロゲートキーってのは調べてみると
「ユーザーが認知しない、業務的に意味をなさない連番とかのキーにせよ。」というのは理解したんだが
このサロゲートキーは検索画面の条件や帳票項目とかに利用していいのかしら？
ユーザーが認知しないという意味では、利用してはいけない気がするが
たとえば業務的な採番ルールがない（ただの歯抜けOK連番とか）伝票番号の場合
システムでは検索条件にもなるし出力項目として利用されていると思う。
この場合、伝票番号とは別にサロゲートキーを持つのか否か。どうおもう？
695:NAME IS NULL
11/05/11 23:57:54.25
迷うまでもなく持つわ
696:NAME IS NULL
11/05/12 00:19:14.93
＞このサロゲートキーは検索画面の条件や帳票項目とかに利用していいのかしら？
いい。サロゲートキーにする意味は、未来永劫不変で一意であることを保証することだから、
IDとか識別番号とかいう名前で利用することはある。
＞この場合、伝票番号とは別にサロゲートキーを持つのか否か。どうおもう？
伝票番号が一意のサロゲートキーになるならどっちでもいい。
697:694
11/05/12 00:37:27.98
どうもです。
>696さんの意見はしっくりきました。
>695さんの、迷うことなく持つの理由は
>いい。サロゲートキーにする意味は、未来永劫不変で一意であることを保証することだから、
がユーザーが認知することで崩れるから。ということかな？
ユーザーが認知すると、ユーザーの使い勝手で「伝票番号に日付入れてくれ！」とか言われたら
未来永劫不変で一意であることを保証できんな
698:NAME IS NULL
11/05/12 00:45:57.64
伝票に日付、アルファベット、ゼロ埋めはザラにある変更
699: 忍法帖【Lv=22,xxxPT】
11/05/15 16:22:26.09
a
700:NAME IS NULL
11/05/15 20:33:01.83
>>697
キーの一意性が変わるような変更に対して、サロゲートキーが対策になる
なんて思っていたら痛い目見るよ。
701:NAME IS NULL
11/05/15 21:08:57.72
> キーの一意性が変わるような変更
？
702:NAME IS NULL
11/05/16 00:34:01.57
「未来永劫不変で一意であることを保証」できなくなるような変更のことだろ。
703:NAME IS NULL
11/05/16 03:35:54.10
>>700
キーって何のことだ？主キー？候補キー？
候補キーが、候補キーじゃなくなるような変更がありえるなら
（その前提がある段階で候補キーかどうかあやしいが）
その候補キーを主キーにしないでサロゲートキーを使うのは対策になるわけだが
お前の言う痛い目ってどんな事なんだ？
704:NAME IS NULL
11/05/16 05:15:31.90
>>703
主キーを追加しなくてはならなくなることだろう。
705:NAME IS NULL
11/05/16 07:17:25.05
>>704
サロゲートキーを使うっていうことは
当然そのサロゲートキーが主キーになってると思うんだが
サロゲートキーの一意性が保証できなくなるって話なのか？
706:NAME IS NULL
11/05/16 21:00:42.81
そんな風にシステム内部で発行する人工キーだけが唯一の候補キーになっているテーブル
だらけで、投入するデータがinsertされるべきかupdateされるべきかわけがわからない状態に
なってしまったシステムは見たことがあるな。
キーが無いのと同じことなんで、注意深くやらないと破綻するのは目に見えているんだけどね。
707:NAME IS NULL
11/05/16 22:50:38.28
>>706
> 投入するデータがinsertされるべきかupdateされるべきかわけがわからない状態に
サロゲートキー関係なくね？
708:NAME IS NULL
11/05/16 23:00:41.81
関係ないよ。
「サロゲートキーで一意性を保証」するから大丈夫なんて言えない例。
709:NAME IS NULL
11/05/16 23:20:15.18
魔法じゃないんだから、サロゲートキーに何期待してるんだよ (w
710:NAME IS NULL
11/05/17 00:07:43.44
>>708
いいえ
バカ除けを施しても破綻させちゃう逸材が居る限り大丈夫なんて言えない例です
711:NAME IS NULL
11/05/17 05:33:39.34
なんで、このスレのやつってサロゲート談義が大好きなん？
712:NAME IS NULL
11/05/17 06:47:19.90
バカ除け？サロゲートキーしかキーが無いテーブルがバカそのものじゃん。
713:NAME IS NULL
11/05/17 16:17:28.35
馬鹿寄せ呪文「サロゲート！」
714:NAME IS NULL
11/05/17 18:27:09.25
サロゲ廚、自重しろ
715:NAME IS NULL
11/05/17 21:15:26.73
fjのmalloc/free論争みたいなもんだな。季節の風物詩。
716:NAME IS NULL
11/05/18 00:23:53.39
>>706
イメージできないから具体例あげてみて