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
イメージできないから具体例あげてみて