11/03/29 22:02:11.24
外部キーとして持つ場合なんかの話だろ
551:NAME IS NULL
11/03/30 01:03:54.95
CREATE TABLE tablename (keyid VARBINARY(50) , columnid VARBINARY(50) , value BLOB , PRYMARY KEY(keyid , columnid));
ですべてことたりる
552:NAME IS NULL
11/03/30 01:56:16.14
その分アプリのロジックで苦労するわけだけれどもね。
553:NAME IS NULL
11/03/30 18:31:30.02
>>551
ガリレオ・ガリレイ
554:NAME IS NULL
11/03/30 23:04:14.47
このスレと
【より良い】データモデリング【モデルを】
ｽﾚﾘﾝｸ(db板)
こっちのスレって何が違うの？
上流の作業の違いがいまいちよくわからん
モデリング後に設計？設計後にモデリング？
555:NAME IS NULL
11/03/30 23:57:39.00 1ro9g/Hl
住所の項目ってどうしてるよ？
都道府県と住所１と住所２（マンション名など）
って分け方が多いみたいだけど、
都道府県以外分ける必要ないよね
556:NAME IS NULL
11/03/31 00:09:50.64
>>555
たとえばタックシールや送り状を作成する業務を考えると
住所が適当な長さで２行になってる方が都合がいいだろ
業務要件で住所が２行必要ならDB上も２項目でもつのは普通
つまり分ける必要があるかどうかは要件次第
557:NAME IS NULL
11/03/31 00:18:34.96 P2ST+s4H
２行かどうかなんてアプリケーション側の問題なんじゃ？
558:NAME IS NULL
11/03/31 00:40:24.56
要件に二行で折り返すことが含まれているのであれば、どこで
折り返すのか区切りが解らないと困るじゃん。
改行入りの文字列を住所として突っ込むのもありだけど、住所と
マンション名その他に分けて二つのカラムに分けて入れることが
多いと思う。
559:NAME IS NULL
11/03/31 00:40:37.54
アプリケーション側の問題？
データモデルが常にそれらから独立していられるわけでもないだろう。
560:NAME IS NULL
11/03/31 01:27:27.86
>>555
+--id--+--henji--+--syugo--+--dousi--|
| １ | YES | I | DO |
+----------------------------------+
561:NAME IS NULL
11/03/31 20:36:43.35 WO6NrX3S
>>555
> 住所の項目ってどうしてるよ？
郵便番号が取得できるなら郵便番号DBを利用する
できないなら総務省の地域コードを使う
コード変換できない番地以下は各レコードに持たせる
最低でもこうしないと話にならない
562:NAME IS NULL
11/03/31 20:53:20.54
DB的には住所をコード化するのが先決だわな
2行でタックシール(ｷﾘｯ)とか馬鹿じゃねえの
563:NAME IS NULL
11/03/31 21:52:14.51
単に土地住所と建物住所じゃないの？
564:NAME IS NULL
11/03/31 22:57:25.26
タックシールの馬鹿を見るだけで、全角英数は馬鹿という定説が正しいことがよく分かる
565:NAME IS NULL
11/04/01 00:06:20.96
DB的には氏名をコード化するのが先決だわな
566:NAME IS NULL
11/04/01 00:35:02.02
「コード化する」ってなに？
567:NAME IS NULL
11/04/01 00:42:28.28
たっくんおかえり
568:NAME IS NULL
11/04/01 00:48:36.32
(国)、都道府県、市町村、町域、建物その他で分けるだろ
569:NAME IS NULL
11/04/01 07:05:20.44 QNKMILe9
郵便番号検索とかどうしてる？
新しい市町村増えたり、メンテが面倒そうなんだけど
570:NAME IS NULL
11/04/01 07:09:15.74
そうだよ。
だから郵便番号検索機能が仕様にある場合はメンテ分も見越して金額が跳ね上がらないといけない。
現実は「簡単でしょ？付けてよ」でプロジェクト終わり。
571:NAME IS NULL
11/04/01 07:25:43.06
要件確認せずに、「だろ」って決め付けてもねぇ。
地番は？住居表示はどうすべきだと思ってるの？
572:NAME IS NULL
11/04/01 10:02:49.85
初心者ですDBの勉強もかねて、簡単なユーザ登録のできるBlogサイト作成しようと思っています。
日記のデータを保存するテーブルについて質問なのですが、一般的(他のサイトなど)に日記を保存している
テーブルというのは、1つのテーブルで全ユーザの日記のデータを保存しているのでしょうか？
例えば一般的には、ユーザID,日付,日記本文,(その他省略)という構造なのでしょうか？
この場合、ユーザ数が増えれば相当なデータサイズになり、1ユーザの日記を数日分、selectするのに時間が
かかるような気がします。(この辺が初心者で、時間がかかるのかもよくわかってないのですが・・・)
573:NAME IS NULL
11/04/01 11:09:31.44
まぁそのためのデータベースだ
適切な設定なら100万レコードからでも一瞬で目的のレコードを探せるよ
574:NAME IS NULL
11/04/01 22:51:49.57
それだと、日記が一日ごとにしか書けないな。
575:NAME IS NULL
11/04/01 22:54:03.22
適当な質問には適当な回答しか無いだろ
576:NAME IS NULL
11/04/02 02:10:35.17
お前ら、こういうDB設計の要件定義って、
仕事でやる場合どのくらい時間かける？最低1ヶ月はかかるよね
577:NAME IS NULL
11/04/02 02:18:13.66 SR6eBDqn
>>570
そういう情報ってどっかにAPI公開されてないのかな
もしくはデータが簡単にダウンロードできたり
578:NAME IS NULL
11/04/02 02:41:31.19
>>577
データは郵便局サイトに
コンポーネントもググれば簡単に見つかる
大概↑データを使用する前提
579:NAME IS NULL
11/04/02 09:09:49.55
つーか、ろくすっぽ調べず「郵便番号メンテが面倒」とか、「住所は二行でタックシールだ！」
とかその手の足りない子を見ると、正規化だのサロゲートキーだのを熱く語る前に、他にやるべき
ことあんじゃねえのって感じだな
580:NAME IS NULL
11/04/02 12:53:38.07
なんか、面倒だな
581:NAME IS NULL
11/04/03 15:32:48.21
それでも地球はまわっている
582:NAME IS NULL
11/04/03 17:10:43.94
そして原発は冷却中である
583:NAME IS NULL
11/04/03 23:20:21.80
>>568
そんなの、実データ使った解析でいかようにもできる。
客が入力したままの文字列を一つだけ保持しておけば、あとは正規化した住所を都度アプリ側で吐き出せばいい。
584:NAME IS NULL
11/04/04 00:39:15.82
>>583
アプリに全部任せてDBは設計もクソもなくていいって聞こえるが・・・
585:NAME IS NULL
11/04/04 00:47:44.84
座標保持するのが流行り
586:NAME IS NULL
11/04/04 06:56:16.69
>>585
ダイレクトメールという文化はやがて滅びるから
企業の視点では、住所や所在地情報の地位は
低下し続けるに違いない。
587:NAME IS NULL
11/04/04 07:51:03.48
>客が入力したままの文字列を一つだけ保持
こんなこと書いてるエセ設計者の言うことは無視でよろし
588:NAME IS NULL
11/04/04 19:32:50.57
エセというか、ただの馬鹿だろ
せっかく公共団体の統一コードがあるのに文字列で持たせるとか正気か？
どうせAccessあたりで糞アプリ作ってる底辺プログラマだろけど
589:NAME IS NULL
11/04/04 20:51:35.27
DM用や顧客用のデータなんだろ？
正規化用のデータを、持しても客が使うデータは、たとえ間違っていても入力のママで使うんだよ。
現場も知らない馬鹿が教科書通りに設計すると回らないから気をつけろw
590:NAME IS NULL
11/04/04 22:22:53.14
正規化と言いたいだけの中小企業Access使いとか、底辺を見ても何の参考にもならないし、
時間の無駄だから、まともな知能を持った人は郵便番号DBや地方公共団体コードを使いましょー
591:NAME IS NULL
11/04/04 22:23:08.98
馬鹿にしてるつもりなのかな？拙い日本語使って煽られてもねぇ・・・
592:NAME IS NULL
11/04/04 22:54:36.58
ハンマーを持った子供には何でも釘に見える
地方公共団体コードなんて覚えたての子供は、「住所」と出てきたらコードを
使わなきゃ気が済まないんだよ。
593:NAME IS NULL
11/04/04 23:40:02.69
まあ、要件も確認せずに何とかコードでOKとか言うやつは
まともな知能を持ってないってのは解る
あと底辺の人ほど他人を底辺だって決めつけるよな
バカっていうやつがバカ的な感じ
594:NAME IS NULL
11/04/04 23:46:14.17
たっくんおかえり
595:NAME IS NULL
11/04/05 00:53:48.93
>>590
名寄せのロジックの一部には郵便番号DBも使うが、あくまでも一部。
おまえ、日本全国の何百万という重複する住所の名寄せなんてしたことないだろ。
したことがあれば、あんな不完全なデータを錦の御旗にドヤ顔出来る訳がない。
596:NAME IS NULL
11/04/05 07:29:40.55
>日本全国の何百万という重複する住所
具体例どぞ
597:NAME IS NULL
11/04/05 07:33:04.51
>>596
どこそこ区の青葉台となになに市の青葉台で一例。
この組合わせを合計するとそんな数になりそう。
598:NAME IS NULL
11/04/05 08:24:56.02
>>597
そういうのは都道府県が違うので重複とは言わない
もっと例示するにふさわしい具体例を挙げるよろし
599:NAME IS NULL
11/04/05 08:53:52.43
>>596
数十万単位のユーザーが十数年にわたって複数回入力する住所の名寄せだよ。
当然ユーザーからしてみれば同じ住所でも入力パターンは間違いも含め多岐に渡り、市町村合併や郵便番号も変わるからね。
600:599
11/04/05 09:10:15.59
他にも英語表記やカタカナ、ひらがな表記も含む。
市区町村の区分も守られておらず(特に町と村。そもそものインターフェースが郡で区切ってたりする)、都道府県が空白なんてざら。
複数のインターフェース、複数の時代を経た巨大な住所データなんて蓋を開ければこんなもん。
入力時に住所が正規化される単一のシステムならなんの問題もないけど、そうでない上記のようなデータなら、住所は一旦すべて連結し、解析掛けるのが正確で早い。
601:NAME IS NULL
11/04/05 09:13:12.42
だからコードにしておけば手入力を解析だ名寄せだとかキチガイじみた発想にならんのだって
ためしに通販サイトかなんか見てみろよ
大抵、プルダウンから選択か、郵便番号から選択だろが
逆に手入力のメリットがあるなら出してみろや
602:599
11/04/05 09:24:48.43
>>601
日本語分かるか？
入力時に正規化出来るなら問題ないがと書いてるだろ。
新規で開発するような話をしてるんじゃなくて、手書きも含め、複数のインターフェースが存在することが前提のデータ処理の話をしているんだが。
603:599
11/04/05 09:28:14.95
>>601
そして、コード化の一番のデメリットは過去の住所はにたいおうしづらい
604:599
11/04/05 09:37:39.53
>>601
失礼、途中で送信してしまった。
コード化のデメリットは過去のデータに対応しづらいという事。購入、決済データぐらいじゃそこまで気にする事はないし、下手すればそもそもの住所の正規化すら要らないケースが多いけど、
過去にさかのぼる名寄せみたいに、コード化よりも解析のほうが現実てきなケースがある事を知っておいて損はない。
605:NAME IS NULL
11/04/05 18:49:22.35 Ge8zwV8y
>>602
> >>601
> 日本語分かるか？
> 入力時に正規化出来るなら問題ないがと書いてるだろ。
名無しIDなしでお前のレスがどれだかわかるわけねーだろw
つーか、DB設計の話をしてるのに名寄せだ解析だとか言い出すから、
頓珍漢に拍車がかかるんだっての
データ移行が要件なら、その解析とやらに使う労力を変換に割り振れよww
言ってることが支離滅裂だっつーのw
606:NAME IS NULL
11/04/05 19:31:24.00
>>605
要するに何の話をしているんだい。
607:599
11/04/05 20:05:05.66
>>605
わざわざ599と入れてるのも分からない馬鹿かw
だから、DB構造としては、住所は一つまのカラムしかもってない(まあ郵便番号くらいは持つが)と言う事だよ。
一応、入力時は分割されてるが、それを連結したものが正式なデータとしてつかわれる。
正規家した住所は複数のカラムを持つが、それは都度都度の最新住所を吐きだすワークテーブル扱い。
高言う実例もあるんだよ。
608:NAME IS NULL
11/04/05 20:20:17.47 Ge8zwV8y
>>606
・住所をまんまの文字列で持つメリットは全くない
・文字列を保持して解析とか言ってるのは池沼
・名寄せとかいきなり言い出してるのは馬鹿(同じやつだろうけど)
・タックシール(ｷﾘｯ
ちなみに文字列解析が現実的とか、噴飯ものの物を知らない子
みたいだけど、世の中にはコンバータってのが売っていてだな、
それで変換できないのは、対象外にするか、客先マターにするか、
その辺は契約にもよるけど、少なくとも俺らが住所と関わるって
のはそういうもんなの
いくら底辺プログラマで単価が安くても、アホな設計の尻拭いに
工数かけて解析とかありえねーよw
コンバータ買ってもらえって
とここまで書いたらタックシールが性懲りもなく現れた
もはや解読困難で相手にすんの面倒くさいから、他の人に任せる
といことで逃亡
609:NAME IS NULL
11/04/05 20:22:29.70
大変だなぁ。で、設計の話はどこ？
610:599
11/04/05 20:50:16.33
>>608
コンバーターは、それぞれの企業が自社で使う必要があって開発したものなことも知らないのか。
どんだけ小さな現場しか知らないんだよw
入力データを正規化して保持して、オリジナルを破棄出来るなら苦労はないんだよ。
自分の知らないしくみがあることは恥でもなんでもないのに、実例紹介してるのに信じないなら勝手にしろw
611:NAME IS NULL
11/04/05 20:50:39.64
変換ソフトの稟議書作成じゃね？
612:NAME IS NULL
11/04/05 20:53:18.81
>>610
設計の話しないなら帰れよ。
613:NAME IS NULL
11/04/05 21:00:32.80 r6xQc+hf
コンバータってこれか
URLﾘﾝｸ(www.addressmatch.jp)
昔住んでいた埼玉県大宮市高鼻町で検索したら、一発で変換できた！
オラ良いこと知ったぞ
でももう埼玉は住みたくない
614:NAME IS NULL
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
イメージできないから具体例あげてみて