10/04/07 09:27:33
またサロゲート厨か
3:NAME IS NULL
10/04/14 19:34:41
T字形ERマスターの俺様が華麗に2ゲット!
4:NAME IS NULL
10/04/17 02:43:18
有給と勤怠の管理システム作ってるけど、
有給の設計むずいな。前年度の繰越とか
5:NAME IS NULL
10/04/17 18:26:32
社員 今年残 前年残
A 20 15
B 5 9
で消化するとき今年残から先に減らせばいいだけ
繰越は単に今年残→前年残、今年残→規定リストからセットで済む
6:NAME IS NULL
10/04/18 17:34:12
なにそのくそせっけい
7:NAME IS NULL
10/04/18 22:26:32
どうしろと
8:NAME IS NULL
10/04/21 00:38:45 GuWbcNTa
簡単なのでいいから勤怠管理の設計載ってるサイト教えて下さい
9:NAME IS NULL
10/04/21 14:58:34
俺だったら、年次ごとに与えられた日数と消化した日数は別々に保存する。
計算結果だけ保存するのは、俺の感が駄目だと言ってる。
10:NAME IS NULL
10/04/22 03:22:06
有給テーブル
取得日
日数
勤怠テーブル
日付
出勤時間
退社時間
勤怠区分
勤怠区分テーブル
勤怠区分
有休残計算はストアドとかで
11:NAME IS NULL
10/04/30 13:54:02
T字型マスターの俺様、なんとか言ってやってください！
12:NAME IS NULL
10/05/04 21:11:32
自分達に無い物を作ろうとするから、どう設計すれば良いのか見えないんじゃね?
13:NAME IS NULL
10/05/06 17:59:31
有休テーブル
+社員ID
+年次（っぽいもの）
+付与日数
有休実績テーブル
+社員ID
+年次（っぽいもの）
+消化日数
有休実績テーブル（案２）
+社員ID
+取得開始年月日
+取得終了年月日
今現在の有休残はストアドとかで
14:NAME IS NULL
10/05/06 23:53:16
>>13
有給実績テーブルの消化日数って、有給テーブルにくっつけたらダメなの？なんでわけてんの？
15:NAME IS NULL
10/05/07 00:51:45
13じゃないのに勝手に答えるけど、
それだと付与・消化の属性を追加して使い分けるとか
あるいはrowそのものを書き換える必要が出てくるじゃない
テーブルで分けといた方が分かりやすいと思うな
休んだ日数を細切れでブっこんでおいて、全体の消化日数はID＆年次でselectしてsum取ればいいし
16:NAME IS NULL
10/05/07 10:15:44
>>14
有給の付与が年度の開始時にしか起こらないって脳内ルールを作ってないか？
17:NAME IS NULL
10/05/07 12:14:53
つまりそれは回りまわって>>12に帰結するわけだな（涙
18:NAME IS NULL
10/05/07 20:15:10
有効期限があるポイントを管理しなきゃならんのだわ。
やっぱり1ポイント1レコードかしら？
それとも「何月何日に100ポイント取得」「何月何日に30ポイント消費」みたいな、
ログ記録かしら。
教えてちょんまげ。
19:NAME IS NULL
10/05/07 21:11:50
直したのかよ
有給ないやつにも分かるように直したのかよ
20:NAME IS NULL
10/05/08 06:31:21
>>16
有給は半年前倒しで全社員一斉に与えても
いいんだよ。でなければ、入社日から計算。
入社半年で、0.5年度。一年半で1.5年度。
年度は入社何年目かって事でしょ。西暦
じゃないよ。この年度単位でないと、
繰越計算しにくいと思う。だから、年度に
与えた日数と消化した日数持たせていい。
>>15
なんかいまいちその利点がイメージできない。消化日数を持たせた時点で、集計
してrowをその都度更新していくのは
当たり前だし。それに、本当にsumなんか
で繰越の計算できんの？
21:13
10/05/10 11:33:11
実際に消化した実績日数だけで良いシステムなら、同一テーブルでもいいけど、
大抵は、事前に申請が必要だし、その申請こみで今現在の残日数を求める必要が
あったりする。つまり、大抵は（案２）みたいなテーブルが必要になるだろうってこと。
22:NAME IS NULL
10/05/17 23:44:56
そういえば最近は時間単位で年休取得できる会社もあるよな。
23:NAME IS NULL
10/05/18 00:21:58
時間単位はややこしい。日単位なら
その日の勤怠区分で処理できるのに。
例えば、10時出勤でも遅刻でないとか、
しかし、そのその日の勤務時間は一時間
マイナスで、有給で一時間補充とか、考えるだけで鬱になる
24:NAME IS NULL
10/06/15 00:30:24
簡単相互リンク集みたいなのを作ってまして
初めてDBをまともに使うのですが、こんな設計で問題ないでしょうか?
仕組みとしては、
・ひとつのUserIDに複数のサイトを登録可能
・申請が承認されると表示される
・相手にはUserIDは秘匿。
UserTable
---------------------
UserID | Mail | Password | 自分のSiteIDs | 承認待ち | 申請中
---------------------
u2145 | test@gmail.com | 1234 | s3265,s2664, | s3526(相手) to s3265(自分), | s3265(自分) to s4377(相手)
SiteTable
---------------------
SiteID | UserID | URL | Title | ビットフラグ | ジャンル | 紹介文 | リンクしているSiteIDs
---------------------
s3265 | u2145 | URLﾘﾝｸ(google.com) | Google | 未認証,リンク切れ,etc | 検索/リンク集 | 検索サイトです。 | s6325,s2355,s2362,s2355,
(未認証は、本人のサイトか未確認の意味。仮登録後、数時間未認証の場合テーブルから削除します。別のテーブル作ったほうがいいのかな)
リンク集生成時にURLとタイトルを取得する為に複数のSiteIDを問い合わせるので、心配なのですが
普段はHTMLファイルを生成して追加/削除するときにHTMLファイルを更新する感じにすれば問題ないでしょうか?
アドバイスよろしくお願いします。
25:NAME IS NULL
10/06/15 01:58:11
>>24
ユーザー毎にテーブル作った方がいい
26:NAME IS NULL
10/06/15 06:01:44
to に笑った
27:NAME IS NULL
10/06/15 06:15:29
「s3265,s2664」とかなってるのはカラムの中にカンマ区切りにするって意味？
そんなんDB使う意味ないぞ。テキストデータで持ってた方がマシなレベル。
それに静的データ（マスタ）と動的ステータスは完全に分けた方がいいがごっちゃになってる
それと未認証とリンク切れとか意味が全く違うものを一緒にしちゃいかん。
>>25
ユーザが増えたらcreate table発行か？ありえん。
28:24
10/06/15 06:42:19
レスありがとうこざいます。
>>27
カンマ区切りでした。。SQL側でひとつのカラムに複数の値を管理できるのでしょうか?
よければヒントの検索ワード教えてもらえませんかTT
(カラムにレヒードを追加できるのでしょうか!?)
ビットフラグでカラム減らそうとしてました。
素直にtrue/falseでそれぞれカラムあったほうがいいんでしょうか?
静的と動的はこの場合、頻繁に書き換わるSiteIDが動的?ですかね
UserTableの申請中などの情報は新しいテーブルに作ってみます。
29:NAME IS NULL
10/06/15 07:01:33
＞カラムに複数の値を管理
配列を入れられるDBもあるけど検索に使いづらくなるのでまずやらない。
そういう場合、RDBは複数レコードで管理する。もちろん行数は多くなるが管理や検索速度のバランスだからしゃーない。
んで、テーブルだが、ちょっと要件いまいちわかってなくて考察適当だがこんな感じだと思うぞ。
UserMasterTable (UserID(PK)|Mail|Password)
SiteMasterTable (SiteID(PK)|サイトのUserID|URL|ジャンル|紹介文|リンク切れフラグ|未認証フラグ)
SiteLinkStatusTable (リンク元SiteID(PK)|リンク先SiteID(PK)|ステータス(未承認/承認済/削除)|更新日時)
SiteLinkStatusTableは申請時１レコード、承認されて相互リンクになると２レコードになる。
未認証→認証を行うのは管理者でいいの？
30:NAME IS NULL
10/06/15 07:19:50
>>29
すごく具体的ありがとうこざいます> <
なるほど、こんなテーブルになるのですか!
素人考えで一つのテーブルに纏めすぎてたんですね ; ;
認証は管理者ですね。リンク切れは定期的に確認する感じです。
ちょっと私には複雑すぎてSQL質疑応答スレで聞くことになると思いますが
とりあえず寝てから作成してみます。
31:NAME IS NULL
10/06/15 16:32:38
未認証とリンク切れは一緒でいいんじゃまいか
認証されてなければリンク切れとは判定しないだろうし
0 = 正常 / 1 = 未認証 / 2 = リンク切れ
とでもすれば
32:NAME IS NULL
10/06/15 17:42:05
まあ、なんにせよ要件次第ではあるが
>>29
>仮登録後、数時間未認証の場合テーブルから削除します
なので、サイトマスターに最低限、申請（仮登録）日時いるだろうな
そうなると本登録日とか、ほかにも項目ほしくなるだろうけど
>>31
・未認証で承認しようとしたらリンクが切れてました
・承認してたんだけど、ある日リンクが切れました
の二つを区別して記録したいなら分けておかないとだめじゃね
もしくは別途サイト登録履歴みたいなテーブルもたせるか
33:24
10/06/15 18:22:47
皆様ありがとうこざいます
作ろうとしてるのは、ユーザーのサイトにphpファイル(名前と設置場所固定)を設置させて被リンク効果を出す感じなのですが
phpファイル自体は、
$SiteID = 235455;
$fp = fopen("URLﾘﾝｸ(www.mydomain.com)", "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タイムスタンプを使おうかと思ってます。
34:NAME IS NULL
10/06/15 19:08:29
UNIXタイムスタンプはダメだ
DATETIME型でカラム作った方がいいぞ
35:NAME IS NULL
10/06/15 20:37:55 NSd5kCf1
在庫調査のDBを作ろうとしてるのですが、
差分データのようにしないとデータ多すぎて一ヶ月もしないうちに大変な事になってしまいそうです。
エリア、店名、商品名、価格、個数、調査時間
最低限保持しないといけないのが上記項目で
同じ店でも同じ商品名でも陳列が別なら別登録になります。（ヤフオクで同じ商品が同じ価格でずらっと並んでるような）
調査1回につき、20～30エリア、1～100店、商品1～100点、個数1～100程度になるので単純にDBに登録すると1回で最大時30万行になってしまいます。
これを3時間ごとに調査となると、1ヶ月で数千万行になってしまって現実的ではありません。
なので調査ごとの変化は1割にも満たないので差分の登録の仕方や利用の仕方を勉強したいのですが、
そのような設計例の載ってる本やサイトをご存知ないでしょうか？
36:NAME IS NULL
10/06/15 21:05:10
差分ってか
ようは在庫変動のトランザクションを持ってりゃいいだけの
話のように思うが
37:NAME IS NULL
10/06/15 21:52:45 NSd5kCf1
すいませんもう少し詳しく教えていただけませんか？
単に今の在庫がわかればいいってわけではなくて、
調査日のその時間にどこにどんな値段で在庫がいくらかあったか、店自体開いてたか開いてなかったかなどの
そのままの情報を保持したいので、
在庫変動したら値を変えるだけってわけではないのですが、そういう意味でもしおっしゃられていたのならすみません。
38:NAME IS NULL
10/06/15 22:16:17
もし本当にそのままの情報を保持する必要があるなら
30万件だろうがそのまま持っとくほうがいいだろう
ただし、それを保存している間に在庫が動く可能性があるから
その瞬間の在庫という一貫性は保てないぞ
ただし、たとえば保存期間を三日とかにしておく等の制限をつける
三時間おきのデータを数年も保持しとかないといけないとかいうなら
要件を見直すべきかと
39:NAME IS NULL
10/06/15 22:32:03
取ったデータで何をするかじゃないかな。
例えばWeb画面でセミリアルタイムで変動をグラフで見せたい（計算させたい）のだったら１クリック５時間のクソアプリになるが、
月に１回バッチで在庫変動情報の帳票を作りたいだけなら全部突っ込んで１億レコードになっても何ら問題ない。
40:NAME IS NULL
10/06/15 22:35:20
>>33
てか「（申請に添える）メッセージ」が「（サイト間の）リンク申請情報」を持ってるっておかしくなってるじゃん。
41:24
10/06/15 23:25:43
>>40
おかしいですか?
SiteLinkStatusTableにメッセージを置くのもおかしいので
MessageBoxTableにリンク申請情報を持たせてしまえば楽かなぁと
(メッセージ消したらリンク拒否みたいに)
42:NAME IS NULL
10/06/16 01:34:09
UserID MEDIUMINT NOT NULL AUTO_INCREMENT
SiteID MEDIUMINT NOT NULL AUTO_INCREMENT
43:NAME IS NULL
10/06/16 10:58:42 1LUS1Pf+
>>38
要件見直すことにします。
>>39
そのクソアプリに近い感じなのでリアルタイムなものと、日間月間変動情報なものとわけて考えて見ます。
44:NAME IS NULL
10/06/18 18:45:41
これ見てよ↓
URLﾘﾝｸ(livedoor.blogimg.jp)
ばらまこうぜ！
45:NAME IS NULL
10/06/26 08:48:25 HzXxnfag
最近DBの勉強をし始めたのですが
通し番号 社員ID 社員名 製品ID 製品名 登録日時
のような列があった場合、通し番号 社員ID 製品ID 登録日時のテーブルと他2つに正規化できますが、
検索するときに必ず名を利用する場合（社員名、製品名、登録日時を取り出すのがメインの利用方法）、
サブクエリが増える分検索が遅くなると思うのですが
こういった場合でもテーブルって分けるべきなんでしょうか？
社員ID、製品IDを利用する事はほとんどありません。
正規化するとDB容量は節約できますが、利用時の負荷が増大するのでデメリットに感じます。
それともサブクエリ増えてたとしても、列が少なくDB容量が小さくなるようにした方が速くなるでしょうか？
46:NAME IS NULL
10/06/26 09:23:29 Y5TEab6Q
やってみないと判らないと言われればそれまでだけど、
そんなに心配しないとイケないほど検索が遅くなる？負荷が増える？
47:NAME IS NULL
10/06/26 09:52:42
初心者なら型通りにやれ。
パフォーマンスを気にするなら、テーブル設計に手を入れるのはSQLチューニングで
改善の余地があるかどうか自分で判断できるようになってからだ。
48:NAME IS NULL
10/06/26 10:06:21
>>45
パフォーマンスのための非正規化なんてのは最後の最後の最後の手段。
社員数が1000万～1億人もいるならそれもありかもなー、なレベル。
考えるのがムダとはいわないが、悩むのはムダ。
49:NAME IS NULL
10/06/26 10:12:29 HzXxnfag
最終手段なんですね・・・
まずは基本どおりの設計を覚えて経験していくことにします。ありがとうございました。
50:NAME IS NULL
10/07/02 08:29:18
>>48
プロフを参照したところこの方、銀歯を作る仕事（ﾌﾟｯ）をなさっていたそうで（苦笑）
道理で、物作りの厳しさ、商売の難しさどれを取っても何一つ理解しておらず、突っ込み所満載なわけです
しかも過去形である所を見ると景気に関係なく黙ってても患者が来る、
病気や虫歯を直す商売でさえ勤まらなかったということでは（笑）
銀歯と金型では要求される精度も品質もまるで違います
質問者が何を作りたいのかが明らかにされていないため分かりませんが
趣味のようなもの、とおっしゃるなら趣味の掲示板で相談されたらいかがでしょうか
その分野の同好の士が良い方法をご存じかもしれませんから
もちろん、趣味の世界といえども技術は只で教えてもらえるほど甘い物じゃないという事をお忘れなく
51:NAME IS NULL
10/07/02 12:07:01
どこの誤爆？妙に番号だけあってて笑える。
52:NAME IS NULL
10/07/03 11:43:06 magiIcce
enumを使うか、マスタ化するかについて。
URLﾘﾝｸ(www.developer0000.jp)
URLﾘﾝｸ(blogs.wankuma.com)
全部をマスタ化すると無駄な感じがするのは確かだけど、
表示順や表示名、ロジック分岐フラグなどのパラメータをもてる。
マスタ化しておくことでアプリ内のswitch文を減らすことができる場合
も多々あるので、基本的にはマスタ化が好きなんだけどどう思う？
53:NAME IS NULL
10/07/08 04:33:44 mgDV/kGB
英語⇔日本語
みたいな対応表を作る時のようにどちらも主キーになるような場合は
どちらかを主キーにしてもう片方もインデックスする感じになるんでしょうか？
54:NAME IS NULL
10/07/08 05:47:39
別の連番のキーをつけた方がいいんじゃない？
55:NAME IS NULL
10/07/08 16:50:07 mgDV/kGB
>>54
ＩＤ 日本語 英語で全部ユニークインデックスってことですか？
ＩＤは使う予定ないのですが将来に備えてということでしょうか。
56:NAME IS NULL
10/07/08 17:37:37
日本語と英語はユニークである必要無いんじゃない？
確実に1対1なの？
57:NAME IS NULL
10/07/08 18:05:55 mgDV/kGB
>>56
確実に１対１です。かぶることはありません。
商品名の日本語⇔英語⇔中国語⇔ドイツ語とあるとして
日本語から英語、ドイツ語から中国語みたいに検索したいんです。
58:NAME IS NULL
10/07/08 18:36:57
かぶらないって空欄も無いってことか
でも連番のidあったほうがいい気がするなあ
検索対象の項目はそれぞれインデックス作ればいいし
59:NAME IS NULL
10/07/08 19:50:03
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'
60:NAME IS NULL
10/07/08 19:57:54
商品名の対訳表なら、商品の主キー＋言語コードで主キーにするな、俺なら
61:NAME IS NULL
10/07/08 20:48:47 mgDV/kGB
>>59 >>60
なるほど。これなら言語増えても列増やさなくて済むんですね。
こういうの自己結合って言うんですね。
自己結合って知らなかったので調べてみます。
いま全く知らない状態だと select Message, Language from Locale where LocaleID = 3
の方が速いんじゃないの？とか
行数増えると結合してるから遅くなるんじゃないの？とか思ってたりします。
62:NAME IS NULL
10/07/08 21:24:44
自己結合知らんような初心者がパフォーマンス考えるとかムダだから
63:NAME IS NULL
10/07/08 23:34:03 mgDV/kGB
>>62
はい。ベテランの方々が提示したものが初心者の私が考えるより確実にいい設計だと思うので、
そのまま使おうと思います。
64:NAME IS NULL
10/07/09 00:55:58
create table locale (
localeid int,
jpn nvarchar(100),
eng nvarchar(100),
doitu nvarchar(100),
china nvarchar(100)
)
65:NAME IS NULL
10/07/09 01:07:19
↑
メンテしやすい
66:NAME IS NULL
10/07/09 01:15:13
それはないわ
67:NAME IS NULL
10/07/09 01:27:27
俺はその形大好きだがｗ
68:NAME IS NULL
10/07/09 01:38:57
>>66
なんでないと思うのかな。必ず全部の言語のデータを一対一で作るという前提なら、ありだろ。
69:NAME IS NULL
10/07/09 03:42:13
だってdoituだよ？
70:NAME IS NULL
10/07/09 11:37:32
>>66
将来にわたって言語の追加変更削除がないことが担保されるならありだと思うが
71:NAME IS NULL
10/07/10 00:23:34
add columnしとけ。
72:名無しさん＠そうだ選挙に行こう
10/07/10 10:24:04
>>64
要件変更時に悲惨なことになりそうな予感しかしない。
73:名無しさん＠そうだ選挙に行こう
10/07/11 10:24:03
chinaだけちゃんとしたフルネーム
74:名無しさん＠そうだ選挙に行こう
10/07/11 10:25:47
あ、フルネームって前に付くあれは無しで
75:NAME IS NULL
10/07/12 22:21:49
ごく基本的なテーブル設計の話なんですが。
例えば「プレイヤーは複数の村を所持、村は複数の家を所持する」場合って
こういうのが↓依存リレーションで
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せず。
76:NAME IS NULL
10/07/12 22:27:59
実際に両方で作ってみたらいいじゃん。
どっちもhouse_name village_nameを何度も書くはめになることに気づくよ。
それでもいいんだ！っていうなら1テーブルで作っちゃえばいいと思う。
「いちいち」player village houseを分ける必要ないでしょ。
77:75
10/07/12 22:29:29
あ、各テーブルの関係は1:Nです。情報後出しで申し訳ない。
あと設計のケースとして一個忘れてた、
player, player_villege, villege, villege_house, house と作るケース。
なんて呼ぶのかわかりませんが。
一応自分の考えを書いておくと、
1:Nで、それこそ子の存在が親の存在に依存する場合は依存リレーション、そうでなきゃ非依存
ってだけの話かと考えているのですが。古いとかじゃなくて。
↑に追加で書いたのは、N:Nのときに使う、と。
（逆に言うと1:Nのときに使うメリットは特に無いと思う）
78:NAME IS NULL
10/07/12 22:32:53
ごめん見落としていた。
>>75の後者って、一つの村は一つのユーザしか所有できないという制限になると思うけど
それはそういう仕様？
ならそれでもいい。
前者は正規化すべき対象がある(かつ、それが煩雑になりすぎない)のに
やらないというところが20年前なんじゃないかな。
79:75
10/07/12 22:45:14
>>78
そこは（遅れましたが）1:Nなので仕様です。
前者のほうが、「家IDから所有プレイヤーを逆引きするのが楽」だとか、
「親が存在しないのに子が存在しうる」といったデメリットがありますが
それでも後者にすべき？
今挙げた二つのデメリットは、最悪冗長なカラムを持つとか、
制約をしっかり設定すればいい話だけど…
パフォーマンスとしては前者の方がいいような気がするのですが。
…いや、それこそ両方組んで実データぶっこんでテストしなきゃわからないか。
結局どちらが是かは要件次第、なのかなぁ。
80:NAME IS NULL
10/07/12 23:07:09
1:Nなら前者にする必要がないんじゃ？
> villageテーブル：primary(player_id, villege_no), village_name, ...
に、unique(village_no)をつけて1:Nであるとアピールしてもいいけど。
「親が存在しないのに子が存在しうる」
これを避けたいなら外部キー制約でいけると思う。
パフォーマンスはこの情報だけだと環境によるとしかいえないかと。
あと、誰も所有していない村や家はどうなるの？
81:75
10/07/12 23:25:03
あれ、俺疲れてんのかな…
よく考えたら子があるのに親がないリスクは前者も後者も同じですよね。
とにかくこれは制約でどうにでもなると。
誰も所有してない村や家は存在してはいけないので削除…いや、
件数がかなり多い（数千万レベル）のでdelete_flag式にするから制約できないや。
そこはPGの責任でしっかり組むことにします。
やっぱり前者に拘る理由は「逆引きが楽」くらい？
indexによる検索性能…も正しくIndex作れば同じ？か？
だんだん「そもそも依存リレーションの存在価値って何」って考えになってきた。
ちなみに質問では親ー子ー孫の３層にしましたが実装は４層。
前者にするとキー長が長くなって検索にはむしろ不利なのか？
82:NAME IS NULL
10/07/12 23:35:48
後者は外部キー制約あるんだから、家があるなら村はあるはずだし、
村があるならプレイヤーはいるはずになっているよ。
キーが長くなるというか、インデックスが肥大化するんでないかね。
そのへん詳しくないけど。
依存リレーションという言葉も知らなくてなんだかごめん。
83:NAME IS NULL
10/07/12 23:42:05
で、今依存、非依存について調べたわけですが、
前者は存在しないplayer_idをvillageに登録できるし、
villageがなくともplayerを登録できるので、互いに非依存
後者は>>82で書いたように、playerがいなければvillageに
登録できないが、villageがなくともplayerは登録できるため、
villageはplayerに依存し、playerはvillageに非依存である
ということなんじゃないのかなーと。
84:NAME IS NULL
10/07/13 00:03:57
PG的には村や家に確実にユニークなIDが振られてる方が楽だと思うが。逆引きするにしても。
「前者のvillege_noやhouse_noも実はユニークなんです(ｷﾘｯ」なら糞設計と呼ばれても仕方ないと思うけど。
85:NAME IS NULL
10/07/13 00:16:17
どう考えても後者の設計だな。前者のが古いかどうかは知らないが、親子関係が変更になった時に主キーに触らないといけないのが気持ち悪い。
86:75
10/07/13 00:47:25
うーむ…。よし、ここは経験と思って、後者で実装することにします。
すでに前者で組んでる最中の、取り返しが付かない段階のシステムがあるので、
違いを肌で感じることにします。
ありがとう御座いました。肌で感じたあとブログにでもまとめようと思います。
87:NAME IS NULL
10/07/13 00:52:30
てかもっと新しい（？）というか安全なのは、「プレイヤー-村」関連テーブルと「村-家」関連テーブルを別途作ることじゃないかね。
88:75
10/07/13 00:58:41
>>87
それが>>77で追加したやつのことなんですけど、
N:Nならそうせざるを得ないとして、
1:Nでもそこまでします？
その形にすると、子要素１件の増減につき必ず２テーブル触らないといけないので
パフォーマンスが気になります。
1:Nなので、「プレイヤー村」関連テーブルと「村」テーブルの
件数って完全一致で、「なんのために２テーブルに別れてんだ？」って考えてしまうのですが。
89:NAME IS NULL
10/07/13 01:16:13
その程度でパフォーマンスが気になるほど更新が頻繁なのか？
90:75
10/07/13 01:30:31
更新はそれなりに頻繁、件数が億単位を想定。
パフォーマンスのために多少の開発効率を落とすのも辞さないレベル。
91:NAME IS NULL
10/07/13 01:34:22
んな条件を後出しすんじゃねぇよｗｗｗ
億単位レコードのテーブルは非正規化されてる方が普通なくらいだろｗ
92:75
10/07/13 01:41:34
で、ですよね。すいません。
それを先に出すべきとか言うところに頭がピンと来ない人間が
億単位システムのDB設計をしているという…。
93:NAME IS NULL
10/07/13 01:43:50
ていうかそれ何のDB？
94:75
10/07/13 01:53:46
MySQLです。
まぁ最初はよほど負荷が見えてるところ意外は基本的に正規形で考えて
後から発覚した負荷について非正規形にする感じで考えてる。
95:NAME IS NULL
10/07/13 02:29:42
それがもしモバゲとかグリーとかブラゲならDB以外にも抑えておかないといけない点がいくつかあるんだけど
その辺は大丈夫なのかね。
96:75
10/07/13 02:37:20
そのへんは肯定も否定もしないでおくけど
memcache使うとか基幹システムAPIは極力叩かないとかは抑えてるつもり。
まぁスレ違いにもなって申し訳ないのであくまでDB設計の話を、と。
ご忠告感謝。
97:NAME IS NULL
10/07/13 02:46:23
そっか。それなら、だいじょうぶかな。DBも分散を検討してね。
うまく行くことを願っているよ。
98:75
10/07/13 03:59:17
MASTER、SLAVEの分散もありました、忘れてました。
あとコネクションを極力短く、少なくとか。状況次第じゃいったん切るとか。
で、報告までに。
「複合キー」とか「サロゲートキー」とかでググりまくったら、
「古い」なんて言われたのもぼんやりと納得できてきました。
階層構造に複合キーを使うなんてのは２秒で否定されるレベル、
といった感じが伝わってきました。
（それでも「必ずしも」ではない、ケースバイケースなんだろうけど）
取り返しがつく今のうちに修正に入ることにします…。
99:NAME IS NULL
10/07/13 10:25:55
今どき複合キーはないわ。
オブジェクト指向とかORM(Object Relational Mapping)とか考えるとサロゲートキー一択っしょ。
あと、１：Nなら関連テーブルは不要だね。
100:NAME IS NULL
10/07/13 11:55:11
俺なら前者にはしない。
なぜなら、playerが所有しない村も（今は無くとも）存在するだろう（かもしれない）し、家も同様。
また、所有者が変更になるとき、pkeyの更新になるのはいただけない。
101:NAME IS NULL
10/07/13 22:17:58
複合キーとサロゲートキーって、
具体的にどう違うの？
102:NAME IS NULL
10/07/13 23:08:29
サロゲートは完全なキーであるためだけのキー。
103:NAME IS NULL
10/07/14 13:04:15
>>102
単独か複合かは関係ないんですね？
ユニークと同じ意味と思っていい？
104:NAME IS NULL
10/07/14 13:13:29
>>103
何で調べないの？
Wikipediaでもある程度わかるのに。
URLﾘﾝｸ(ja.wikipedia.org)
105:NAME IS NULL
10/07/14 22:43:21
サロゲートキーは「本当はいらないはずだけど、どうしても作らなければいけない」
というイメージがあります。
ダミー列がprimary keyのような感じ。
106:NAME IS NULL
10/07/14 22:52:25
祇園精舎の鐘の声
諸行無常の響きあり
沙羅双樹の花の色
盛者必衰の理をあらわす
おごれる人も久しからず
ただ春の世の夢のごとし
たけき者も遂には滅びぬ
偏に風の前の塵に同じ
サロゲートキー、それは自然キーの否定。
107:NAME IS NULL
10/07/15 09:22:23
>>105
あんたの感想はわかった。それで？
108:NAME IS NULL
10/07/15 11:02:19
いやまぁ合ってるよ
業務要件上はいらないけど、システム要件上は必要なので
ダミー（ユニークネスを保証する以外に意味のない）列を追加するわけだから
109:NAME IS NULL
10/07/15 11:14:09
まーた始まった
110:NAME IS NULL
10/07/15 21:21:24
>>107
ごめんなさい。
111:NAME IS NULL
10/07/18 09:49:29
>>109
ん？まーた始まったって？
私は初めて書き込みますが、サロゲートキーは一つのデータベースで必要な部分と不必要な部分があります
必要な部分では必ず適用します
不要な部分では使用しません
何故必要な部分で使用するかというと使用しなかった時に大変困ったという経験則に基づくものです
不要な部分というのはデータベースごとで違うでしょうが、使用しなくても大して困らなかったという経験則に基づくものです
つまり必要無いと思う人は使わなければ良いし必要だと思う人は使えば良いだけじゃないでしょうか
112:NAME IS NULL
10/07/18 14:00:29
>>111
「必要なとき使う、不要なとき使わない、その基準は経験則」
そんな情報をネット上のフォーラムに残すことに何の意味がある？誰の参考になる？
どうせならその経験則を少しでも、ほんの一部でも噛み砕いて置いていってくれないか。
113:NAME IS NULL
10/07/18 14:31:12
>>111ではないが、RDB的なサロゲートキーってのはその名のとおり長大な
複合キーなど取り回しに難がある場合に代理として用いるものだろ。どのくらいで
「難がある」かはケースバイケース。
ただし、>>108の言うような「ユニークネスを保証する以外に意味のない」キー
というのは本来のサロゲートキーとは違って、OODBのIDのようなもの。
こいつらはデータモデルがそもそも違うんで、ごっちゃに議論すると発散する。
114:NAME IS NULL
10/07/18 15:17:40
顧客が決める気持ち悪いコードに対して
それと１対１になるように一見意味のなさそうなIDを振りなおすのがサロゲートキー。
（あとから仕様変更によって、１対１じゃなくなる可能性があるが）
単にテーブル設計の都合上の複合キーに対してIDを振りなおすのは
ちょっとわけが違うということか。
115:NAME IS NULL
10/07/18 15:58:36
いや、どっちかっつーとサロゲートキーというのは後者。
また、前者で1:1でなくなる仕様変更というのは、RDB的には「そんな仕様変更があったら
従属関係が変わってるからテーブル定義を変更せずに済むとは限らんだろ」となる。
これが有効なのは、OOあるいはER的に「オブジェクト/エンティティ境界はそれが持つ
属性やその関係よりも安定である」という前提でそのように設計した場合の話。
116:NAME IS NULL
10/07/18 17:20:37
サロゲートキーが必要／不必要で論じると、
複合キーを認めないという前提でないかぎり、すべて不必要だと思うが
ただ単に取り扱いが楽かどうかだけの問題以外に必要性があるなら教えてほしい
117:NAME IS NULL
10/08/07 07:48:37
ニコニコ動画とかのタグ付けって
ひとつのカラムに空白区切りとかで押しこむのが普通なんでしょうか?
118:NAME IS NULL
10/08/07 09:52:59
>>117
動画テーブルと、タグテーブルの間でN:Mの関連を構築すればいいんじゃないの？
119:NAME IS NULL
10/08/07 16:40:59
>>118
ありがとうございます
勉強してきます > <
120:NAME IS NULL
10/08/07 20:29:49
URLﾘﾝｸ(q.hatena.ne.jp)
仕事でやってるとこんな風に考えられるのか・・・
アマだとまったく思いつかない; ;
121:NAME IS NULL
10/08/07 22:56:44
実際の仕事ではpopular_tagsとtagsテーブルは合算されるよ
なるべくテーブル数は減らして結合処理のボトルネックを減らした方が後々いいからね
122:NAME IS NULL
10/08/08 16:59:01
減らす為にpopular_tagsを作ってるんじゃ。。
123:NAME IS NULL
10/08/09 00:27:37
え？
124:NAME IS NULL
10/08/09 12:04:21
数学
125:NAME IS NULL
10/08/09 22:23:38
>>121
>なるべくテーブル数は減らして結合処理のボトルネックを減らした方が後々いいからね
やめてくれ
126:NAME IS NULL
10/08/09 22:36:39
初心者は結合すると遅くなると本気で信じてる奴いるからな。
127:NAME IS NULL
10/08/10 02:41:55
ド素人が第三正規化にこだわるのをよく見るな
128:NAME IS NULL
10/08/10 11:17:30
> 結合処理のボトルネック
SQL書けない馬鹿の言い訳
129:NAME IS NULL
10/08/10 12:42:16
あるあるｗ
130:NAME IS NULL
10/08/10 13:30:12
>>120
相変わらずhatenaはレベルの低い回答が多いな
131:NAME IS NULL
10/08/10 14:07:34
SQL書けない人にJOINさせると開発工数のボトルネックになる(笑)
132:NAME IS NULL
10/08/10 15:46:06
>>120をよく読まずに>>121が反応してるので話がかみ合ってないだけじゃね？
popular_tagsはタグの種類じゃなくて集計用のテーブル。
目的は精度や時系列の一貫性を求められないが頻繁に参照されるデータの取り扱いのためであって、
正規化やそれを崩した場合のＪＯＩＮのパフォーマンス云々は関係ない。
133:NAME IS NULL
10/08/10 18:31:51
集計のためのカウントアップの前にjoinする必要がある
結果を表示する時もjoinする必要がある
結論：無駄
おｋ？
134:NAME IS NULL
10/08/10 19:00:09
>>133
だからさ、どういう仕組みのシステムを想定してるかで変わってくるのだから、
その辺を明確にしないと話がかみ合わない。
それぞれ違うものを想定して結論だけをあーだこーだ言っても仕方ないだろ。
135:NAME IS NULL
10/08/10 19:22:10
あのさ、普通に考えてみなよ
カウントアップの時はユーザがタグを入力した時
そのタグ名を判定しつつカウントアップしないといけない
つまりjoinまたは過剰なクエリ発行を伴う
結果表示も同じ
タグ名無しで表示される事何てまずない
システムによっても糞もないだろ
id指定でカウントアップする事例ってあるのか？
id表示させて満足させる集計表示ってあるのか？
まともなシステムならねぇだろ
たのむから億単位のレコードを扱ってから物申してくれ
こんな設計をする奴は経験が浅い
136:NAME IS NULL
10/08/10 19:28:19
>>135
じゃ一つシナリオを挙げよう。
popular_tagsテーブルはいらない。tagsをgroup byすれば済む。
ただこれを人気タグの一覧を表示するごとにクエリするとコストが高い。
それで１０分おき位にgroup byのクエリを行い、popular_tagsテーブルにキャッシュしておく。
場合によってはRDBではなくアプリケーションサーバー内のメモリにキャッシュしてても良い。
137:NAME IS NULL
10/08/10 22:25:31
>>121
>実際の仕事ではpopular_tagsとtagsテーブルは合算されるよ
合算って何？
138:NAME IS NULL
10/08/11 00:04:59
>>135
ずれてない？
139:NAME IS NULL
10/08/12 16:56:53
所与の条件は、タグは自由入力形式で１つのコンテンツに対して複数付けられるってことだよね。
人気タグに関しては検索数（参照数）が多いのか、付けた数が多いのか明確にされていない。
また集計期間を設けるかどうかやその期間についても明らかにされていない。
検索数の場合はカウントアップが必要になるかもしれないが、
付加数ならば>>136の方法が妥当じゃないかな。
>>135の想定しているものがいまいち分からないが、
それぞれのテーブルが１：１：１でとか考えていて、
タグ名と参照数をわざわざ３テーブルに分けるのは無駄だとか考えているのだろうか。
>>136のはコンテンツとタグが１：ｎ、人気タグテーブルが独立して存在という考え方だろう。
140:NAME IS NULL
10/10/14 02:48:47 etNKxQCa
>>127
第三正規化が正確に出来てから言え！！
まずこだわることが大事だぞ。
141:NAME IS NULL
10/10/14 10:25:29
>>127のはできないやつのいいわけだからｗ
142:NAME IS NULL
10/10/14 10:45:55
121みたいな何も知らない馬鹿はおいておいて、人気タグのようなケースはデータ構造というよりアプリ依存の話だから、ごっちゃに話すと混乱するでしょ。
データ構造の話でいえば、ちゃんと正規化して最適化されたデータ構造が保持できていれば、人気タグのような集計系によるJOINも問題なし。
いまどきの商用（とほぼ同等品も含む）RDBMSならストアドにすれば高コストと言ってもたかが知れてる。（タグが毎秒何千とかで追加変更されているとかじゃない限りｗ）
当然、適正に正規化できているデータ構造に冗長なテーブルは存在しない（まぁ、それは理想だがｗ）。
アプリの話で言えば、WEBアプリのネックはページ生成と通信部分だから、サーバサイドのデータ処理よりこちらのほうが普通はデメリットになる。
なので、人気タグやそのとび先をあらかじめ一定時間毎に静的ページ（厳密には静的ページではなくてもそれと同等の負荷のものも含む）を作成するような場合もある。
検索でインデックスと展開先をあらかじめ作っておくパターン。このような場合は、そのページ生成のためのデータをどこかに当然吐き出すわけだが、
それがテーブルなのかHTMLのようなファイルなのか、とにかく出力先の違いだけ。
hatenaの回答者はそれを一緒くたに回答しているので話がややこしくなってる。
143:NAME IS NULL
10/10/14 14:33:13
ﾅﾝｶﾜﾛﾀｗ
どんだけ一人の書き込みを気にしてんだよｗ
144:NAME IS NULL
10/10/14 17:27:43
一人の書き込みに食いつかざるを得ないほど、ネタがないｗ
145:NAME IS NULL
10/10/14 20:57:41
アクセスコストがストアドで解決できるとかw
146:NAME IS NULL
10/10/15 00:14:44
>>121は、元コボラーだな。
元コボラーが設計したテーブル設計って酷いのが多いんだわ。
147:NAME IS NULL
10/10/15 07:39:41
>>145
アクセスコストの話は下段だろjk
148:NAME IS NULL
10/10/15 09:10:34
121の人気に嫉妬ｗ
たぶん合ってるから人気なんだろうなｗ
149:NAME IS NULL
10/10/15 10:19:56
2ヶ月も前の話題を引っ張るなよ。それにしても>>121大人気だな。
150:NAME IS NULL
10/10/15 11:14:08
いまどき一般的な規模のRDBでテーブルの結合がボトルネックになる、なんて書いたらそりゃ人気も出るw
151:NAME IS NULL
10/10/15 21:55:23
>>147
下段って？>>142本人なら解説ｷﾎﾞﾝ
152:NAME IS NULL
10/10/25 20:01:40
>>146
元コボラーには有償研修のSQL入門程度は行かせた方が良い。
わずかな投資で使いものにならなかった人材が使えるように
なったらもうけもの。
汎用機ではこうだったからだ、、、
と仕事を妨害することも少なくなれば一石二鳥。
153:NAME IS NULL
10/10/25 21:56:18 G/Enqt3S
COBOLにOCCURS項目があるといのがCOBOLとSQLの相性が悪いところなんでしょうかね… w
それだけではないでしょうけど
154:NAME IS NULL
10/10/25 23:29:57
SQLというより、テーブル定義の問題だがな
COBOLのようなISAM編成に向いたテーブル定義と
RDBを前提としたテーブル定義は違うってことだ
155:NAME IS NULL
10/10/26 22:28:35 BB4To3r1
ある製品を作る時に使用する部品をDB化したい。
[条件]
1つの製品を作る際に使用する部品の種類は、1個～20個以内。
データの出力時には、固定列数なフォーマットにする。
--
こういう場合も正規化ってする？
クロス集計でしか利用されないデータを正規化するのってすごい非効率な気がするんだがどうなんだろう。
[非正規化]
作成No,製品名,部品1個数1,単価1,部品2,個数2,単価2～部品19,個数19,単価19,部品20,個数20,単価20,合計,作成日,コメント
[正規化]
作成No,製品名,合計,作成日,コメント
部品No,作成No,部品,個数,単価
156:NAME IS NULL
10/10/27 00:55:32
>>155
将来、部品点数が絶対に増えないといえるのなら、
非正規化でもいいかもね。
将来、部品点数が増えたり、階層化する可能性があるなら、
正規化しといたほうが、後々潰しが効くと思う。
157:155
10/10/27 11:38:52
>>156
どうもです。
階層化は考慮外ですが、部品点数が増える事に対しても非正規化の方が
工数的(作成時、実行時ともに)に有利だと思うんだけどなー。
テーブルを修正しなくても良いという点では正規化が優れているが、
それほど加点でもなく、マイナス点の方が多く思える。
Gridに表示させたり、CSVなどで出力したりで毎回毎回別途に集計しなければならないのは面倒くさい。
制限チェックも増えるし、取りだしが必ず2度以上になってしまうからレスポンス的にもだいぶ不利だし…。
皆さんどうしているんだろうか。そういう欠点よりも将来の拡張性の為に正規化をしているのかな。
悩む…。
非正規化はテーブルの見た目がださい所も気になる。
158:NAME IS NULL
10/10/27 12:22:13
>>155
非正規化の場合、部品のステータスに修正入ったら一括変更でもするつもりか？
データ構造が変わらない（商品を構成する部品の点数や構成が将来的に変わらない）としても、表示するフロントエンド（アプリ）は色々変わったり、
他の場所で使われることがあるから、素直に正規化しておけ。
非正規化されたデータをもとに他の人間がフロントエンド作るのは非常に面倒くさい。
その程度のクロス集計のコストが高くなるというのは、そもそもの設計か実行時のSQLに問題があるだけ。
159:NAME IS NULL
10/10/27 19:46:30
>>157
＞非正規化はテーブルの見た目がださい所も気になる。
開発者の感覚としては、これにつきる。
その程度のテーブルなら、どんな構成
でも実行速度は変わらんだろ。
捨てコードでもいいから突貫で、と
いうのでなければ、個人的に非正規は
ありえない。
160:158
10/10/27 19:54:11
>>157
非難だけしてもなんなので、現実的な方法を。
仮に出力の（クロス集計の）コストが高いというのが問題であるならば、部品構成の変更などが頻繁でない限りは（今回のケースはそうだと思うが）、
部品の変更や修正、追加をトリガーに出力用のデータをテーブルなりファイルなりに吐き出しておけばよい。
最終形でなくても、計算途中のデータを出力しておけば実行速度の問題はなくなるはず。
大手のデジカメの階層化されたPDMで実際にやってる。
161:NAME IS NULL
10/10/27 23:29:07
なんでこうJOIN一発するだけでレスポンスが"だいぶ"悪くなると思う奴がDB設計とかやってるんだろう。
162:NAME IS NULL
10/10/28 00:44:53
つかこれ、かならず部品１～２０までを固定で取り扱うというなら
横に１～２０まで並べても非正規化だとはいえない気がする．．．．
が、俺なら絶対実テーブルを部品１～２０まで繰り返したりしない
部品点数が増えたときに非正規化が工数的に有利だと思う考えが理解できん
毎回別途に集計するのがめんどくさいというのも、いまいち理解できん
ビュー使えよ。最近のＤＢＭＳなら>160の言うようなワークテーブル的に
使える実体付きビューを使えるものもあるんだぜ
163:NAME IS NULL
10/10/28 12:46:48 2nX/Ozle
テーブル名を日本語で作るのは駄目かな？
164:NAME IS NULL
10/10/28 20:12:37
出来るけどやめておけと言われるはず。
日本語が入力出来ない状態でメンテナンスするってなった場合、手段が減る。
特別な理由がない限りASCII文字で作って老いた方が無難。
165:NAME IS NULL
10/10/28 20:23:31
どっかで、日本語を推奨してる人を見たことがある。
今はO/Rマッパーやらツールやらがいろいろあり、
テーブル名や項目名を直接タイプすることが少なくなったから、
（日本人しか使わないなら）直感的な日本語のほうがいいとか言ってた。
わりと賛同できるのだが、やっぱ怖いもんは怖いよなぁ。
こんなことで変なリスク抱えたくないわ。
166:NAME IS NULL
10/10/28 21:34:07
>>165
>O/Rマッパーやらツールやらがいろいろあり
色々あるから、むしろ TBL0002345 みたいなテーブル名でも最終的にはさほど困らないと思うんだが。
テーブル名や項目名が直感的に把握できる必要があるものに関してはVIEWなりストアドで作ればいい。
167:NAME IS NULL
10/10/28 23:42:40
>>165
全く賛同できないんだが。
ていうか、何を言ってるんだ？って感じだ。
そんな奴が近くに居たら、ぶちのめしてやりたい。
168:NAME IS NULL
10/10/29 07:29:40
>>167
論理的な意見が聞きたい
169:NAME IS NULL
10/10/29 10:18:23
>>168
>>164の
＞日本語が入力出来ない状態でメンテナンスするってなった場合、手段が減る。
これとか
charset問題とかだろ
170:167
10/10/29 22:55:31
>>168
OSやらDBやらアプリやらで、文字コードを統一しないと怖くて使えない。
プログラムを組んでいる最中に、いちいち全角入力モードに変える必要がある。
（絶対に、全角スペースをコードに記述してしまってコンパイルエラーとなる頻度が多くなる）
半角と全角の区別がつき難い。
（例えば、"1"と"１"はパッと見解らない。）
あと、O/Rマッパーやらツールやらを使うことが出来ない場合のことを考えろ。
171:NAME IS NULL
10/10/30 05:46:07
コンパイルエラーなんて別に構わないだろ。その場で分かるんだから。
怖いのは潜在的なエラーとしてバグを引き起こすこと。しかも数年後とか、改修時に。
後は抽出条件が実は間違っていた、とか。
172:NAME IS NULL
10/11/08 11:58:49 wNBEtH7N
簡単な人材派遣システムを作りたいのですが、空き人材の抽出方法に悩んでいます。
タスクの開始日と終了日、跳び石や繰り返し設定等を組み合わせて検索するには
どうすればいいのか複雑でまとまりません。
単純にタスクを実稼働日の配列として展開し、日付をフラグで
埋めていくほうが明快で良いのかもしれませんが、その場合のデメリットは
あるのでしょうか？
また各人材が稼働日空き日を保持するのと、先に競合タスクを判定して
従事者を除外するのはどちらが一般的なやり方でしょうか？
173:NAME IS NULL
10/11/09 00:22:16
業務で人材派遣システムを覗いたことがある。
人のアサインはアサイン管理テーブルみたいなので運用。
基本はDELETE→INSERT、少しでも期間が被った場合はエラー、
前の予約状況をキャンセルしない限り新しいアサインは不可。
174:NAME IS NULL
10/11/09 10:36:25
管理テーブルでDeleteは乱暴なので、更新日時が最新なものをピックアップでよい。案件確定後なり一定期間後にログとして出力してクリーニング。
175:NAME IS NULL
10/11/10 11:03:03 zzwY8gI+
>期間が被った場合はエラーについては
どう判定するのでしょうか？
新規側が連続日ならば、
新規期間内に既存開始／終了日のいずれかが無いこと、または
（新規開始前に既存開始があり、かつ新規終了後に既存終了後がある）が無いことで、
競合が無い人物の抽出（または競合するタスクに関わる人物の除外）はできますが、
毎週第二火曜日や、平日土日のみなどの隔日予定が混在するとややこしくなります。
日付に従業フラグを立てる場合は新規開始～終了までの日数分ループを回して
一日ごとに競合判定することが考えられますが、せっかく規則性あるのに
200日なら200個データを持つのは実用的なのかスマートでないのか…（柔軟にはなりますが）。
176:NAME IS NULL
10/11/10 17:42:59
bitフラグ判定で言いじゃん
db問い合わせも出来るし何が不満なんだ？
177:NAME IS NULL
10/11/11 10:54:29
給与計算ソフトで「社会保険料等控除後の額」とか
日本語の述語を使いまくった身としては日本語名を支持したい。
文字コードはUnix系では怖いけど.NETならまず心配ないし。
178:NAME IS NULL
10/11/11 12:07:30
.NET言語の変数名なら問題おこさないけど
Oracleの列名で日本語はいろいろ問題あるからなぁ
179:NAME IS NULL
10/11/11 20:08:59
>>155
>[正規化]
>作成No,製品名,合計,作成日,コメント
>部品No,作成No,部品,個数,単価
遅レスだが
[正規化]
T製品：作成No,製品名,合計,作成日,コメント
T使用部品：作成No,部品No,個数
T部品：部品No,部品名,単価
実はこう？
面倒臭いな
180:NAME IS NULL
10/11/11 23:01:04
.NETもLINQが使えないVS2005あたりで開発すると、正規化は諸刃の剣
181:NAME IS NULL
10/11/13 22:34:02
>>178
> Oracleの列名で日本語はいろいろ問題あるからなぁ
なんか定期的にこういうやつ出てくるけど、具体的な「問題」とやらは
書かないんだな (w
182:NAME IS NULL
10/11/14 01:25:17
最初に入った会社のDB設計は、列名日本語でやってたな。
優秀な人はいたけどガラパゴス状態な感じで、
今になって真似しようとは思わないけど、それなりにちゃんと動いてたよ。
Windowsオンリーの環境だったのが良かったのかもしれんけど
183:NAME IS NULL
10/11/14 10:30:25
だから、クローズドの環境なら日本語だろうがドイツ語だろうがハングルだろうがサンスクリットだろうが問題ないんだってばさ。
問題がおきれば随時つぶせばいいだけだし。
環境が頻繁に変わったり、他との連携で様々なドライバ使う可能性があったり、フロントエンドがガンガン増産されるような環境なら、
動作保障内でやるのが定石。
184:NAME IS NULL
10/11/14 13:34:39
それ Oracle の問題じゃねーだろ。
そもそも動作保証云々以前に「環境が頻繁に変わったり、他との連携で
様々なドライバ使う可能性があったり、フロントエンドがガンガン増産
されるような環境なら」日本語なんか使う奴は馬鹿だろ。
185:NAME IS NULL
10/11/14 23:41:47
>>181
文字コードの問題があるだろ。
日本語にしてしまうことで、文字コードがEUCなのかUTF8なのかSJISなのかを気にする必要が出てくるんだよ。
Windowsならまだしも、UNIX上からSQL文を叩くのに日本語入力することなんてありえねぇわ。
186:NAME IS NULL
10/11/15 00:27:52
そんなん今時utfやん。
大体おまえんとこは実機で直接SQLたたいてんの？w
187:NAME IS NULL
10/11/15 08:42:27
>>185
何年前の話をしてるんだ？
188:NAME IS NULL
10/11/16 02:10:00
わかるわかる。ASCIIのDDLもってけばどんな環境の上でも構築できるよねｗｗｗ
189:NAME IS NULL
10/11/16 10:57:26
試さずに聞くが、NLS_LANG=Japanese_Japan.UTF8でDB作れば
「№」とかを列名に含めても問題起こさないのか？
場合によって""で括る必要があったりなかったりで面倒なんだが・・・
190:NAME IS NULL
10/11/16 19:09:37
何か問題を起こしそうな文字コードなの？
191:NAME IS NULL
10/11/16 20:42:16
>>189
問題ない。
と言われれば信じるのか？ｗ
192:NAME IS NULL
10/11/16 21:32:01
>>191
それ、頭悪いレスの筆頭候補だと思ってる。
193:NAME IS NULL
10/11/17 01:07:34
>>186
OSはUTF8で、DBはSJISの環境が多いだろが。
勿論、実機でSQL文を叩くことが多いね。
194:NAME IS NULL
10/11/20 14:12:23 sSrpbL1f
DBがSJIS
195:NAME IS NULL
10/11/20 14:47:12
OSがUTF8でわざわざDBをSJISにする理由がないだろｗ
一昔前はOSがEUCでDBがSJISなら結構あったと思うが。
196:NAME IS NULL
10/11/21 22:27:34 4MhMQRH6
得意先別の締日を登録する場合，例えばデータ型をIntとした場合，
月末締めはどのように表現するのがいいのでしょうか？
よく，月末は99として登録するなどのテクニックがありますが，
どのような方法がいいのでしょうか。
197:NAME IS NULL
10/11/22 20:47:59
３１でいいと思うんだが
198:NAME IS NULL
10/11/22 21:18:08
31だと末尾を指定したかったのか31日を指定したかったのかが読み取れない
199:NAME IS NULL
10/11/22 21:26:58
31で十分
なんかの時のbitフラグ使用時もちょうどいいしな
99とか今時あるのか？
200:NAME IS NULL
10/11/22 21:30:15
それを区別する要件があるなら違う値にすればいい
俺にはそれを区別する要件は思い浮かばない
３１日締めの指定って、２月とか４月とかの締めどうするんだ？
201:NAME IS NULL
10/11/22 22:01:29
>>200
2月や4月の時に32指定だったら末日だとわかる。
31だとユーザや別システムの入力ミスかもしれない。
202:NAME IS NULL
10/11/22 22:08:29
31=月末
入力ミスとかDBでやるならトリガーで見張れよ
基本だろ…
203:NAME IS NULL
10/11/22 22:34:58
>>201
それは入力ミスってるんだから別問題だろ
そんなの救ってやる必要ないと思われる
たまにそういう仕様外の動作をコードでキャッチしようとする奴がいるけど
問題の切り分けができてない
204:NAME IS NULL
10/11/22 22:37:36
>>201
入力ミスって、３２でも入力ミスの可能性はあるわけだが？
結局３１でも３２でも、その月の末日で締めるわけだろ
わざわざ３１日締めという、月末締めとは別の状態が必要か？
それを正しく区別する設計というなら、指定日ごと締めと、月ごと（月末）締めの
締め区分みたいなものを別途用意するのが正解だろうな
205:196
10/11/23 22:38:58 wQ8I8TMH
多くのレス有難うございます。31を月末締めとすればいいようですね。
206:NAME IS NULL
10/11/24 00:22:54
>>205
いやー、仕様を確認したほうがいいと思うぞー
そもそも２９日締めとかって設定も入るようにする気か？
その場合２月とかどーすんだよｗ
本当は１日と１５日と末しかねーんだろ？
もしくは日付＋例外条件とかなってたら日にちで保存はヤバイかもしんないんだぞ
俺が前までいた会社は月の最期の営業日が締め日（技術者向けの）だったぞ
ただし、四半期の月じゃねーときは次の月のはじめの営業日までがセーフ・・・とかそんなんだ
複雑だろ？ｗ
もっと実務について詳しい担当と話合えよｗ
こーゆーのってディスプレイといくらにらめっこしててもダメだと思うぜ
207:NAME IS NULL
10/11/24 00:39:33
それ、締め日じゃない何かと勘違いしてないか？
セーフとかなんだそれ。
208:NAME IS NULL
10/11/24 05:20:01
仕様を確認した方がいいのは確かにそうだが
>206の話は締め基準日と、稼働日とか絡んだ実際の締日は別ってだけの話だ
今問題にしてるのは、締め基準日が月末の場合にどう保持するってだけの話
そっから実際の締め日をどう算出するかはまた別の話
209:NAME IS NULL
10/11/24 17:56:36
仮に締め日が来月の１日だったときって日付保存ってダメじゃね？って言ってほしいの？
210:NAME IS NULL
10/11/24 18:09:48
>>208
すでに実務として１～３１日って指定のが珍しいのに
これを継続して使うのってどうだろ？
よくある締め日と多少の例外ぐらいはサンプル集めたほうがいいと思うね
１日（先月分）、１５日（先月１６日～今月分）、２５日（先月２６日～今月２５日分）、月末（今月分）
だったら折角１～３１日まで入るようにしてあっても大半が無駄なわけじゃん
もうステータスでいいんじゃないの？
ステータスなら第二金曜日とか対応できるよ
211:NAME IS NULL
10/11/24 18:21:48
わかった！varchar型にして末日だったら「末日」って登録すればいいんじゃないかな？
212:NAME IS NULL
10/11/24 18:31:52
もう割り切って、テキストにすれば。
213:NAME IS NULL
10/11/24 19:52:36
>>211
素直が一番ってのは俺の長年のＰＧ経験で学んだこと
214:NAME IS NULL
10/11/24 23:03:51
ある売上が何年何月の第何週に起算されたものか、って言うのをシステム上で
表示して欲しいとか言われて、馬鹿正直に作ったら、
お盆期間は必ず8月の1週めに含む、とか、年末年始は～
とか色々なルールがあって結局全部コードに書いて何とかした。
今も動いてるのかなぁ、あのシステム。
215:196
10/11/24 23:16:33 vMmyFVn7
意外に盛り上がっているので，ちょっと驚いています。
マジレスすると，都度請求なので，単に得意先の締め日がわかればいいだけなので，
あまり複雑には考えていませんでした。確かに，複数の締め日があったり，
締め日が変動するケースもありそうなので，まじめに考えると頭が痛いですね。
216:NAME IS NULL
10/11/24 23:17:29
売り上げの起算日とお盆期間がどう関係あるのかよく分からないや。
今年だったら、8/1-8/7がお盆になるとして、8/3の売り上げはそのまま
8月の第一週に起算されたものなんじゃないの？
217:NAME IS NULL
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で問題が起こらないとは到底思えないな。