DB設計を語るスレ

1 ：NAME IS NULL：2006/12/19(火) 23:55:59 ID:hprRM4qH

語れ！！

2 ：NAME IS NULL：2006/12/20(水) 00:57:33 ID:4iqFdJvf

正規化って何で必要なの？特に必要ないように思うんだけど。

3 ：NAME IS NULL：2006/12/20(水) 07:01:38 ID:???

なんとなく、思うのは、
データの重複をさけたいからではないかと。

4 ：NAME IS NULL：2006/12/20(水) 07:02:59 ID:???

PKのないテーブルを設計する理由をおしえてほしい。
どんなときPKがいらないのか？

5 ：NAME IS NULL：2006/12/20(水) 13:54:06 ID:???

データの重複を避けると、データの管理が簡単になるだろ

6 ：NAME IS NULL：2006/12/21(木) 00:20:12 ID:???

>>4
めったに検索しないテーブルとか。

たとえば、なんかの動作ログ記録用のテーブル。

7 ：NAME IS NULL：2006/12/21(木) 10:22:50 ID:???

システムで使う定数を入れておく
1レコードだけのテーブルとか。

8 ：NAME IS NULL：2006/12/21(木) 14:58:42 ID:WlnR0fcq

ここの住人に質問です。

このやりとり、どう思う？
http://www2.moug.net/bbs/db/20061219000001.htm

9 ：NAME IS NULL：2006/12/21(木) 16:00:19 ID:???

あほくさい

10 ：NAME IS NULL：2006/12/22(金) 01:00:52 ID:???

>>8
どっちでもいいよ。どちらかが妥協すりゃすむし。
そんなんで工数伸ばすなよ。

11 ：NAME IS NULL：2006/12/26(火) 10:52:24 ID:???

コード化なんてDB設計の概念であるの？
どの書籍読んでも出てこないんだけど？

12 ：NAME IS NULL：2006/12/26(火) 10:57:14 ID:???

それ以前の問題化と

13 ：NAME IS NULL：2006/12/26(火) 11:44:47 ID:???

>12
kwsk

14 ：NAME IS NULL：2007/01/02(火) 00:43:20 ID:???

顧客管理とか、売り上げ管理とか、給与計算とか、そろそろ定型パターンって決まって無いの？
みんなでバラバラに作ってそれぞれ正規化してるのってかなり間抜け。

JISかなんかで、標準DB設計とか決めてしまえば良いのに。
SOX法対応ならこれとか、個人情報保護法対応ならこれとか、有ると楽。
DBAの仕事は無くなるだろうけど(w

15 ：NAME IS NULL：2007/01/02(火) 08:56:42 ID:???

その手の仕事したことないの？

あんたが言うように定型パターンはあって、会社毎にちょっと手直しするレベル。

でも、その手の仕事でデータベース設計の比率なんて知れてるから、わざわざ標
準データベース設計から差分を設計しなおすぐらいなら、新規に作った方が早い
し楽。

そもそも、標準からたいして離れていないなら、パッケージ製品導入するし。

16 ：NAME IS NULL：2007/01/02(火) 11:22:59 ID:???

標準データベース設計ってどこにあるの？
パッケージ製品ってぼったくられるじゃん。

17 ：NAME IS NULL：2007/01/02(火) 12:03:01 ID:???

> 標準データベース設計ってどこにあるの？

日本語大丈夫か？

そんなものいらないって書いてあるんだが。

> パッケージ製品ってぼったくられるじゃん。

頭悪いんだったら、金出せってこった。

て言うか、どっかに作らせたらもっとぼったくられるぞ。(w

18 ：NAME IS NULL：2007/01/02(火) 18:07:11 ID:???

業務別のパターン、結構本が出てるじゃん。
それ読みなよ。

19 ：NAME IS NULL：2007/01/02(火) 19:14:04 ID:???

ISBNくれ。

20 ：NAME IS NULL：2007/01/02(火) 21:13:44 ID:???

ISBN:457571075X

21 ：NAME IS NULL：2007/01/02(火) 22:48:45 ID:???

うまい

22 ：NAME IS NULL：2007/01/04(木) 12:09:55 ID:???

おまいら、DB設計で業務知識ってどのくらい意識してる？

23 ：NAME IS NULL：2007/01/05(金) 11:38:09 ID:???

DB設計というか、設計そのもので意識しないとだめくね？

24 ：NAME IS NULL：2007/01/05(金) 17:41:51 ID:???

>23
日経SWの記事で読んだ記憶があるんだが、
風呂屋のシステム開発で、業務知識を掴むため、
SEが一月ほど番台に立ったとかetc・・・

25 ：NAME IS NULL：2007/01/05(金) 23:21:22 ID:???

システム化された風呂屋...。

あんまり行きたくね～な。

26 ：NAME IS NULL：2007/01/05(金) 23:48:28 ID:???

>>25
女湯にセキュリティホールがあるので安心です。

27 ：NAME IS NULL：2007/01/06(土) 13:48:48 ID:???

番台に上がる老人が居なくなるから、存亡の危機とかでしょ。

28 ：NAME IS NULL：2007/01/10(水) 16:17:02 ID:???

おまいら、しっかり嫁よ↓

NULL撲滅委員会
http://www.geocities.jp/mickindex/database/db_getout_null.html

29 ：NAME IS NULL：2007/01/20(土) 10:27:38 ID:30yvgBBL

Firebirdで会社の作業日報を管理するものを作ろうとしてるんですが
平日と休日の作業時間を別々に集計したいのですが、
平日か休日かのデータをどのように管理するのがいいのでしょうか？

30 ：NAME IS NULL：2007/01/23(火) 18:35:21 ID:???

休日マスタ

31 ：NAME IS NULL：2007/01/29(月) 13:00:05 ID:???

休日しますた

32 ：NAME IS NULL：2007/02/02(金) 01:32:36 ID:FP7B9NgQ

３つのマスタテーブルがある場合に、それらをまとめて一つにした
テーブルって作る意味ある？

CREATE TABLE mst_hoge1 (id INT, name TEXT, PRIMARY KEY(id));
CREATE TABLE mst_hoge2 (id INT, name TEXT, PRIMARY KEY(id));
CREATE TABLE mst_hoge3 (id INT, name TEXT, PRIMARY KEY(id));

CREATE TABLE hoge_matome (
matome_id INT PRIMARY KEY,
FOREIGN KEY (hoge1_id) REFERENCES mst_hoge1(id),
FOREIGN KEY (hoge2_id) REFERENCES mst_hoge2(id),
FOREIGN KEY (hoge3_id) REFERENCES mst_hoge3(id)
);

matome_idを外部キーとして使うと全てのテーブルにhoge1_id, hoge2_id, hoge3_id
が入らなくて楽なんだけど。

33 ：NAME IS NULL：2007/02/03(土) 01:14:10 ID:???

まずマスタテーブルが３つもある理由から聞こうか。

34 ：32：2007/02/03(土) 13:49:09 ID:???

顧客マスタ、商品マスタ、配送業者マスタと３つあって
この３つセットが複数のテーブルで外部キーとなっている。

外部キーがいつも３つセットで登場するので、１つにできたら
全体的にテーブルもすっきりするかな、と思った。

35 ：32：2007/02/03(土) 15:21:16 ID:???

もうちょい具体的に書く。

CREATE TABLE 受注伝票テーブル (
受注ID INT PRIMARY KEY,
顧客ID INT,
商品ID INT,
配送業者ID INT,
受付日付 DATE,
処理日付 DATE,
担当者 TEXT,
FOREIGN KEY (顧客ID) REFERENCES 顧客マスタ(ID),
FOREIGN KEY (商品ID) REFERENCES 商品マスタ(ID),
FOREIGN KEY (配送業者ID) REFERENCES 配送業者マスタ(ID)
)

とこんなテーブルがあって、例えばこのテーブルと1:n関係にあるテーブルには
外部キーのリレーションによって
FOREIGN KEY (顧客ID) REFERENCES 顧客マスタ(ID),
FOREIGN KEY (商品ID) REFERENCES 商品マスタ(ID),
FOREIGN KEY (配送業者ID) REFERENCES 配送業者マスタ(ID)
をいちいち入れないといけない。これが嫌なので

CREATE TABLE 流通テーブル (
流通ID INT PRIMARY KEY,
顧客ID INT,
商品ID INT,
配送業者ID INT
FOREIGN KEY (顧客ID) REFERENCES 顧客マスタ(ID),
FOREIGN KEY (商品ID) REFERENCES 商品マスタ(ID),
FOREIGN KEY (配送業者ID) REFERENCES 配送業者マスタ(ID)
)

とこんな外部キーだけをまとめたテーブルを別に作って、
CREATE TABLE 受注伝票テーブル (
受注ID INT PRIMARY KEY,
流通ID INT,
受付日付 DATE,
処理日付 DATE,
担当者 TEXT,
FOREIGN KEY (流通ID) REFERENCES 流通テーブル(ID)
)

と外部キーを一つにすると、1:n関係にあるテーブルにはキーが1個で済むので
容量的にも速度的にもよさそうなもんなんだけど、設計としてはどうなの？と
思ってる。

36 ：NAME IS NULL：2007/02/03(土) 16:48:53 ID:???

その場合、3つのﾏｽﾀを組み合わせで商品データが作成されるということではないかと思う。
運用方法にもよるが、よく使う手だよ。
ただし、流通IDで受注入力を行うのなら問題はないが、
入力時に顧客マスタ、商品マスタ、配送業者マスタを
別々に絞込みを行い入力する場合は手間も時間もかかるね。

運用しだいだね

37 ：32：2007/02/03(土) 22:05:19 ID:???

>>36
運用では流通IDでのみ受注入力なので問題がないようです。

ありがとうございました。

38 ：NAME IS NULL：2007/02/04(日) 16:43:35 ID:???

初DB作成で商品評価データベースを作りたいと考えています。

流れ
１webでユーザー登録（未登録はゲスト）
２ユーザーは商品に評価・感想を書ける
３それら評価などから商品をランキング表示可能

といった感じなんですが
・商品データベース
・ユーザーデータベース
の２種類が必要そうだなと。こういった場合ユーザーの
「評価」や「感想」はユーザーデータベース側か
商品データベース側かどちらに置いておくほうがいいとか
あるんでしょうか？
基本設計のアドバイスをいただけたら幸いです。

39 ：NAME IS NULL：2007/02/04(日) 16:56:08 ID:???

設計の基本
1. エンティティを決める
2. 1:1, 1:n, m:nの関係を整理してリレーションを決める。

私の場合なら、エンティティとして
・商品
・ユーザ
・評価
の3種類作るな。

商品と評価の関係: 1:n
１個の商品に対してn個の評価の可能性があるので1:n関係。

ユーザと評価の関係: 1:n
１人のユーザがn個の評価をする可能性があるので1:n関係。

ｎ側の方に1側のプライマリキーを含めると評価テーブル完成。
1:1, m:nは設計という意味ではあまり意味ないので無視する。

ランキングについてはちょっと考えてみ。

40 ：NAME IS NULL：2007/02/17(土) 18:52:52 ID:JVcoRVj9

DB設計していると区分が大量にでてくるけど、
そういうのって、区分を管理するテーブルを新たに作って管理するものなのかな？

41 ：NAME IS NULL：2007/02/17(土) 20:46:55 ID:???

必要なら作れ

42 ：NAME IS NULL：2007/02/17(土) 21:20:37 ID:JVcoRVj9

>>41
あなたはどう管理していますか？
プログラム、それともテーブルで管理していますか？
私は、テーブルや、項目を管理するテーブルを作って、
下のような区分管理テーブルを作っています。

テーブルコード　pk
項目C 　 pk
区分　　 pk
区分名称

43 ：NAME IS NULL：2007/02/18(日) 03:11:58 ID:???

汎用性持たせとくか、決め打ちかってだけじゃないの？

速度重視なら決め打ち。
拡張性重視なら管理テーブル作成。

システム屋の場合は定期的に収入も欲しいから、あんまり完璧なシステム作ると仕事が無くなる。
定期的に手直ししつつ収入が入って飯が喰えたほうが嬉しい。

44 ：NAME IS NULL：2007/02/23(金) 23:26:01 ID:1tyqb/0g

これまでの業務で外部キーを使うことってあまりないのだが、
外部キーって必要な場面ってどんなとき？
外部キーで可能な制御は外部キー制約で制御する事じゃないと思うのだが。
プログラムレベルで制御すべき事が多いと思う。
テストデータ作る時なんか、
外部キー制約で挿入が面倒だというデメリットは知ってるが。

45 ：NAME IS NULL：2007/02/23(金) 23:45:03 ID:???

>>44
その話題、この板のそこここに散らばってるなあ。
永遠のテーマなのか・・・。

制約っていらなくね？
http://pc10.2ch.net/test/read.cgi/db/1087483786/l50

他のスレで、インポート時は制約削除しちゃえという意見があって
なんでその手に気が付かなかったのかと思った。
ここらへんだ↓
http://pc10.2ch.net/test/read.cgi/db/1069324950/782-792

46 ：NAME IS NULL：2007/02/24(土) 00:32:27 ID:7O++I76A

>>44
伝票ヘッダーと明細の関係の時に使うよ。
伝票消すときはヘッダーだけ消せばいいから

47 ：NAME IS NULL：2007/02/24(土) 14:09:22 ID:+wKoEvab

くだらない質問かもしれないんですけど
カラムの命名でちょっと迷ってます。

色々なテーブルで同じ種類の項目、
例えばテーブルuserとshopに名前をあらわすカラムを作るとして
これを両方ともnameと命名するのと、user_nameとshop_nameなどユニークな名前で
命名するのとどっちがいいのでしょうか？

SQL的にはテーブル名指定しなくていいし、例えば登録日時でソート
なんてする場合、全テーブルadd_dateなんて名前にしといたら
joinして問い合わせたとき、必ずテーブル名をつけなきゃならないじゃないですか？（ここ間違ってます？＾＾；）

とりあえず、ユニークな名前をつけようと思ってるのですが
どうなんでしょうか？
ご意見ありましたらよろしくお願いします。

48 ：NAME IS NULL：2007/02/24(土) 18:27:10 ID:???

>>47
nameだと迷うかもしれないが
主キーとかはuser_idとかshop_idにしないと
両方とも他のテーブルのFKになった時に
結局名前付けなきゃならなくなるのでそうしてる。

idをそうしたんならnameもあわせてそうしておく方が
判りやすいと思う。

とここまで書いて気が付いたが、addressやらtelやらemailは
user_とかshop_とかつけないなあ・・・なんだろうこの基準は。
気分でしかないのかも知れないなあ。

登録日時なんかは要するにメンテ要件であって
業務要件ではないので全部同じ名前にしてる。

49 ：NAME IS NULL：2007/02/24(土) 19:30:30 ID:7O++I76A

主キーは普通IDじゃないとORマッパー使うとき不便だぞ

50 ：NAME IS NULL：2007/02/24(土) 21:19:20 ID:w75Pe+VJ

>>47
名前を表すといっても店名と人名は違うだろ？
だから別のカラム名の方がいい。
電話番号、メールはどちらも一緒だから、
同じ名前にしないと分かりづらい。
この辺は国語の問題なんだけどな。勉強してきてないヤツ(専門卒とか)が悩む問題だね。

51 ：NAME IS NULL：2007/02/24(土) 21:43:37 ID:???

と学歴しかとりえの無い>>50が逝っています。

52 ：NAME IS NULL：2007/02/24(土) 21:50:30 ID:???

>>50
名前を表すといっても店名と人名は違うだろ？
って当然のようにいってるけどさ、
店名・人名の違いって何？

もっと仕事ぽくいいかえようか？
仕入先マスタと売上先マスタがあったとして、
仕入先名と売上先名の違いって何？

53 ：NAME IS NULL：2007/02/24(土) 21:52:41 ID:???

>>50
面倒だからいっそ同じ名前(cd,name,telとか)にしてasで別名付ければ良くない？
使い回しするのはview作るんだろうし。

54 ：NAME IS NULL：2007/02/24(土) 22:26:37 ID:7O++I76A

>>52
売上先マスタって・・・
後気持ちは分かるけど
ちょっとずれてるぞ
普通、得意先名と店名は意味合いが違うだろ

55 ：NAME IS NULL：2007/02/24(土) 22:31:58 ID:???

>>54
取引先として一括管理したい場合があるって事じゃね？
JAなんかだとコードも一緒だったりするんで別管理しなくて良くね？って話が出た事がある。
(こっちのシステムの都合で別マスタになったが)

56 ：NAME IS NULL：2007/02/24(土) 22:35:35 ID:EBk8cf2k

ユーザー自動作成の日別スケジュール表で、
何のイベント（予定記入）もなく過ぎ去った過去の日のレコードは
削除した方がいいですか？
何らかの追加があった場合にはレコードを新規に追加するようにして

57 ：NAME IS NULL：2007/02/24(土) 22:36:49 ID:7O++I76A

なら仕入先マスタはいらないじゃん

58 ：47：2007/02/25(日) 01:07:30 ID:Zz8YGbzC

>>48
>>50
他、関連レスしてくれた人サンクス

確かにFKは迷わずユニークですね。

うちの会社のシステム（外注品）は>>47と同じ感じの仕様なんですよね。
で、会社では、データを取り出すプログラムを作ってるんですけど、
登録日時順にソートすることが多いんです。
また、会社のシステムには全テーブルにadd_dateというカラムがあって、
これ名前変えた方が迷わなくて良いのかなあ
なんて考えたわけでして・・・

今、仕事とは別に自宅鯖で個人的にシステムを作っていて、
いっそのこと、カラム名は全テーブルでユニークな名前にしたらどうだろうと思い
ちょっと迷ったので質問しました。

参考にさせて頂きます
ありがとでした。

59 ：NAME IS NULL：2007/02/25(日) 11:19:54 ID:???

結局お客さんによりけりじゃないの？
もう理屈こねたって宗教論争ぽいよ。

お客さんの店台帳に「店名」って書いてあれば
shop_nameとするのが自然だし
ただ「名称」と書いてあったら、
nameでもいいけど、うーんでもちょっと迷うな。

で、台帳には普通「住所」とか「電話番号」って書いあるだろうし
だからそれらはaddressやらtelでいい、と。
もし「店住所」とか「店電話番号」って書いてあるなら
shop_addressとかshop_telとか考えればいい。まあまずないよなあ。

idはユニークな名前の方がいい。
「id」って名前にしないと使えないORマッパなんてもんが
あるならそんなもん使わない方がいいよ。

60 ：NAME IS NULL：2007/02/25(日) 11:30:30 ID:k357gTV0

複合キーを受け入れられない人っているんだね～（ｗ

61 ：NAME IS NULL：2007/02/25(日) 13:58:00 ID:6/IGUhkO

一つ間違って欲しくないのはSQLを書きやすくするためのテーブル設計をしてはだめ。
CUSTOMERS.NAMEが得意先名の方が自然だろ。
得意先名というのは得意先の名前であって得意先の得意先名ではない。
CUSTOMERS.CUSTOMER_NAMEだとおかしいし、それはむかしのテーブル設計方法だ。
少なくともJAVAやRAILSとかではこれが主流。

62 ：NAME IS NULL：2007/02/25(日) 14:29:53 ID:???

>>59
その例じゃ・・・

携帯TEL・自宅TEL・会社TELとかの方がいいだろ

63 ：NAME IS NULL：2007/02/25(日) 15:24:38 ID:???

>>61
テーブル設計ってより名前付けのポリシーだからなあ
どうしても悩んじゃうんじゃないかな。

SQLを書きやすいように設計するなってのは
要するに、実装の都合で設計を左右させるなって事だと思うけど
そうすると最後のJavaやRailsとかでは主流、なんて話と矛盾するじゃん。

言語の都合に合わせてよくてSQLの都合に合わせちゃいけないってのは
その間にどういう違いがあるのかな？

>>62
うん、だからお客さんの台帳にそう書いてあるなら
そうしなよって話だよ。

64 ：NAME IS NULL：2007/02/25(日) 15:32:48 ID:???

>>61
上の議論が単にSQLの書きやすさを云々しているのだと思っているなら
オマイが間違っている。
RDBの世界のこの古い慣習は、同一のドメインを持つ属性には
同じ属性名を使おうということ。

ちなみにJava言語そのものはこれをクラスで表現できるわけだけど、
ドメインを意識した設計をするJavaプログラマーてのは少ないね。
まぁいちいちクラスを起こすのは面倒くさいってのもあるけれど。

65 ：NAME IS NULL：2007/02/25(日) 15:46:27 ID:6/IGUhkO

そういうレベルの低い設計方法を話し合うスレなの？
IDEFとかの勉強をしたら？

66 ：NAME IS NULL：2007/02/25(日) 16:42:54 ID:???

>>65
まずスレの流れを読む勉強したら？

67 ：NAME IS NULL：2007/02/25(日) 17:08:58 ID:???

>>64
そうか、ドメインだ、その言葉ですっきりした。

>>52はさ、電話番号、住所は同じドメインで
店名と人名はドメインが違うと言ってる訳だよ。

で、店名と人名と、どう違うのよ？
それぞれのドメインってどんなもんなのよって
話だよな。

ただの名前付けの話からスレタイにふさわしい内容になってきたなあ。

で、話が前後するけど、実装と設計の話だったら俺は
実装の都合に合わせた設計はしてもいいと思うよ。
実装されない設計なんて意味ないし。
ORマッパーが複合キーだと使いにくいってんなら
全部id振ります。

68 ：67：2007/02/25(日) 17:10:21 ID:???

ごめん。

> >>52はさ、電話番号、住所は同じドメインで
> 店名と人名はドメインが違うと言ってる訳だよ。

これは>>52じゃなくて>>50の間違い。

69 ：NAME IS NULL：2007/02/25(日) 19:17:19 ID:6/IGUhkO

>>64
上のレスはドメインモデル無視にSQLの書きやすさとかユーザーが扱う項目名を安易にカラム名に使用してるように思えた。
ながれてきに解決したみたいだからいいけど

70 ：NAME IS NULL：2007/02/25(日) 21:48:25 ID:???

>>69
たぶんドメイン違い。

71 ：NAME IS NULL：2007/02/25(日) 21:57:49 ID:???

>>56
> ユーザー自動作成の日別スケジュール表

俺俺用語で書かれても、君以外には理解できないよ。

72 ：NAME IS NULL：2007/02/26(月) 05:00:31 ID:???

SHOP.SHOP_IDと記述する私は昔の人だと感じました

73 ：NAME IS NULL：2007/03/03(土) 23:50:38 ID:???

OOのドメインモデルとRDBのドメインの区別ついてるか？

74 ：NAME IS NULL：2007/03/07(水) 01:20:30 ID:???

通りすがりで酔ってるので、スーパー亀レス

>>2
正規化する必要性は、
「１事実１箇所（one fact in one place）」にすることで、
データ操作時に発生する問題を解消する。
（発生する問題）
　・二重登録／重複更新（更新不整合）
　・事前登録できない（挿入不整合）
　・関係の消失（削除不整合）

>>4
テーブルに１行しかないとき。
RDBにおいて、主キーはテーブルのなかから行を特定するためのものだから。
１行しかないので特定する必要がない。従って、主キーが不要。

>>11
コード化は、DB設計の概念ではない。でも広義にはドメインの設計と言えるかも。

>>22
「DB設計」という用語が、データ設計、概念設計などと同義であれば、
業務知識が必要。物理設計と同義であれば、不要。

>>32,35
[流通テーブル]は、「連関エンティティ」というものにあたるな。
さらに、[流通ID]は、「代替キー」というものにあたる。
厳密には、[顧客ID,商品ID,配送業者ID]でユニーク制約を実装する必要がある。
（もともとその３つが主キーとして一意性があるから）
ちなみに「リレーション」じゃなくて「リレーションシップ」だ。
「リレーション」はRDBではテーブルのことだ。

>>40
自分の場合は、その区分がデータモデル上のエンティティとして意味を持つか、
その区分のドメイン（=定義域=値のとりうる範囲）に変更がありそうなら
テーブル作るかな。変更可能性が少ない場合は、特にテーブルにしない。

>>44
参照整合性制約（外部キー制約）は、データ中心設計した場合に必要だと認識してる。
可能な限り、データモデルを実装に反映することで
　・設計-実装の乖離を防止する
　・正規化されたストアをAP屋が解釈するというスキルミスマッチを防止して
　　開発コストを適正にする
　・どうせ商用DBつかうから、自前APで制御のテストコスト掛けるより安くすむ
自分は、そういう解釈をしてDBで実装してる。

75 ：NAME IS NULL：2007/03/23(金) 10:18:56 ID:???

業務知識もうろ覚え、データベース設計もろくにやったことが無い素人に基幹の
DBを設計させんなよ('A`

xxxはpkにした方がいいんかなぁ・・・
あ、でも帳票の括りを考えると属性のほうがいいかなぁ・・・
待てよ、入力単位を考えたらこれじゃ駄目じゃん
先頭へ戻る

て感じで延々とループに陥ってる漏れ orz

ところでERWinって半額くらいで買えるキャンペーンとかないん？

76 ：NAME IS NULL：2007/03/23(金) 11:38:15 ID:HPT+SY9e

> ところでERWinって半額くらいで買えるキャンペーンとかないん？

Visio じゃ駄目なの？

77 ：NAME IS NULL：2007/03/23(金) 12:04:45 ID:???

> ところでERWinって半額くらいで買えるキャンペーンとかないん？

紙と鉛筆じゃ駄目なの？

78 ：NAME IS NULL：2007/03/23(金) 12:35:08 ID:???

>>76
ERWinの快適さに慣れると、VisioやObjectBrowserには戻れンすよ。
んでも、DBDesigner4を試してみたら思ったよりイケテる感じがしたんで
しばらく試してみようと思う。

>>77
m9（＾Д＾）

79 ：NAME IS NULL：2007/03/23(金) 13:05:54 ID:???

ERWinは保守ツールだな。設計の後半から保守フェーズ向き。
設計の前半は紙と鉛筆、客向けの資料はVisioも使うぞ。

80 ：NAME IS NULL：2007/03/23(金) 13:43:38 ID:???

>>75
ttp://www.sparxsystems.jp/
テーブル生成のSQL出力とかあったと思う。

81 ：NAME IS NULL：2007/03/23(金) 16:46:53 ID:???

>>78
DBD4って辞書登録出来るん？
なんかどうやって項目を辞書登録していいんかわからへんかったやねんけど。

82 ：NAME IS NULL：2007/06/10(日) 19:34:15 ID:NrCzcrMI

今のシステムのOracleデータベース、新機種が発売されるたびに、その機種専用のスペックテーブルが増えたり、
関連するテーブルのフィールドが増え、そのたびに増えたテーブルやフィールド用にプログラムをバージョンアップするんだが、
そもそも機種が増えるたびにデータベースの構造を変化させるようなテーブル設計ておかしくない？
それとも、世の中では普通に運用中にテーブル増やしたりフィールド増やしたりするの？
異動して半年、あまりの設計思想の違いに混乱しまくりです。。。

83 ：NAME IS NULL：2007/06/10(日) 22:18:03 ID:???

余計なことして、仕事 (した気になってる) or (してる振りしたい) 奴がいるんじゃないか？

84 ：NAME IS NULL：2007/06/10(日) 23:30:51 ID:???

テーブル生成SQLなんて、Excelでええやん。

85 ：NAME IS NULL：2007/06/13(水) 18:07:38 ID:i/W8/Jf6

お前が管理者になって自分の部署がシゴトナシになった場合のやばさを考えるんだ

86 ：NAME IS NULL：2007/06/13(水) 23:24:01 ID:???

いくらでもFreeでいいツール出てきてんのにEXCELって、酷いよね・・・

87 ：NAME IS NULL：2007/06/14(木) 00:42:01 ID:???

>>82
その設計はおかしいんじゃない。
コボラーとかVB厨房の設計じゃないのかな。

88 ：NAME IS NULL：2007/06/15(金) 16:24:15 ID:???

>>82
たしかに新機種が発売されるとテーブルが増えるという
設計はおかしいな。

カラムが増える、というのであればわからんでもないが。
現時点では実装されていない「機能」が将来つくかもしれんしね。

89 ：NAME IS NULL：2007/06/16(土) 17:20:56 ID:???

>>88
むしろ新機種の新機能部分は新規テーブルで作ってリンクという思想自体はアリでは?

例えば携帯電話みたいに
新機種毎に新機能＋それに関わる多数の独自の属性項目がどんどん増えていくような
商品の場合
# カメラ機能テーブルとかワンセグ機能テーブルとか。
旧製品は新機能のテーブルにレコード自体が存在しないから無駄も少ないし。

新製品毎に既存のテーブルの列が増える方が問題な気が。
旧製品にとっては確実に無駄な項目だから。

90 ：NAME IS NULL：2007/06/25(月) 10:17:22 ID:NcBbc/LF

それならいっそ

機種ID 機能ID スペック(数値型) スペック(文字列型)

機能ID 機能名

みたいな設計にしてみるとどうだろう。

91 ：NAME IS NULL：2007/07/05(木) 19:32:01 ID:iUW9TYQf

質問です。

例えば、以下のような項目があった場合の設計に関してです。
(前提条件として各データが複数になる事はありません。）

個人ID/名前/住所/電話番号/性別/身長/体重/胸囲/腹筋/背筋/腕立て/

上記の様に一つのテーブルでも問題ありませんが、分類すれば、

■基本情報
個人ID/名前/住所/電話番号/性別/

■身体
個人ID/身長/体重/胸囲/

■能力
個人ID/腹筋/背筋/腕立て/

と、意味で分類できる場合、1対1の関係のテーブルを作った方が良いのか悪いのか。
って事なんですが。
分かれていると手間になるが、分類してある方がすっきりしているような気もするし･･･。

92 ：NAME IS NULL：2007/07/05(木) 19:36:36 ID:???

>>86
社内規定でフリーソフト使用禁止なんだ……。

93 ：NAME IS NULL ：2007/07/05(木) 23:41:16 ID:BUGp8zxh

>>91
分類したあと、分析とかするの？
基本的には、ひとつで問題ない。第3正規形を満たしてるし。
（でも、前提条件あるとはいえ、年度によって身長とか変わると思うけど…）

94 ：NAME IS NULL：2007/07/06(金) 00:03:10 ID:7xm44r2b

>>91
情報のライフサイクルで分けるといいと思う。
測定が複数回行われたり、行われない場合もある（NULLが発生する）のであれば

■基本情報
個人ID/名前/住所/電話番号/性別/
■身体測定
身体測定ID/個人ID[FK]/実施年月日/身長/体重/胸囲/
■能力測定
能力測定ID/個人ID[FK]/実施年月日/腹筋/背筋/腕立て/

のようにする方がよい。

逆に個人情報の登録時に必ず１回だけ測定が行われるのなら、意味のないテーブル分割はしない方がいい。

95 ：NAME IS NULL：2007/07/06(金) 00:29:03 ID:???

>>91
分ける意味も必要もないと思う。

理由は、前の人も書いているけど、前提条件から個人IDが主キーだとして、
非キー属性が主キー属性に関数従属する第３正規形になっていて、
多値従属性や結合従属性などの従属関係が無い。（これ以上正規化できない）
要するに正規化済みなので、テーブルを分割する必要は無い。
one fact in one place（１事実１箇所）で。

また、ERモデルで考えた場合に、前提条件から"個人"=個人IDとした場合、
"個人"という【実体】を表していて、エンティティを３つに分割できない。

96 ：NAME IS NULL：2007/07/06(金) 01:17:44 ID:???

>>91

無理やりにでも分ける意義を見出すならば、
各情報へのアクセス権限を管理したいケースかな。
職員は全てへのアクセス権限があるが、保険委員は
身体/能力にしかアクセスさせたくないようなシナリオ。

もちろん、フィールドごとに権限を管理できるDBMSならば
1テーブルでもそれは実現できるという話になる。

97 ：NAME IS NULL：2007/07/06(金) 13:57:11 ID:???

>>93-96
ありがとう御座います。

1対1になる場合は、原則分割する意味は無さそうですね。

そして申し訳ありません。
>>94さんの回答を頂いて自分の失念がありました。
前提条件に関してですが、

前提条件として各データが複数になる事はありません。
これに追加して、ただし、身体測定と能力測定は、測定しない人もいます。
(身体測定だけする人、能力測定だけする人がいます。)

がありました。

この場合、分割するとデータは1対1か1対0の可能性がありますので、
分割する意味はあるという事になりますでしょうか？
それともやはり無いのでしょうか。

98 ：NAME IS NULL：2007/07/06(金) 14:14:35 ID:???

>>97

扱ってる人数が非常に多く、なおかつ測定している人が非常に少ない場合は、
「測定した人だけを対象に」何かを集計するようなクエリでは
各テーブルに分けている方がパフォーマンス的には有利にはなるかな。
あと、ディスクサイズの節約にもなる。

逆に言えば、測定値がN/Aの人がほとんどいないならば
1テーブルでいいだろう。

99 ：NAME IS NULL：2007/07/13(金) 23:39:52 ID:???

ちょうど今のＤＢ設計でそんな状態があったから書き込んでみる。

俺が１対１にテーブルを分けるのはイベントタイミングが分かれる場合と、
業務的に敢えて意味を持たせたい場合かな。
たとえば登録するユースケースが複数に分かれる場合などね。

・基本情報登録UC
・身体情報登録UC

どっちもInsertになるしわかりやすいから実装しやすい。
1度に取ってくる場合には結合が発生する分無駄になる。

１テーブルにしてしまうと1回目はInsert、2回目はUpdateになるから、設計が面倒になるし。

あとは、ORマッピングするときも分けておいたほうが楽。
クラス設計だとその2つは「人」と「身体測定結果」の2クラスに分けるから。

もっとも、「測定項目」と「測定結果（値、単位、測定年月日）」とかにしとくとさらに汎用的だよね。

DOAじゃなくてｽﾏｿ

100 ：NAME IS NULL：2007/07/14(土) 00:06:04 ID:???

100げっと

>>99
なるほどそれなら2テーブルに分けてinsertがやりやすそうだけど、
データの扱い方が、マスタというよりはログ的な場合だよね。

重複登録されても、そのイベントの時点では許容して、
レポートを出す段階になったときに考慮するような感じの。

101 ：NAME IS NULL：2007/07/14(土) 09:27:40 ID:???

> １テーブルにしてしまうと1回目はInsert、2回目はUpdateになるから、設計が面倒になるし。

意味わからん。

データの修正は金輪際ないって仕様なの？

それとも、全部 Insert しといて、参照する時は最新のものを取ってくるとか？

102 ：NAME IS NULL：2007/07/16(月) 23:28:22 ID:???

>>99
>クラス設計だとその2つは「人」と「身体測定結果」の2クラスに分けるから

これなら分割する意味有るね。

103 ：NAME IS NULL：2007/08/07(火) 19:12:21 ID:???

初心者です。質問させてください。

時間を扱うのはどの型で決めればいいと思いますか？

時間といいますと、一時間や二時間とかで日付、時刻ではないです。

104 ：NAME IS NULL：2007/08/07(火) 19:19:22 ID:???

int

105 ：NAME IS NULL：2007/08/07(火) 19:21:00 ID:???

tinyint～int で良いんじゃないか。

どういった点で悩んでいるの？

106 ：NAME IS NULL：2007/08/07(火) 23:04:45 ID:???

>>103
nvarcharなら１時間でも一時間でも壱時間でも丑三時でもオッケーだぜ。

107 ：103：2007/08/08(水) 08:53:20 ID:???

レスありがとうございます！
時間の計算がしたくてどのような値がいいのか、他の同僚がTime型で定義しようなど言っていたのでそれでいいのかということが聞きたかったのです。

Time型って時刻ですよね？時間といえば時間なんですけど・・・
疑問に沸いたのでみなさんはどの型を使用されてるのかお聞きしたくて書き込みました。

intで定義されている方の場合1時間30分はどのようなデータになるのでしょうか？分計算で90という値が入る形ですか？

108 ：NAME IS NULL：2007/08/08(水) 09:10:20 ID:aWfaidbN

「時刻（位置）」と「時間（距離）」は別物。
そして分単位が必要となるなら、分単位で保持しておくこと。

109 ：103：2007/08/08(水) 10:12:46 ID:???

>>108
別物ですよね。ならばTime型はやめた方がいいということですよね？

DBの設計者も今回設計はじめてらしくTime型を選んだのはテーブルのデータが見やすいだからだそうです。
Time型のばあい1時間であらわすと 01：00：00 と入れるらしいです。確かに分かりやすいですが・・・
その辺についてはどうでしょうか？そのデータ内容は24時間越えないそうですがDB設計としては間違っていませんか？

110 ：NAME IS NULL：2007/08/08(水) 10:35:16 ID:???

>>109
そのTime型というのが、使用してるDBMSで、時刻ではなく時間長を表す型として
用意されてるものなら、それが一番いいんじゃない？
質問者がDBMSを明示してないし、ここのスレの回答者は基本的に
DBMS非依存の標準SQL仕様を前提に考えてるから汎用的には
>>104-106,108 みたいな回答しかない出せないわけだが(もちろんそれが正しい)、
DBMS依存を考慮するならまた話は変わってくる。

111 ：103：2007/08/08(水) 11:06:43 ID:???

>>110
勉強になります。Time型など時間は時間長として扱うということに抵抗があったので（＞＜）
DBMSはpostgresを採用してます。

112 ：NAME IS NULL：2007/08/08(水) 11:13:07 ID:???

>>111
PostgreSQLなら、時間長はinterval型てのが用意されてるみたいだね。
俺も使ったことはないから自信もって推奨はできんが。
PostgreSQL識者いたら、フォローよろ。
あと、回答者もPosgreSQLマニュアル読んでみて。

113 ：NAME IS NULL：2007/08/08(水) 11:15:00 ID:???

>>112
x:回答者も
o:質問者も

114 ：103：2007/08/08(水) 12:10:20 ID:???

みなさんご親切にいろいろありがとうございます！

>>112
interval型ですね。調べてみます！

115 ：NAME IS NULL：2007/08/08(水) 13:58:43 ID:aWfaidbN

interval型とか、ホスト言語から扱いにくかったりもするから注意。

116 ：103：2007/08/08(水) 16:43:16 ID:???

>>115
javaを扱ってますがたしかにそのような感じですね。

117 ：NAME IS NULL：2007/08/08(水) 23:11:39 ID:???

基本的に"時間"だからtimeだのtimestampをつかうのはおすすめしない。
時と場合による。書き込みをみてると単純にTime型をあなたが使いたくないだけに見える。
その保持した分の使用用途にもよる。

118 ：NAME IS NULL：2007/08/12(日) 14:11:04 ID:N4Usbcud

ユーザーに好きな食べ物を選ばせます。
1.肉 2.魚 3.野菜
1個も選ばなくてもいいし、2,3個選んでもいいとします。
こういった状態を保持するのに
1) それぞれ専用の列を用意して好き・嫌いを保持する
2) 好きな食べ物列を用意してパーミッションみたいに1,2,4みたいな感じで保持する
3) 好きな食べ物列を用意してカンマ区切りで保持する

1だと選ばせる食べ物が増えた場合にたいへんそうだとか、ぱっと思いつくのですが
なにぶん経験不足な物で、どのパターンでやると今後こまったりするのか、などが調査できていません。
どのパターンがよいか、またこういった時にこまる、など教えていただけないでしょうか。

119 ：NAME IS NULL：2007/08/12(日) 15:12:05 ID:SxglpIS4

■ユーザー
ユーザーID/名前/etc...
■食べ物
食べ物ID/名前/etc...
■ユーザーの好きな食べ物
ユーザーの好きな食べ物ID/ユーザーID(FK)/食べ物ID(FK)

とするのがよいと思います。

120 ：NAME IS NULL：2007/08/12(日) 23:03:22 ID:???

>>118
一般に、多対多の関係は「関係」を表すテーブルを作成して表現する。
つまり答えは>>119の通り。
「ユーザーの好きな食べ物ID」は余計だけども。

121 ：NAME IS NULL：2007/08/12(日) 23:51:52 ID:???

>>120
「ユーザーの好きな食べ物ID」は
実装を考えた場合あった方がいい。

実装で複合キーはやっぱりしんどい。

122 ：NAME IS NULL：2007/08/14(火) 10:38:16 ID:???

>>120-121
IDを付加するか否かの基準を教えてください。必ず必要ということなら、
その理由を。
私は、重複する可能性のないものはIDは要らないと思っていました。
この例ですと、ユーザーIDだけが必要だと。

123 ：122：2007/08/14(火) 12:08:01 ID:???

>>122
ネタっぽく書いたつもりでしたが、おかしかったですね。
この書き込みなかったことにしてください。

124 ：NAME IS NULL：2007/08/14(火) 12:09:30 ID:???

>>122
そもそも「ID」というものはプログラム実装上の都合でつけるもの。
IDをつけたほうが実装しやすければつければいいし
そうでもなければつけなければいいだけ。
いちいち考えるのが面倒だから全部IDつけちゃえっていう考え方もアリだろう。

125 ：119：2007/08/14(火) 13:11:37 ID:fI74lPjs

私はまさに、実装に便利なのと、いちいち考えるくらいなら主キーは全部IDにしてしまえと思っています。
デメリットもないですし。

126 ：NAME IS NULL：2007/08/14(火) 13:17:22 ID:vLfyd2Go

DB 設計の話かどうかわからんのですが…

必要なディスク容量とかどのように算出するものなのでしょうか？

例えば、レコードに以下のデータを保存するとして、

id: 4 Byte
name: 64 Byte
jender: 1 Byte
memo: 256 Byte

合計が 325 Byte になります。レコードが 100000 件あるとすると、
最低でも 325 * 100000 = 32500000 Byte になり、
圧縮されずに保管されるとして、ディスク領域として最低 30MB ほど
が必要になるのではと想像しています。
しかし、管理用にとか、検索用にとかでこれだけでは足りないとも
思っています。

一般的に必要なディスク容量を出すときは、
どのように見積もるものなんでしょうか？

127 ：NAME IS NULL：2007/08/14(火) 14:11:21 ID:???

>>126
MySQLはよく知らないから大雑把な話をすると、方法は次の３つくらい。
1) 1レコードのバイト長Xレコード数で求めたものを３～４倍する。
2) 実際にテーブルや索引を作り、実際のレコード数または1/倍のレコードを投入して測定。
3) DBMS毎に細かい計算方法がマニュアルにあるのでそれで積算する。

3が一見一番緻密であるため正確のように思えるが緻密ゆえに誤差や誤謬で大きく外れた数字になりやすい。
1と2を組みあわせるのが一般的。
ただ客から3を要求されることは多いので、3の数字が妥当であるかの検証に1や2の結果を利用することになる。

128 ：126：2007/08/14(火) 14:15:19 ID:vLfyd2Go

>>127

なるほど、そのような方法を取るのですね。

1 は本当の概算、2 は（ある意味）実測値、3 は計算で出す。
このような方法を取るわけですね。

参考になりました。
ありがとうございました。

129 ：NAME IS NULL：2007/08/14(火) 14:35:20 ID:???

>>126
そん時に入手可能なそこそこの金額のHDDにしておくので考えた事ない。

130 ：NAME IS NULL：2007/08/20(月) 00:28:04 ID:???

本格的にＤＢ（ＭｙＳＱＬ）を使ってサイトを再構成しようかと考えています。
サイト内容はいわゆる会員制サイトなのですが、構成を考えているうちに疑問な点が
あるので質問させてください。

質問：
リレーションシップが無いテーブルは別のＤＢに分けたほうが良いのでしょうか？

具体的にいいますと「会員情報」と「ログイン認証用(※)」テーブルの２つなのです。

「人間」的にはどちらも同じ会員が使用するテーブルなのですが、
「コンピュータ」的には「会員情報」テーブルはそれほどやり取りが多くない静的なテーブルで、
「ログイン認証用」テーブルは会員ページにアクセスするたび呼び出される動的なテーブルに
なると思います。

セキュリティ、パフォーマンスの面からご指導いただけるとありがたいと思います。

（※）セキュリティの為、ログイン時にcookieに「ID+ランダムな文字列」という情報を持たせています。
　　　それをログイン認証用テーブルで参照します。

131 ：NAME IS NULL：2007/08/20(月) 06:03:01 ID:???

リレーションシップがないからって別DBにしてたら別DBだらけになっちゃうよ。

セキュリティ、パフォーマンスを気にするにしてもDBを分けるという解に行き着くのは
相当なレアケースだと思う。
（特定のテーブルをEUC的に開放するようなケースしか思いつかない。）

132 ：NAME IS NULL：2007/08/20(月) 08:42:51 ID:???

DBを分けるかどうかは、物理設計/運用設計上の問題だね、基本的には。
特にOracleの場合は、1DB＝1インスタンスだから、DBを分けるということはインスタンスを分けるということになるので、
リソースの使用量が増えることになる。

133 ：NAME IS NULL：2007/08/20(月) 13:35:20 ID:???

いや1インスタンスで複数DB作れたよ。

134 ：NAME IS NULL：2007/08/20(月) 15:07:30 ID:???

それは勘違い。

135 ：NAME IS NULL：2007/08/20(月) 15:12:54 ID:???

あらそうなの？

同一インスタンス内で、
データベースリンク張ったりしたんだけど。
あれはデータベース同士のリンクって意味じゃないのか。

なんていうの？スキーマ？なら勘違いスマン。

136 ：NAME IS NULL：2007/08/20(月) 15:57:59 ID:???

Oraclerは大概インスタンスとデータベースをごっちゃにするよね（藁

137 ：NAME IS NULL：2007/08/20(月) 16:01:51 ID:???

Oraclerは大概データベースとスキーマをもごっちゃごちゃにするよね（藁々

138 ：135：2007/08/20(月) 17:15:56 ID:???

>>137
つまりそれが俺なわけだな。
つかオラクラーじゃないから勘違いしてるわけでして・・・。
あやまるからもういじめないで～

データベースリンクって言われたら
データベースとデータベースをリンクしてんのかと思うじゃん・・・。

139 ：130：2007/08/20(月) 23:19:53 ID:???

たくさんのレスありがとうございます。m(_ _)m

>>132さんも書かれたとおり、
「ログイン認証用」のテーブルを持っているマシンには負荷がかかると思い、
将来的にはパワーのある別サーバを用意してそちらに置こうかと考えていました。

当面はDBサーバを一台で運用できると思いますが、とりあえず両方試してみます。

140 ：NAME IS NULL：2007/08/26(日) 01:27:07 ID:???

>>135
オラクルのデータベースリンクは、分散システムの位置透過性を実現する機能。
なので、データベース同士のリンクって意味であってる。

また、１インスタンス＝１データベースが正しい。
ちなみに、オラクルでいうインスタンスとは、DBMSプロセス＋メモリ領域のこと。
データベースを構成するデータファイル群は含まない。
そして通常は、１インスタンス＋データファイル群＝１データベースと呼んでる。
　　　（複数インスタンス＋複数データファイル群＝１データベースもある＝RAC）

同一インスタンス内？（同一データベース内？）でデータベースリンクを張れるけど、
それは本来のデータベースリンクの使い方じゃない。（無駄なだけ）

141 ：135：2007/08/26(日) 01:43:26 ID:???

>>140
わかりました。

つまり俺が見たデータベースリンクは
本来の使い方じゃない奴って事ですね。
ありがとうございました。

１インスタンス＋データファイル群＝１データベース
ってのもわかりよかったです。

142 ：NAME IS NULL：2007/08/26(日) 10:30:18 ID:???

それだから、Oracleはサーバ統合が苦手なんだな。
別々のデータベースをそれぞれスキーマにして統合すると、バックアップのタイミングなど運用上の問題が出てくるし、
インスタンスを分けるとリソース（共有メモリなど）がばらばらのままなので、統合した意味が薄くなる。
DB2やSQLServerならサーバ統合に合わせて自由にインスタンスを整理統合できるので、リソースの使用効率が格段に上がる。

143 ：NAME IS NULL：2007/08/26(日) 12:53:26 ID:???

Oracleがそこまで便利になったらDB2の立つ瀬はないだろう。

と思いつつもOS/400のDB2はデータベース一個しか作れなかったな。w
まあ、アレはOSとRDBが融合しているので別モノだけど。

144 ：NAME IS NULL：2007/09/06(木) 01:37:58 ID:???

所詮コボラー専用箱だしな。
別途有料オプション購入で御賦せしないと他の鯖からSQLでアクセスできない囲い込み仕様。

145 ：NAME IS NULL：2007/09/06(木) 21:45:08 ID:???

OS/400はJavaの知識があればむしろ無料でSQLでアクセスでき
WASのBASEエディションとRationalの開発キットをタダでつけてくれる
IBM唯一の鯖なんだが。

むしろCOBOLer専用にすると返ってPCOMM端末のライセンスやら
洗濯機プリンターとか買わされるので高くつく。ｗ

まあ、>>144みたいな勘違いしているCOBOLerは現実に多いな。
そういうのを含めてAS/400の不幸なトコなんだろうなぁ。

146 ：NAME IS NULL：2007/11/18(日) 17:33:01 ID:U6M3l2gU

>>125
私はJOINが複雑なSQLを読みやすくするため、「XXXX_ID」みたいに命名しますけどね。
たくさんのテーブルを結合するときに「同じ列名、違う意味」があるとSQLが読みにくいので。

147 ：NAME IS NULL：2007/11/18(日) 22:35:52 ID:???

>>146
125=119
べつに「ID」って名前にするなんて話誰もしてないよ。

でも最近、「ID」って名前にするのが前提の
フレームワーク、結構あるんだよねぇ。

148 ：NAME IS NULL：2007/11/19(月) 01:40:31 ID:???

スレ違いのところに投稿してしまってレス付かなかったので教えてください。

項目が2000個ある場合など、どのようにテーブル設計すればよろしいでしょうか？

項目名：　　　値
-----------------
TEST-0001：123
TEST-0002：789
　：
　：
TEST-2000：999

149 ：NAME IS NULL：2007/11/19(月) 02:33:20 ID:???

どうもこうもねぇな

150 ：NAME IS NULL：2007/11/19(月) 02:40:17 ID:bf1DMNXI

わけわかんねｗｗｗ
取りあえず縦にもってるからそれでいいんじゃねぇの？
一体何を聞きたいかわからない

じゃがいもと肉がある場合どのように料理すればいいでしょうか
とそう変わらないとおもうぞ

せめて味付けの方向性とかイメージきめようぜ
焼くのか煮るのか　みたいな感じで

151 ：NAME IS NULL：2007/11/19(月) 03:01:56 ID:???

じゃがいもと肉ってわかってれば
カレーどう？とか肉じゃがどう？っていえる。

この場合、「フライパンがあるんだけどどんな料理作ったらいいですか」
くらいに空虚かと思う。

152 ：NAME IS NULL：2007/11/19(月) 23:10:41 ID:???

これ縦にもってるんじゃなくて
列が2000あるって言ってるんだろ？

TEST-0001列の値が123
TEST-0002列の値が789
　：
　：
TEST-2000列の値が999

列ごとにデータが1個しかなくてデータの増減がなければ
そのままで問題ないと思うよ
そうじゃなければデータ増えるごとにALTER TABLEして大変なことになるぞ

153 ：NAME IS NULL：2007/11/19(月) 23:20:11 ID:???

つかそんないっぱい列って作れるの？

154 ：148：2007/11/19(月) 23:54:49 ID:???

こんばんわ。>>152さんの通り、列が2000あるのです。
そもそも2000列も横並べするのは馬鹿っぽいなと思いつつ、相関性のないデータなので
正規化もできません。まあ、いいかとSQLServerでテーブル作成しようとしたら横は1024列が最大でした･･･。
さて、どうすればよいのでしょうか・・・？

今のところ、テーブルを二つに分割する以外思いつきません。どなた様かお知恵を拝借したく。

155 ：NAME IS NULL：2007/11/20(火) 00:06:27 ID:fOu30nsb

>>154
それがマスタなのか登録されるデータなのか
その辺はどうなんだ？
こういうのだったら
項目名カラムと　項目名別のシーケンス番号でキーにしたりすることもあると思うんだけど

項目名IDカラム＿項目名SEQカラム＿データカラム

TEST＿1＿内容1
TEST＿2＿内容2
TEST＿3＿内容3
・
・
・
・
TEST＿1999＿内容1999
TEST＿2000＿内容2000

156 ：148：2007/11/20(火) 00:13:43 ID:???

>>155
登録されるデータです。
↓これですと、一度の登録で2000行も追加されるのですよね？
10000回登録すると･･･行が増えすぎて不安です。

TEST＿1＿内容1
・
・
TEST＿1999＿内容1999
TEST＿2000＿内容2000

157 ：NAME IS NULL：2007/11/20(火) 00:43:47 ID:fOu30nsb

可能性として10000X2000　ほどはデータ登録の可能性があるってこと？
一体何のデータか抽象的すぎてわからないけど・・・
10000X2000ほど新規登録が発生するとしたら結構な量だなぁ…

まずは想定できるデータの規模をみんなに示してみては？
あまりに漠然としすぎて>>155程度のことしか言えなかったんだが
設計をするのであれば自分が持っている情報を出来るだけ伝えてほしい

158 ：NAME IS NULL：2007/11/20(火) 01:25:28 ID:???

XXX300位までは見た事あるけどなぁｗ
どんなデータなんだろう

159 ：148：2007/11/20(火) 01:57:12 ID:???

具体的には説明できないのですが、例えばで説明すると･･･ある工場用の自動荷物仕分けシステムです。
各配送先(この場合2000箇所)の振り分け数をチェックし、その件数が蓄積されるとしてください。

配送先1　　配送先2　･･･　　配送先2000
120件　　　　140件　　　　　　　　90件

これを週に１回集計します。
同様のシステムが１００００台あります。

このような感じです。

160 ：NAME IS NULL：2007/11/20(火) 05:17:27 ID:???

>>159
その例なら列はまずいでしょ可変情報過ぎる。
入力元工場が1なのか複数なのかにも関わってくるし、
抽出要件として過去参照がどこまでさかのぼるのかにも

過去参照がないのであれば集計後DELETEとか
n週の過去参照であれば履歴テーブルを用意するとか
過去全参照だと・・・集計テーブルに集計データのみ残してって感じかな・・・
どれにせよ、そのテーブルは最大で2000*7*n工場のデータ数になるんじゃない？

161 ：NAME IS NULL：2007/11/20(火) 12:17:36 ID:AlZxTldT

テーブル数2000*7*n工場ってマジで言ってんの

162 ：NAME IS NULL：2007/11/20(火) 15:56:36 ID:fOu30nsb

そのDBへの挿入や更新はリアルタイムじゃなくて夜間バッチとかでやるような処理じゃないのか？
それだったら別に1000万件とかでも平気だろ

リアルタイムにやれとか言われたらかなり悩むけど

163 ：NAME IS NULL：2007/11/20(火) 20:08:46 ID:???

各システムは必ず2000件の配送先を持つのか。
2000件の配送先は増えたり減ったりする可能性は考えられないのか。
1万システム全体での配送件数が1日平均何件なのか。

例えばこれが全体で配送件数が5000件であれば、
配送件数として1日に増加するレコード数は最大5000にしかならない。
さらにもし1配送先に平均10件と仮定すれば
記録すべき配送先は500先なので1日で500レコード増加するに過ぎない。
(横持ちせずに(列で持たずに)、縦に持つようにした場合の話です。)
と、思うがどうか。

164 ：NAME IS NULL：2007/11/20(火) 20:38:55 ID:wWhiZNbu

パソコンショップならここ！！
http://want-pc.com

165 ：あぼーん：あぼーん

あぼーん

166 ：NAME IS NULL：2007/11/21(水) 01:04:15 ID:ejwf2SGm

横持ちしない場合ってこんなんだと思うけど、集計とかやりやすいのかな？素人なんだけど俺
ID　配送先　値
：　　：　　　　　：

167 ：bomtNmsCJ：2007/11/24(土) 04:00:24 ID:???

http://cqiycu.cn/ legal mp3 download

168 ：AANOlxiodCsz：2007/11/24(土) 12:07:43 ID:???

http://bdzwbn.cn/happy-mp3 happy mp3

169 ：dqGHtpsdsnzLW：2007/11/27(火) 18:49:28 ID:???

qdcfAp <a href="http://ztphhovihfnd.com/">ztphhovihfnd</a>, [url=http://aapgkojubcll.com/]aapgkojubcll[/url], [link=http://osatiejwhmbj.com/]osatiejwhmbj[/link], http://wigfjztncgof.com/

170 ：NAME IS NULL：2007/11/28(水) 16:44:05 ID:yMQT4KPq

なんかの本だかサイトで主キーのないテーブルはいかん！
って見た気がするんですけど、

今、設計してて
WEBのアクセスログを取るテーブルに主キーがいらない気がするんですよね。

削除はこの日付より前のものって感じでcronで削除するのでいらないし
selectもgroup byとcountで集計しかしないので（index使われないですよね？たぶん・・・）

どうなんでしょう？
そういう設計はまずいのでしょうか？

171 ：NAME IS NULL：2007/11/28(水) 16:55:14 ID:+hnShCQ+

別にいいんじゃね？

172 ：NAME IS NULL：2007/11/28(水) 17:15:29 ID:???

困ってなきゃいいんじゃない？

173 ：NAME IS NULL：2007/11/28(水) 19:33:39 ID:???

それならいらねーんじゃね？
一日に１回くらいしか集計しないんだったらインデックスやらキーを
つけるほどの事でもないし。

ただまあ、最近はフレームワークとかで主キーがあると
ﾗｸﾁﾝになるのもあるので、Webの画面に表示してどうこうする
テーブルとかは普通に主キーを設定しておく方が無難ではあるな。

174 ：NAME IS NULL：2007/11/29(木) 01:36:40 ID:DGmlyzPU

大量のデータの場合、検索が遅い。
結局、DBMS側も一意のキーが特定できないと辛いのです。
経験則からなら○百万件以下のDBなら何も問題ないっす

175 ：NAME IS NULL：2007/11/29(木) 02:02:10 ID:???

ログなんだからそのうち○百万件超えるだろ

176 ：NAME IS NULL：2007/11/29(木) 03:16:51 ID:???

>>170
つーか、集計しておしまい程度のログを、
わざわざDBにログ突っ込む必要ないのでは？

177 ：NAME IS NULL：2007/11/29(木) 13:40:04 ID:???

これなんかいいよ
ttp://www.forest.impress.co.jp/article/2003/02/14/okiniiri.html

178 ：huvOJjLyYD：2007/11/29(木) 20:15:08 ID:???

http://zerozeroone.at.tut.by/orgii-ska4at-besplatno.html ⅱ肛? 璞瑣? 砒?瑣濵
http://zerozeroone.at.tut.by/besplatnjie-foto-orgij.htm 砒?瑣燾?  ⅱ肛?
http://zerozeroone.at.tut.by/porno-orgii-besplatno.html ?ⅱ濵 ⅱ肛? 砒??瑣濵
http://zerozeroone.at.tut.by/ljubitelskoe-foto-gruppovogo-seksa.html ?�礪??鮱  胙?魵魲? ?
http://zerozeroone.at.tut.by/gruppovoe-porno-video.html 胙?魵鮱 ?ⅱ濵粨蒟?

179 ：iTrTZQkcEuofEmTr：2007/11/29(木) 21:10:04 ID:???

http://zerozeroone.at.tut.by/besplatnjie-foto-orgij.html 砒?瑣燾?  ⅱ肛?
http://zerozeroone.at.tut.by/porno-orgii-besplatno.html ?ⅱ濵 ⅱ肛? 砒?瑣濵
http://zerozeroone.at.tut.by/orgii-video-besplatno.html ⅱ肛? 粨蒟? 砒?瑣濵
http://zerozeroone.at.tut.by/besplatnoe-porno-foto-orgii.html 砒?瑣濵? ?ⅱ濵  ⅱ肛?
http://zerozeroone.at.tut.by/dikie-orgii.html 蒻?韃 ⅱ肛?

180 ：ORYqhlickQwwoRu：2007/11/30(金) 00:22:20 ID:???

http://zerozeroone.at.tut.by/grupovuha-porno.html 胙魵? ?ⅱ濵
http://zerozeroone.at.tut.by/seks-grupovuha.html ?? 胙魵?
http://zerozeroone.at.tut.by/ska4at-grupovuhu.html 璞瑣? 胙魵?
http://zerozeroone.at.tut.by/domashnie-fotki-grupovuhi.html 蒡?璧湜? ? 胙魵?
http://zerozeroone.at.tut.by/grupovuha-video.html 胙魵? 粨蒟?

181 ：NAME IS NULL：2007/12/17(月) 00:26:40 ID:???

５年分のログを記録とかだと、DBに突っ込んでおかないと軽く死ねるよ。
あと膨大な規模／台数を対象にログをとるとかさ。

おまいのところのちっぽけなサーバのログ取り程度じゃない世界もあるよ。

182 ：NAME IS NULL：2007/12/17(月) 07:27:05 ID:???

ＤＢにつっこまないと死ねるｱﾌｫな職場環境の方が死ねると思うが。

ｱﾌｫ構成を自慢されてもな。

183 ：NAME IS NULL：2007/12/18(火) 07:06:27 ID:???

ログをテキストで持ってて全文検索してる職場環境がゴミ。
オラクル動かしてる鯖のログなんて見てないのか(w

184 ：NAME IS NULL：2007/12/18(火) 19:27:37 ID:???

質問があります。
類似の項目が可変＆多数ある場合どう設計すればいいでしょうか？

例えばイベント情報DB（一覧表示がメイン）で、
時間：必須は開始と終了時間のみ。他に開場時間や最終入場時間などが追加の可能性。
料金：当日・前売、席、男女、年齢などで異なり、且つ最低どれか１つが必須。
名称(イベントや会場)：正式名・一般名称・略称があり、詳細表示は全て、一覧表示は後者2つのどちらかを使用、など。

今は下記で考えています。
■基本テーブル
主ID/日付/開始時間/終了時間/他の時間リスト/会場ID/正式名/一般名称/略称/料金リスト/…
■会場テーブル
会場ID/正式名/一般名称/略称/住所/地図/…
●一覧表示時
主ID/日付/開始時間/終了時間/会場名(一般名称か略称)/イベント名(一般名称か略称)/料金(一部)/他の時間(一部）/…
●イベント詳細表示時
主ID/日付/開始時間/終了時間/他の時間(全て)/会場名３種類/イベント名３種類/料金(全て)/…

名称の重複は仕方ないとしても、時間・料金・割引をどうするか悩んでます。
各項目をすべてフィールドで用意すると空項目が多く無駄になるので、
可変部分は１つのフィールドにまとめて(○○リスト)、プログラム側での展開・処理を考えています。
（「開場#9:00 最終入場#16:00 △△時間#20:00 …」としてスペースと#で分割とか。）
ただ検索が大変そうで…。

よくあるケースと思いますが何か定番の方法あるのでしょうか？

185 ：184：2007/12/18(火) 19:28:38 ID:prFbnylX

すみません。sageてしまいました

186 ：NAME IS NULL：2007/12/18(火) 23:19:51 ID:???

>>184
頭んなかでアプリとDBがごちゃまぜになってないか？
名称の重複とかDB側では見当たらんし・・・

時間：
素直に開場時間や最終入場時間など用意しておいた方がいい
料金：
ちょっとメンドクサイね。
ホントにその条件なのか？当日・前売とその他が同列っておかしいくない？
名称(イベントや会場)：
何を悩んでるのかわからない上に仕様不明確。DB設計よりもアプリ側の話

ところでリストってArray型？差し支えなければDB教えてくれんか？

187 ：NAME IS NULL：2007/12/20(木) 16:54:20 ID:F1yzUOQD

>>184
RDBで可変は限界がある。

無駄になると思いつつ空ばかりのレコードを作るか、
もしそれがいやならカンマ区切り等のセパレータで
区切られた文字列をつっこんでアプリで処理するのが一般的。

アプリ側の処理をある程度許容するのであれば、
まとめたい部分をテキストファイルにして、DBにはファイルパス
を入れておく。こうすると検索については全文検索に任せればいい。
SQLのLIKE文とどっちが速いかは分らん。

おすすめはデータベースを設計してみて容量見積もりをする。
その容量が許容できないほど大きいのであれば、どこかに
制約をつけるしかない。

Object Databaseっていう手もあるが、技術情報・技術者が
少ないのと速度見積もりが難しいので商業戦略としては
使いづらい。

188 ：NAME IS NULL：2007/12/21(金) 00:12:35 ID:???

そんな糞設計が一般的なわけがない

189 ：NAME IS NULL：2007/12/21(金) 12:00:45 ID:9gvFSqQa

カンマ区切り等のセパレータで
区切られた文字列をつっこんでアプリで処理するのが一般的。

これにはたまげたｗｗ

190 ：NAME IS NULL：2007/12/22(土) 14:25:55 ID:???

>空項目が多く、無駄になるので

空項目が多く、無駄になるのが一般的です

191 ：NAME IS NULL：2007/12/23(日) 01:46:00 ID:???

このスレってほんと投げられっぱなしだなｗｗｗ

192 ：23453030：2007/12/23(日) 02:39:57 ID:???

こんな感じでどうだ。

■基本テーブル
イベントID/日付/会場ID/正式名/一般名称/略称/料金リスト/…

■スケジュールテーブル
イベントID/スケジュール名（開始・開場・最終入場・...・終了）/時間/一覧フラグ
※一覧フラグは、一覧表示画面に表示するかどうかをあらわす

▼開始時間ビュー（select イベントID, 時間 from スケジュール where スケジュール名 = '開始'）
▼終了時間ビュー（select イベントID, 時間 from スケジュール where スケジュール名 = '終了'）

■料金テーブル
イベントID/料金名（当日・前売、席、男女、年齢）/料金/一覧フラグ
※一覧フラグは、一覧表示画面に表示するかどうかをあらわす

■会場テーブル
会場ID/正式名/一般名称/略称/住所/地図/…

193 ：NAME IS NULL：2007/12/23(日) 04:37:05 ID:???

可変カラムがあったらどうやるの？
カラムが増えたらALTERするの？

194 ：NAME IS NULL：2007/12/23(日) 06:54:17 ID:???

>>193=187
無知なだけかも知れんが可変カラムって聞いた事無いんだけど・・・
アプリ要求とTableを対にするって発想でも無さそうだし、理解が出来ない。

COL1=A,B,Cとして持たせるって
AをSQL条件とする検索とかの仕様変更来た場合はどうするつもり？
このやり方でカラム増やしたってシステム上改修は必須で、逆にCOL1のデータへのアクセス部分の調査が必要になるでしょ？
COL1で対応できない要求された場合はALTERなりで拡張するんでしょ？

わざわざ難しくしてるようにしか見えない

195 ：NAME IS NULL：2007/12/23(日) 08:41:31 ID:???

>>193
最初の要件で可変であることがわかっている属性があるならそのように設計する。
後から出てきたものなら設計変更。

196 ：NAME IS NULL：2007/12/23(日) 12:12:04 ID:???

>>187
>>193

リレーショナルモデルにおいて、属性が可変なんてありえん。

197 ：184：2007/12/24(月) 16:26:34 ID:???

遅くなってすみませんm(_ _)m

>>186
●名前の重複：　名称の一部が重なる事です。例えば↓など。
　・東京モーターショー2007／東京モーターショー／TMS　(「東京モーターショー」が重複)
　・東京国際展示場／東京ビッグサイト／BS　(「東京」が重複)
●時間：　開始・終了時間以外は稀(200件に1件以下)と思うので個別だとほとんど空状態で無駄な気がします。
●料金：　入場の料金、○○の料金、…と分ける必要ないので同列でいいかと。

リストとは項目を連結させた文字列(TEXT型)。187氏のカンマ区切り文字列と同じです。DBはMySQL(レンタル鯖)。

>>187
的確なアドバイスありがとうです。

カンマ区切り文字列については意見色々ありますね。、
可変項目はよくありそうですが実際はどう対処してるんでしょ？
（検索対象なら個別に用意すべきでしょうが、検索不可だが必要な場合など。）
最初はPostgreSQLの配列型で出来ないかと考えてました。

>>192
以前はそれに近い考え(可変カラムを外部テーブルへ)でした。
（基本TBL「イベID/日付/会場ID/…」、時間TBL「イベID/時間名ID/時間」、時間名TBL「時間名ID/時間名」…）
正規化としては正しそうですが、一覧表示は問合せが1行(1イベント)ごとに発生して遅くなりそうで。

結局現時点では、
１）　時間と料金は検索不可にしてカンマ区切り文字列を使用。
２）　会場名やイベント名は置換と省略可能な書式にしてアプリ側で正規表現処理。
と考えてます。（>>184とは検索不可と会場名・イベント名を3種類から１つにまとめただけの違い）

ところで一覧表示で1行(1イベント)毎に会場名などを外部テーブルに問い合わせると遅くないですか？
（1行ごとに3件ほど外部テーブルへ問合せ。1ページ約100行なので300回。）
基本テーブルに会場名称を会場IDとともに登録して、表示は名称、検索はIDにしようと考えてるのですが。

198 ：23453030：2007/12/25(火) 00:14:17 ID:???

正規化は知ってたのか。
だと、実務経験があまりないのかな。

正規化するとパフォーマンスが心配というなら、
「外部テーブル」が何件くらいになりそうか
見積もってみれば。

MySQLも含めていまどきのデータベースなら、
数万件から数十万件のテーブルから数件のデータを
とってくるのは一瞬のはず
（DBの先人は、そういうデータ取得を
高速化するためにまっさきに工夫してきたので）。

データがそれより大きい場合、いろいろ
考えなきゃいけないかも。でもその場合でも、
正規化したデータを前提にしたDBの
パフォーマンスチューニングが正道。

天才プログラマなら、ユニークな
方法で大成功するかもしれないけど、
そうでないなら教科書通りにやるのが吉。

199 ：NAME IS NULL：2007/12/25(火) 00:29:12 ID:???

>>197
おまえ様は、RDBでの設計知識は全然ないだろ。アプリ屋だね。
RDBなんだよね？SQLって知ってる？結合(JOIN)ってわかる？
ごく普通にJOINすれば良いだけだろ？

なんで、一覧表示するのに、イベント１行検索して、その後、会場名検索するの？
SQL一発で、イベントも会場も時間も全部入で１００行でも１億行でも拾えるだろ。
それとも、そのレン鯖はJOINのコストが気になる様なマシンスペック&
データ量なのか？

200 ：NAME IS NULL：2008/01/07(月) 19:35:26 ID:ivk9xsoC

マスタって例えばどんなデータが対象になるんでしょうか。
定型的なパターンとかありますか？

201 ：NAME IS NULL：2008/01/08(火) 03:53:42 ID:???

なんと難しい質問。

人間って何？って言われてるみたいだ。

202 ：NAME IS NULL：2008/01/08(火) 03:57:59 ID:???

とかいうのもなんなので、定説みたいなのは、
～名ってつくものはリソース、つまりマスタとみなす、
なんてよくいいます。

顧客名、ユーザー名、などなど。必ずしもそうではないんだけど。
まあ考え方の目安として。

逆に、マスタじゃないのはトラン系とかイベント系とかいって
～日ってつくもの。

受注日、出荷日とか。

てな答えでいいのかなあ・・・。すげー難しい質問だ。

203 ：NAME IS NULL：2008/01/08(火) 04:02:31 ID:???

すんません、>>202はちょっと言葉たらずだった。

顧客名、ユーザー名、って～名がついてもおかしくないので
「顧客」や「ユーザー」はマスタ系テーブルと見なしてもいいかもしんない。

受注日、出荷日、って～日がついてもおかしくないので
「受注」や「出荷」はイベント系テーブルうんぬん。

って事です。
上のだと、「顧客名」って属性だけがマスタと呼ぶ、みたく思われ可燃。
要は「もの」と「こと」って事かと。

204 ：NAME IS NULL：2008/01/09(水) 00:57:55 ID:???

業務的に帳票化して管理しているようなデータ集合をマスタって読んでることが多いな。
個人的にはマスタって言葉に違和感を感じるが、業務を遣ってる現場の連中がマスタって呼んでるので合わせてる。

正規化ってあんまり気にしなくても実害は少ないと思う。
コボラーとか旧世代の作った業務システムのデータなんて何万列も一つのテーブルで存在して正規化以前の状態で業務で使われてたりするし、
設計、開発当初はきっちり正規化してみたけど、現場の声でこのデータも欲しいと列をどんどん追加していったら、あんまり正規化されなくなってしまったなんて状況もあったりするし。
定期的にシステム更新して、正規化した構成に改善していくのが理想とは認識していても、現実は遣れてなかったりする。
正規化したからって売り上げに直接響くような資料を作って決済もらうのって、なかなか難しいし。
それより、パフォーマンス改善策として、より性能の高いハードウェアに更新しますって理由の方が予算／契約は取りやすい。

205 ：NAME IS NULL：2008/01/09(水) 10:07:22 ID:???

>>204
俺もトラン、マスタって嫌い。
イベント、リソースだとわかりやすい。

正規化しなくても実害が少なく思えるのはね、
DBのクソ設計をアプリで一生懸命カバーしてるからで
そのアプリを残業しながらメンテしたりしてる人達がいるって事だよ。

転職前の俺がそうだったもん。

206 ：NAME IS NULL：2008/01/09(水) 11:06:48 ID:???

その非正規化を否定することって、自分を否定してるようなもんだね。
それで飯食ってたんだから・・・。

207 ：NAME IS NULL：2008/01/09(水) 13:14:05 ID:???

自分を否定する事なんかしょっちゅうだよ・・・。

つか、否定しようとしないから色々と大変なんだろう？
今までネットワークDBでやってきた自分のやり方とか、
そのままRDBに適用したり。

208 ：NAME IS NULL：2008/01/10(木) 06:59:11 ID:???

コボラーなんて古い設計を否定せずに使い続けるしなあ。
コボラーの進化って止まってる(w

209 ：NAME IS NULL：2008/01/11(金) 17:00:48 ID:7xR6a2PU

しかし、コボラーの設計思想というのは、
スタイリッシュではないが、何が起きても大丈夫なような安心感がある。
あれこれ頭を痛めるよりは、淡々と進めた方がいい場合もある。

210 ：NAME IS NULL：2008/01/11(金) 17:36:39 ID:???

>>209
違うよ。何が起きてもどうにかする人が居るんだよ。

設計自体は、わざわざ何かが起こり得るようになっている。
最初に頭痛めれば起こり得なくなる何かが。

211 ：NAME IS NULL：2008/01/11(金) 22:19:23 ID:???

＞スタイリッシュではないが、何が起きても大丈夫なような安心感がある。

安心感と言うか、感覚がズレてる感があるな。
ホストからの電文が一部ロストしたら、その後のキューにたまった電文が
全てズレで帳票印刷されて、壮絶な障害が発生した事があるんだが、

　　　　　　　　　　　　　「　そ　れ　は　仕　方　な　い　な」

と力強いコメントいただいた事がある。

ｱﾌｫかと

212 ：NAME IS NULL：2008/01/11(金) 22:49:25 ID:???

証券システムの日米比較で、「スペースシャトルと乳母車」に例えられるくらい、日本の汎用機コボラーはショボイ。
殿様抱え込み商法の超ぬるま湯団塊親父の吹き溜まり。

213 ：NAME IS NULL：2008/01/12(土) 05:43:07 ID:???

安心感は全くないな。
列が何万行もあって、明らかに遅くなるテーブルを、何の疑問すら持たずに使い続けてるだけだよ。
コボラーの空気読めなさは異常。

テーブルの正規化でパフォーマンス改善できるのに、ひたすらハードウェアの性能でパフォーマンス改善しようとする。
そこそこ早い鯖なのに、遅いからしょうが無いとか言い出すし。コボルで組んだお舞らのバッチが遅いだけです(w

214 ：NAME IS NULL：2008/01/12(土) 06:32:28 ID:???

重くてもしっかり動けばいいんだけど、やつらは付け焼き刃のバベルの塔を築くからなあ。
自分しか分からない（自分でも？）ようになっちゃって、既得権益を守ってきた。

215 ：NAME IS NULL：2008/01/12(土) 18:12:29 ID:???

その方が高い鯖売り逃げることが出来るからな
ベンダとしてはコーダーを文盲統治したいところ

216 ：NAME IS NULL：2008/01/12(土) 23:02:12 ID:???

技術的に正しいことが必ずしも商売として正しいとは限らないという事か

217 ：NAME IS NULL：2008/01/13(日) 00:07:35 ID:???

>>211
>「　そ　れ　は　仕　方　な　い　な」

これで済むのか！無茶苦茶安心だ！

218 ：NAME IS NULL：2008/01/13(日) 00:09:06 ID:???

>>216
短期的にはそうだねぇ。

でも長期的にはいつかツケが回ると思ってる。
特に中小は。

219 ：NAME IS NULL：2008/01/13(日) 06:22:29 ID:???

>>218
そのツケが大きいところまで回ってきたのが、東証全面ストップ。
これも付け焼き刃で対応している筈なので、遅かれ早かれまた大規模な障害が出る。
そして東京市場が見捨てられている。

220 ：NAME IS NULL：2008/01/13(日) 22:45:20 ID:???

長期的な視点があってもそれまで生きていなければ意味は無いから絶妙なバランスが必要だな。

つい読んでしまったけどこれマ板ネタじゃね。

221 ：NAME IS NULL：2008/01/13(日) 23:57:38 ID:???

>>220
短期を乗り越えられるだけの現金は持っておけ、とか。
理想論かな・・・。

222 ：NAME IS NULL：2008/01/14(月) 01:46:46 ID:???

東証のダウソや誤発注が通ってたのってコボラーの仕業なのか。
仕方ないねって平気で言いそうだ(w

223 ：NAME IS NULL：2008/01/14(月) 13:00:27 ID:???

凍傷は不治に損害賠償求めたんだっけ

224 ：NAME IS NULL：2008/01/17(木) 17:10:23 ID:???

すみません売掛金計算方法について助けてください。

販売管理のDB設計をしています。
日々、販売するごとに価格、売上数を売上テーブルに入力していっています。
また、売上の入金があるたびに、入金額を入金テーブルに入力していっています。

このとき、販売先別の売掛金や請求額、またその繰越残高を算出するために、
皆さんはどうやっていますか？
1日から月末までの計算ならいいのですが、請求額などは販売先ごとに締日が違っていて、
単純に計算するのは難しく悩んでいます。

自分の考えでは、
１）過去の売上テーブルの売上額の総合計－過去の入金テーブルの入金額の総合計＝売掛残高として計算する。
２）売掛テーブルを作成し、月イチや毎日のバッチ処理で、その月の売上合計と入金合計を売掛テーブルに保存する。
そして売掛テーブルの売上げの総合計－売掛テーブルの入金の総合計＝売掛残高として計算する。
３）売掛テーブルを作成し、月イチや毎日のバッチ処理で、その月の売上合計と入金合計を売掛テーブルに保存し、
さらに前月繰越額も計算して同じレコードに保存する。
の３つが考えられそうな気がしています。

ただ、１）だと締日が異なる販売先を一覧で表示する場合には、union等を使った複雑なクエリになりそうですし、
３）だと過去のデータを変更されると、それ以降の繰越額が全部ズレてくるので、それをすべて
修正しなければならず、２）が妥当なやり方のように考えているのですが、皆さんはどうしておられますか？

225 ：NAME IS NULL：2008/01/17(木) 17:28:25 ID:???

>>224
俺なら、同時更新(リアルタイム) と日バッチ(チェック＋補正)で作るかなぁ。。。
DBだけでなんとかしようとしないと思う。

アプリでなんとかするｗ
アプリの話は、すれ違いになりそうなのでやめとくね。

226 ：NAME IS NULL：2008/01/17(木) 18:06:24 ID:???

締月属性用フィールド追加

227 ：NAME IS NULL：2008/01/17(木) 18:13:03 ID:???

あまり深く考えないで答えると、売掛金って勘定なんだから
そこには締めの概念が社内にかならずあるはず。

なので２。

請求先の締め日は、いつお客さんに請求書を送るかに関わるところだから、
債権管理には関係ないんじゃない？
社内の管理会計は当然その社の締めに基づいてされるはずだし。
どういう帳票を出したいのかがどうもイメージできない・・・・。

228 ：NAME IS NULL：2008/01/17(木) 19:46:21 ID:???

>>225
ありがとう。自分もソフト側での更新も考えてます。
ただ、その時のDB設計はどうなのかと思いまして。
詳しくは下記の>>227さんへのレスを参照してください。

>>227
ありがとう。自分も2が適当なのかなと思っていたのですが、不安で・・。
ちょっと質問の仕方が適当でなかったかもしれません。
つまり、売上テーブルに販売数×販売価格を保存し、入金テーブルに入金額を保存していくとき、
売掛金を計算する場合に、皆さんはどのようにされているか、そしてそれを選択した理由が
何かをお訊きしたいということです。

１）売上テーブル、入金テーブルから、ある販売先のレコードを全て抽出し合計値から計算する

２）１）だと膨大な数になりそうなので、集計テーブルを用意し、そこに月ごとの売上金額と
入金金額をまとめた数値をバッチなり、同時更新なりで計算し保存していく。
イメージ的には「集計ID, 売上年月, 販売先ID, 今月の売上金額, 今月の入金金額」となる感じで、
これをsumすることで１）と同じ要領で売掛金を計算する。

３）やり方は２）と同じですが、フィールドを
「集計ID, 売上年月, 販売先ID, 今月の売上金額, 今月の入金金額, 前月の繰越金」とし、
やはりバッチなりリアルタイム更新で保存していく。
ただし、この場合は、前月繰越金＋今月の売上金額－今月の入金金額を計算すればｏｋ。

ですが、問題もあって、
１）データ件数が多くなると計算が遅くなりそう
２）１）ほどではないが、1ヶ月ごとに販売先の数だけレコードが作られるとやはり遅くなる？
３）計算は速そうだけど、過去のデータを修正すると、それ以降の繰越金がすべて再計算になる。
ということになりそうなので、果たしてどれがいいのかと、お知恵を貸していただきたかったわけです。

>>226
すいません。締月属性用フィールドという意味がよくわからないので、
よければ詳しく教えてください。

229 ：NAME IS NULL：2008/01/18(金) 10:27:58 ID:???

2のバッチでのサマリーテーブル生成を選択した
最大の理由は、パフォーマンス対策です。
そのためにあえてone fact in one placeの原則をやぶるわけです。

債権残ってのは過去全ての取引の蓄積であって
そんなもん都度サマってたら、何年かして死んじゃう。

ついでに前月繰越残（要するに前月データ）も並べてもっておくと帳票出す時に楽。
うーん、これは異論ありそうだなあw
でも管理会計帳票って重くなりがちなんでこれくらいは許して欲しい。

230 ：NAME IS NULL：2008/01/18(金) 11:00:55 ID:???

>>229
なるほど、ありがとう。実質的には３）のやり方ですね。
ただ、３）だと、仮に過去の編集を許すとすると、それ以降の繰越金が全部変更になりますね。
まぁ、リアルタイム更新でなくて、バッチ処理なら問題ないし、
そんなに重い処理にはならないと思うけど・・・。

ひょっとしたらフィールドは２）の方法保存していき、
ビューで前月のレコードを表示させるようにすれば計算も速そうだし、
リアルタイム更新にも対応できそうだし、いいのかな？

集計　：　集計ID. 今月売上, 今月入金, 集計年月　とすると

SELECT 今月売上, 今月入金,
(SELECT SUM(集計2.今月売上)-SUM(集計2.今月入金) FROM 集計 AS 集計2 WHERE 集計2.集計年月 < 集計1.集計年月) AS 前月繰越
FROM 集計 AS 集計1 WHERE 集計年月 = '2008/01/31'

いい方法なのだろうか･･･(；´Д｀)ｳｳｯ…

231 ：NAME IS NULL：2008/01/18(金) 13:47:58 ID:???

>>230
締めた後の過去の編集なんて、そもそも業務としてまずい。
普通は赤黒処理して当月側で処理します。
会計締めってそれだけタイトな業務なはず。

本来なら、ですけど。

そこまでの要望がない軽いシステムってのもあるだろうから
そうならどういう作りしてもどうとでもなりそう。
あとは好みなんじゃない？

232 ：NAME IS NULL：2008/01/18(金) 13:53:53 ID:???

連投すまんですが、
まずはお客さんに過去売上の修正について
管理会計上どう処理してるか聞くのがいいと思うよ。

俺のお客さんでやっぱり適当に過去の売上いじってて
会計は会計事務所まかせになってて
いじった過去の売上をそのまま事務所に伝えてるだけってのがあった。
会計事務所側では恐らくちゃんと当月側で打ち消し仕訳起こしてるはずで
そうなると、月次の会計データと社内の売掛金データに食い違いが
出来てるはずなんだけど、それで仕事は回ってんだからいいんだ、って話になった。

しかも法律事務所。

233 ：NAME IS NULL：2008/01/18(金) 14:51:24 ID:???

データベース設計ツール探してるんだけど、何かないだろうか？
dbwrenchとか
SI Object Browser ER 4
みたいなソフトで、フリーなのがないかなあと。
できれば日本語ドキュメントの生成も対応していて。

234 ：NAME IS NULL：2008/01/18(金) 17:37:03 ID:???

TOADは？

フリーのはみんな記法がいまいちでなー。

235 ：NAME IS NULL：2008/01/18(金) 20:15:02 ID:???

>>233
dbdesignerは？

236 ：NAME IS NULL：2008/01/25(金) 19:31:34 ID:yAWOBhhy

今、渡辺幸三さんの「業務別データベース設計のためのデータモデリング入門」という本を読んでいるのですが、
作出属性というのがよくわかりません。他の列の値を使って計算した結果がはいる列のようなもののようですが…
OracleやSQLserverなどでテーブルを作るときには固有属性の列などと同じように作るのでしょうか？
計算した値はどうやって入れるのでしょうか？

237 ：NAME IS NULL：2008/01/26(土) 00:12:43 ID:???

「作出属性」はその人の造語じゃないの？

たぶん、SQL-Server の計算列みたいなものかと。

> OracleやSQLserverなどでテーブルを作るときには固有属性の列などと
> 同じように作るのでしょうか？

Oracle は知らんけど、SQL-Server なら Yes.

> 計算した値はどうやって入れるのでしょうか？

列を定義する時に、式を定義しておくと計算結果が自動的に入る。

と言うか、実体はなくて select した時に計算して列を作る。

とりあえず、SQL-Server 計算列でぐぐれ

238 ：NAME IS NULL：2008/01/26(土) 01:32:14 ID:uG1o+X6G

>>237
有難うございました。計算列（仮想的な列）を　列名 AS 計算式　で定義しておけばselect時に計算してくれるのですね。
これは親テーブルなどの列の値を計算式に使ったりもできるのでしょうか？

239 ：NAME IS NULL：2008/01/28(月) 10:24:24 ID:???

渡辺さん、本人に聞けば教えてくれるよきっと。

240 ：NAME IS NULL：2008/02/10(日) 06:01:35 ID:tRxMhI5F

今やってる仕事なんだが、せっかくデータベース使っているのに、
一部のデータをテキストファイルで持っているんだが、こういうのってよくある話なんですか？

具体的にいうと、商品テーブルというのがあって以下のカラムを持っている。
・商品コード
・商品の種類

商品名が無いので、どこにあるかと思ったらテキストファイルに以下のように格納されてた。
1,コカコーラ350ml
2,みかん
3,餃子

担当者に何でテキストファイルにもっているのか聞いたら、
「作ったのは俺じゃないから知らないけど、優秀な技術者が作ったので何かしら意味はあると思う」
と言われました。

テキストファイルにデータを持つというのはよくあることなんでしょうか？
メリットがあるとしたら何でしょうか？

241 ：NAME IS NULL：2008/02/10(日) 06:18:56 ID:???

>>240
ありがちなのはそのシステムがさらに古いシステムからのリプレースで、
仕様書がなくよくわからないところはそのままにしとこうなど安易な理由で、
旧プログラムやロジックをそのまま使うためにそういうのを残すことがある。
CHAR(80)なフィールドにCOBOLの固定長レコードをぶち込んだだけのテーブル
がごろごろしてたのを見たときは逃げたくなった。まさに底辺。

242 ：NAME IS NULL：2008/02/10(日) 10:17:15 ID:???

Oracleだと、漢字の読みでソートというのができたと思うけど、
例えば、
安部（あべ）
木村（きむら）
斉藤（さいとう）
のように。
MySQLでこういうのはできる？

243 ：NAME IS NULL：2008/02/10(日) 11:04:38 ID:???

社会保険庁じゃないんだから
読みのフィールドを持てば済む話

244 ：NAME IS NULL：2008/02/10(日) 11:19:57 ID:???

>>242
Oracle、そんなことできんのか？

245 ：NAME IS NULL：2008/02/10(日) 12:11:11 ID:???

萩原さんと荻原さんの区別はどうするんだろうか

246 ：NAME IS NULL：2008/02/10(日) 12:39:05 ID:???

て言うか、エスパーじゃないんだから振り仮名なしで

| 神戸 (こうべ、兵庫県)
| 神戸 (ごうど、埼玉県川口市)
| (他にもがうど、かうど、かど、かのと、かみど、かんど、かんべ、ごうと、
| こうど、ごうどう、ごおど、ごおと、じんごとかがあるらしい)

とかをどうやってソートしろと言うんだ？

247 ：NAME IS NULL：2008/02/10(日) 13:23:12 ID:???

その辺は気合いで．

とか言う設計者が多摩にいるから困る．

248 ：NAME IS NULL：2008/02/10(日) 14:08:15 ID:???

渋谷にもいるぜ

249 ：NAME IS NULL：2008/02/10(日) 14:29:14 ID:???

>>240
工数と条件の間で苦心した結果の可能性は捨てきれないけど
>「作ったのは俺じゃないから知らないけど、優秀な技術者が作ったので何かしら意味はあると思う」
こんな事言う奴の「優秀」を信じないに1票

250 ：NAME IS NULL：2008/02/10(日) 15:13:38 ID:???

組織によっては「何もしない」ことが優秀である件

251 ：NAME IS NULL：2008/02/10(日) 16:00:35 ID:???

組織によらず、同じ結果がでるなら「何もしない」方が優秀である件

252 ：NAME IS NULL：2008/02/10(日) 16:23:05 ID:???

ただの文字データから前後関係で
読みを的確に推測するとは
Oracleってすごいんだね。高いのもわかるわー。

253 ：NAME IS NULL：2008/02/10(日) 18:53:08 ID:???

>>251
あれじゃ改修が発生した場合ネックになって複雑仕様を余儀なくされるようになる。
作り投げ屋や派遣なら関係ないけどね

254 ：NAME IS NULL：2008/02/10(日) 20:05:18 ID:???

>>253

改修が発生してもネックにならないのであれば
「同じ結果がでるなら」に該当しないので
>>251 の言っていることは正しいと思う

255 ：NAME IS NULL：2008/02/10(日) 20:15:49 ID:???

て言うか、状況もよくわからんのにネックになるなんて断言できる奴って
多分エンジニアより営業の方が向いてると思う。

256 ：NAME IS NULL：2008/02/10(日) 22:21:45 ID:???

>>241
ていうか、今俺の仕事まさにそんな感じなんだけど、
コボラーに負けそうです・・・。負けたらそうなるんだろうなあ・・・。

257 ：>>240：2008/02/11(月) 00:49:42 ID:PqAiPtIR

みなさん、ありがとうございます。

確かに、そのシステムは以前コボルで作られていたそうです（今はC）が、
以下の理由でリプレースになったんだとか。。
・団塊世代の退職で、システムを保守できる人がいなくなる。
・引継ぎすべき団塊世代の担当者が優秀なのだが、昔かたぎの職人で、質問に罵声で返答する。
・ドキュメントは誤字脱字、嘘ばっかり書いてある。
・で、引継ぎの先陣隊長が「こんなシステム引き継ぐぐらいなら会社やめてやる！」ぶち切れた。
となって、
結局リプレースになったんだとか。。

258 ：NAME IS NULL：2008/02/11(月) 01:59:52 ID:???

>>257
そういうオヤジのことは「優秀」とは言わない。

259 ：NAME IS NULL：2008/02/11(月) 07:31:13 ID:???

（今はC）

ここに突っ込んでもいいですか？

260 ：NAME IS NULL：2008/02/11(月) 15:01:13 ID:???

>>257
リプレースで>>240なの・・・か？

261 ：NAME IS NULL：2008/02/11(月) 15:29:29 ID:???

きっとうわべだけリプレース

262 ：NAME IS NULL：2008/02/11(月) 15:40:13 ID:???

置き場所移動しただけ

263 ：NAME IS NULL：2008/02/11(月) 15:41:13 ID:???

それじゃリロケート

264 ：NAME IS NULL：2008/02/11(月) 17:45:54 ID:???

>>257
それってＣのを書いた「優秀な技術者」＝引き継ぎの先陣隊長なの？
結局その人辞めちゃったの？

265 ：>>257：2008/02/12(火) 01:49:03 ID:???

>>264
＞それってＣのを書いた「優秀な技術者」＝引き継ぎの先陣隊長なの？
違います。
「優秀な技術者」の上司＝引き継ぎの先陣隊長
ですね。
「優秀な技術者」は別のプロジェクトにいったそうです。

＞結局その人辞めちゃったの？
辞めてはいないです。

ちなみに、そのぶちきれた先陣隊長は30代の人なんですが、
なんかこの業界って団塊の世代と、30代の人ってやたらすぐに切れる人多くありませんか？
この世代って人数が多いから闘争心なんかも異常に強いのかもしれませんね。
どこかの大学の実験で、ねずみを多く入れた箱と、少数のねずみを入れた箱を比べたところ、
多く入れた方の箱は少ないほうの箱より攻撃的になったと聞いたことがあります。
JRで以前、年齢別の車内暴力事件や飛び込み自殺を調べたところ、
団塊の世代と30代の男性が一番多かったとか。。

266 ：NAME IS NULL：2008/02/12(火) 04:59:01 ID:???

30代はむしろ少ないだろ。
バブル世代は39以上だし、それより下は氷河期で。

267 ：NAME IS NULL：2008/02/12(火) 12:11:54 ID:???

>どこかの大学の実験で、ねずみを多く入れた箱と、少数のねずみを入れた箱を比べたところ、
>多く入れた方の箱は少ないほうの箱より攻撃的になったと聞いたことがあります。

狭い場所に多くいるんだからストレス溜まって当然だろう

>JRで以前、年齢別の車内暴力事件や飛び込み自殺を調べたところ、
>団塊の世代と30代の男性が一番多かったとか。。

人数ベースで比較したら団塊と団塊Jr.が多いのは当たり前

ソースは？

268 ：NAME IS NULL：2008/02/12(火) 16:44:52 ID:???

しかしアレだな。
なんでもかんでもカゴテライズしないと安心できないヤツ
ってのはいるもんだな。

漏れは業務ではそれを適切に行うのが仕事だけども
根拠のない思い込みで団塊がどーとか語るエンジニアいたら
ソイツはこういう仕事に向いていないと思うぞ。

269 ：NAME IS NULL：2008/02/12(火) 22:40:47 ID:???

あれ？レスをよく読むと・・・

270 ：NAME IS NULL：2008/02/21(木) 07:51:39 ID:MnpsKLDC

共通テーブルの扱いについて質問させてください。

あるプロジェクトAで使っているデータベースhogeに社員テーブルがあります。
今度、新しいプロジェクトBが立ち上がりましてデータベースfooを作りました。
プロジェクトAと同じように社員テーブルが必要なのですが、
共通テーブルとして社員テーブルを持たせるようにするか、
各プロジェクトの各データベースの中に社員テーブルを持たせるようにするか悩んでおります。

共通テーブルとして社員テーブルを作れば、メンテナンスが楽だなとは思うのですが、
テーブルのjoinができなくなるので大変かなと思ってます。

各プロジェクトの各データベースに社員テーブルを作った場合、
データベースhogeで更新した社員テーブルをデータベースfooの社員テーブルに
どのように反映するかが課題となります。（こういうのにトリガつかっていいんでしょうか？）

このように、複数のプロジェクトで共通に必要とするテーブルがある場合、
皆さんなら共通テーブルにしますか？各データベースの中に社員テーブルつくりますか？

271 ：NAME IS NULL：2008/02/21(木) 07:54:43 ID:???

>>270
DBサーバーが別ということならレプリケーション。
一方向のレプリケーションなら運用も楽。

272 ：>>270：2008/02/21(木) 23:36:26 ID:J1OJ+3YP

>>271
DBサーバは同じです。

273 ：NAME IS NULL：2008/02/22(金) 07:00:01 ID:???

>このように、複数のプロジェクトで共通に必要とするテーブルがある場合、

DBを分けない

274 ：>>270：2008/02/22(金) 07:20:10 ID:jGuXLD6i

>>273
たとえば、勤怠管理システムと給与計算システムがあったとします。
この場合、それぞれのシステム毎にDBもつのが自然ですよね？

275 ：NAME IS NULL：2008/02/22(金) 09:37:34 ID:???

オマエは一度MS Accessでもいいので簡単なアプリ作ってみろ

276 ：NAME IS NULL：2008/02/22(金) 10:24:29 ID:???

>>274
要件による。

特に要件がなければ分けない。

277 ：NAME IS NULL：2008/02/22(金) 14:10:39 ID:???

>>274
システム毎にDBをもつと

１．データの共有が面倒
データの不整合が生じる場合がある。
２．サーバーに負荷がかかる
メモリーやセマフォなどのサーバー資源をDBごとに持つから
DBを２つにすると、サーバー資源は２倍になる。
結果として、パフォーマンスの低下を招く恐れがある。

欠点ばかりで、よいところはひとつもない。
どうしても分けたいなら、DB単位でなくスキーマでわけるとか。

278 ：NAME IS NULL：2008/02/22(金) 22:18:01 ID:???

>>270
>共通テーブルとして社員テーブルを作れば、メンテナンスが楽だなとは思うのですが、
>テーブルのjoinができなくなるので大変かなと思ってます。

なんでJOINできないの？
DBなにつかってんの？

279 ：>>270：2008/02/23(土) 11:02:16 ID:plV93xd4

>>278
DBはMySQLを使っています。
異なるデータベースのテーブルをjoinすることができるDBってあるんですか？？

280 ：278：2008/02/23(土) 12:20:45 ID:???

>>279
MySQLわかんない…

SQLServerだったら同一インスタンス内の別DBのテーブルは
SELECT * FROM foo.dbo.xxxx AS A
LEFT JOIN hoge.dbo.社員テーブル AS B
ON A.社員ID = B.社員ID

とか。
別サーバのDBであってもリンクサーバの設定をすれば、レプリケーションせずとも
[リンクサーバ名].[DB名].[スキーマ名].[テーブル名]
で見に行ける

281 ：NAME IS NULL：2008/02/23(土) 12:50:25 ID:???

>>280
MySQLだからって部分じゃなくね？つか出来ないのってあるの？
両方の参照権限あるユーザであれば select * from db1.table1, db2.table2 出来て当然。

282 ：NAME IS NULL：2008/02/23(土) 20:34:46 ID:???

＞異なるデータベースのテーブルをjoinすることができるDBってあるんですか？？

そりゃまあ、商用RDBのDB2なんかは
select * from Oracle.table1, MySQL.table2
みたいな結合もできるが、あんまやらん罠。

つか、相手が嫌がるケースが多いし、「勤怠管理システムと給与計算システム」
とかなら社員が何万人いるか知らんがMySQLだけで十分だろ。

283 ：NAME IS NULL：2008/02/26(火) 04:46:20 ID:???

シェンロンも作ってんのか?
すっげぇな、おめぇら

284 ：NAME IS NULL：2008/02/27(水) 00:23:24 ID:???

＞システム毎にDBをもつと
＞１．データの共有が面倒
＞データの不整合が生じる場合がある。
＞欠点ばかりで、よいところはひとつもない。
＞どうしても分けたいなら、DB単位でなくスキーマでわけるとか。
システムが別なら、DBも別にするべきだろ？
たとえば、あるサーバに勤怠管理システムと給与計算システムが動いてたとするだろ？
それで、一つのDBに二つのシステムで使われているテーブルが全部入っているとする。
ある日、なんらかの理由で給与計算システムだけ別のサーバに引っ越すことになった場合、
そのDBで使っている給与計算システムのテーブルがどれなのか調べるのが面倒じゃん。
だから、１DB＝1システムで使用するDBであるべき。だと俺は思う。

285 ：NAME IS NULL：2008/02/27(水) 01:10:11 ID:???

どのシステムがどのデータベースの中のどのテーブル
使ってるかぐらいは把握しとこうよ。

286 ：>>284：2008/02/27(水) 01:47:11 ID:???

>>285
業務で使うテーブルなんて１システムで１００テーブルはザラ。
そんなのを把握しようとするのが間違い。
人間は間違いを犯すという前提で、考えるべきだと思う。

287 ：NAME IS NULL：2008/02/27(水) 01:51:44 ID:???

284の人気がどこまで上がるか。

288 ：NAME IS NULL：2008/02/27(水) 03:16:41 ID:???

>>274
ネタなのか釣りなのか。とりあえずマジレスしてみよう。

少なくとも業務システムだと、サブシステム一式をサーバ単位で分けるなんて
設計はあり得ない。(「3層クライアントサーバ」でぐぐれ)

Web系のシステムだと、

Webブラウザ ⇔ ロードバランサ×2 ⇔ Webサーバ×4 ⇔ アプリケーション(AP)サーバ×4 ⇔ DBサーバ×2

とかになってるのがふつー。(「⇔」の部分はネットワーク接続な) 規模が小さ
くてサーバが共存してるケースはあるけど、論理的な構成はあまり変わらない。
(他に、NASやSANやバックアップ装置なども付随してたりはする)

勤怠管理システムや給与計算システムみたいなやつは、サブシステムとして
全部APサーバにぶらさがってる。APサーバ間のセッション共有は、クラスタ化
するとか、セッション情報を全部DBやメモリキャッシュサーバに持たせる。

DBの分割はあくまで業務を基準に分けられる。サブシステム単位ではない。
例えば上記の勤怠管理と給与計算だと、社員マスタあくまで共通。

289 ：288：2008/02/27(水) 03:17:47 ID:???

うぎゃ、レス先間違えた。>>274→>>284 でした。

290 ：288：2008/02/27(水) 03:30:08 ID:???

288の下2行、微妙に話がずれてるような気がするので補足。

サブシステム間で共通する情報を持っている場合(前述の社員マスタとか)、
DBのインスタンスは共通で、各サブシステム固有の情報は同一インスタンス内
の別テーブルに格納するのが普通だと思う。

291 ：NAME IS NULL：2008/02/27(水) 05:13:37 ID:???

ファウラーの分散オブジェクト設計の第一法則。
「分散させるな」
http://martinfowler.com/bliki/FirstLaw.html

292 ：NAME IS NULL：2008/02/27(水) 05:16:18 ID:???

>>286
見れば見るほど味わい深いな。

293 ：NAME IS NULL：2008/02/27(水) 22:05:40 ID:???

「人間は」なんて言ってるけど、ホントは284が犯しちゃったとか？

294 ：NAME IS NULL：2008/02/28(木) 00:25:37 ID:???

>>288
＞DBの分割はあくまで業務を基準に分けられる。サブシステム単位ではない。
おれは>>274じゃないですが、業務とサブシステムって何が違うんでしょうか？

業務＝業界？（たとえば、医療システム、建築システムみたいな単位？）
サブシステム＝（たとえば、医療システムの中の、電子カルテシステムみたいな単位？）

であってますか？

295 ：NAME IS NULL：2008/02/28(木) 01:00:43 ID:???

>>294
業務全体は複数の業務から成る。
システム全体は複数のサブシステムから成る。
一連の業務は複数のサブシステム+人間系を組み合わせる形で実現され、
それらの業務がさらに互いに関連し合う、というイメージ。

例えば「受発注」という業務だと、

見積依頼→見積回答→発注→納品→検収

みたいな流れがあって、これが複数のサブシステムから構成される。
(例えば受注側と発注側とか、見積系と発注～検収系、みたいな感じ。
どう構成するかは設計者次第かなぁ)

で、これはこれだけで成立するとは限らなくて、予算管理や工数管理
などの業務と連携し、業務／システム全体を構成したりするわけだ。

296 ：NAME IS NULL：2008/02/28(木) 12:55:25 ID:???

こうしている間にも284は何らかのシステム開発に関わっているのだろうと思うと、世の中怖くなる

297 ：NAME IS NULL：2008/02/28(木) 21:30:19 ID:???

テーブルの正規化

298 ：NAME IS NULL：2008/03/05(水) 00:29:20 ID:D2n410NJ

このたび、社内で日報システムを作ることになりまして、
みなさんのご意見をお聞かせいただきたい事があります。

以下の情報をテーブルで管理しようと思っています。
・日報ID（主キー）
・日報を書いた日付
・社員ID
・社員が書く日報（二バイト１０００文字）

これらの項目を一つの社員テーブルとして管理したほうがいいのか、
それとも経歴に関しては容量が大きいので、経歴テーブルというものを
別に作ったほうがいいのか迷ったのです。

性能を考えた場合はこうするべきだとか、保守性を考えた場合はこうするべきだとか
いろいろ考え方があると思うのですが、みなさんのご意見をよろしくお願いいたします。

299 ：NAME IS NULL：2008/03/05(水) 00:47:22 ID:???

>>298
用語の統一って大事だよな。
なんにせよ社内システムでしょ？
俺なら拡張ありきと考えて、ある程度予測立ててTABLE分ける。

300 ：NAME IS NULL：2008/03/05(水) 00:47:23 ID:???

社員マスタ
- 社員ID
- 氏名

日報
- 日報ID
- 社員ID
- 内容
- 日付

ていうか経歴テーブルってイ可？

301 ：>>298：2008/03/05(水) 01:11:15 ID:D2n410NJ

すいません。。。かきなおします。
（自分のメモ帳で、全件置き換えしてそのままはりつけちゃいました。。）

このたび、社内で日報システムを作ることになりまして、
みなさんのご意見をお聞かせいただきたい事があります。

以下の情報をテーブルで管理しようと思っています。
・日報ID（主キー）
・日報を書いた日付
・社員ID
・社員が書く日報（二バイト１０００文字）

これらの項目を一つの社員テーブルとして管理したほうがいいのか、
それとも社員が書く日報に関しては容量が大きいので、
日報テーブルというものを別に作ったほうがいいのか迷ったのです。

性能を考えた場合はこうするべきだとか、保守性を考えた場合はこうするべきだとか
いろいろ考え方があると思うのですが、みなさんのご意見をよろしくお願いいたします。

302 ：NAME IS NULL：2008/03/05(水) 08:27:46 ID:???

しね

303 ：NAME IS NULL：2008/03/05(水) 20:24:17 ID:???

>>301
自分が一生そのシステムの面倒見るなら好きに作れ。
他人にメンテさせてくなら、外部のSIerに作ってもらえ。

正直、その程度の事を他人に聞かないと判断できない人間が
やるべきではないと思うが。

304 ：NAME IS NULL：2008/03/05(水) 23:11:04 ID:???

>>303
>正直、その程度の事を他人に聞かないと判断できない人間が
>やるべきではないと思うが。
同意

305 ：NAME IS NULL：2008/03/06(木) 23:23:04 ID:???

社内でって言うんだから練習なんだろ
外で失敗するよりいいじゃまいか

306 ：NAME IS NULL：2008/03/06(木) 23:46:11 ID:???

あまりに初歩的すぎるからな。
ここで答えを書いてしまうのはよくない。

307 ：NAME IS NULL：2008/03/07(金) 01:42:03 ID:???

>>301
テーブル分けないほうがいいと思う。
ＳＱＬ作るのめんどくさいし、性能の面からいっても、たぶんテーブル分けないほうが、
ＤＢの中でテーブルとテーブルを接続する処理がいらないので早いと思う。

308 ：NAME IS NULL：2008/03/07(金) 01:57:07 ID:???

>>301
>　これらの項目を一つの社員テーブルとして管理したほうがいいのか
社員テーブルという名前でなくて日葡テーブルという名前にすればよいと思います。

309 ：NAME IS NULL：2008/03/07(金) 02:05:20 ID:???

>>307
「思う」じゃなくて計測すべし。

310 ：NAME IS NULL：2008/03/07(金) 12:50:16 ID:???

>>307
おぃおぃこのスレはいつの間にこういう輩を呼び込むようになったんだよ・・・

311 ：NAME IS NULL：2008/03/07(金) 19:32:43 ID:???

過疎板の過疎スレの分際で態度だけはデカイな。ここの住民どもは。

312 ：NAME IS NULL：2008/03/07(金) 21:08:00 ID:uMhc0dqS

来月の情報処理試験のデーターベーススペシャリスト試験を目指しているものですが、
モデリングの理解が難しくて四苦八苦しています。
業務の実例からモデリングするようなことを解説している本とかないでしょうか？

プログラマーとしてずっとやってきたのですが、
データーベースの概念設計からやったことは一度もないので、
その辺の知識を補いえたらと思います。

このスレは、色々探していたらヒットしたのですが、
データーベーススペシャリスト試験にも出ている内容が多くて非常に参考になります。
このスレがもっと延びていたら、よかったのにと思います。

313 ：NAME IS NULL：2008/03/08(土) 02:43:39 ID:???

booch

314 ：NAME IS NULL：2008/03/09(日) 02:23:23 ID:9zjRbvkF

create table hoge(id foo bar);
このテーブルでfooとbarが頻繁に更新されて、
idが滅多なことでは変化しない場合はインデックス使うべきでしょうか？

315 ：NAME IS NULL：2008/03/09(日) 02:29:37 ID:???

idが滅多な事では変化しないって
変化する事がありうるの？

idじゃないじゃんそれ。

316 ：NAME IS NULL：2008/03/09(日) 12:16:34 ID:???

>>315
id をバンバン更新する方が普通じゃないと思うが...。

例えば、社員情報テーブルで社員番号がころころ変わるのが普通って
言ってるようなもんだぞ。

>>314
インでクスってそのフィールドが更新するかどうかより、そのフィー
ルドが頻繁に検索に用いられるかどうかの方が重要だと思うけど？

まあ、今時ストレージの値段が下がってるので、更新が少ないなら闇
雲にインデックス張ってしまっておくのも悪くないと思うが。

317 ：NAME IS NULL：2008/03/09(日) 12:20:37 ID:???

>>314
更新するときは where id=? だろうから
id にはインデックスを使って foo bar にはインデックスを使わない
がいいんじゃね

318 ：>>316：2008/03/09(日) 12:51:20 ID:???

>>315 すまん、誤解してた。

>>315 へのレスはなかったことにしてくれ。orz

319 ：NAME IS NULL：2008/03/09(日) 17:09:31 ID:???

今保守させられてるアクセスなんだけど、入力フォームがうまくコーディングできないからって
マスタテーブルに手を入れて解決するのはやめてほしかった。全システムでそのマスタを
使ってるので、入力フォームの変更依頼が来て、全システムを見直さないといけなくなった。
まじ泣きそう。

320 ：NAME IS NULL：2008/03/10(月) 14:13:47 ID:???

人の作ったものの面倒見るのって大変だよな。
ちなみにオレ面倒みさせて困らせる方。

321 ：NAME IS NULL：2008/03/12(水) 00:38:30 ID:SqdK6BYY

「実践！！データベースバイブル」という本に、
"更新が頻繁に発生するテーブルはテーブルのサイズを小さくするべき"とありました。

これはどのような理由からなのでしょうか？

322 ：NAME IS NULL：2008/03/12(水) 06:54:46 ID:???

そのテーブルに索引があったるすると更新される旅に索引が再作成されたり
してパフォーマンスが落ちたりするから。

323 ：NAME IS NULL：2008/03/12(水) 07:24:52 ID:???

>>321
前後に説明がないか？前提や文脈なしでは答えられんと思うが。
ほんとにそれだけしか書いてないならそんな本読むな。
１レコードのサイズのことかテーブルの総容量、レコード件数のことかくらいはっきりしないと答えられないだろ。

>>323
全件走査のようなまねをしない限りパフォーマンス上の問題はないと思うけどな。
問題になるのはバックアップや索引再編に時間がかかるようになるということ。

324 ：NAME IS NULL：2008/03/12(水) 09:32:19 ID:???

重箱スミですまんけど、「更新される旅」って
自己啓発ぽくてなんか自分探してる感じがしますねw

325 ：>>321：2008/03/13(木) 01:33:43 ID:9sO5R5ZC

>>322
なぜ、索引がテーブルのサイズと関係あるのでしょうか？

326 ：NAME IS NULL：2008/03/13(木) 01:50:46 ID:???

マンガの索引は1ページだけど、辞書の索引は数十ページあるよね？

327 ：NAME IS NULL：2008/03/14(金) 00:34:59 ID:???

>>321
>>323さんの指摘のように、１レコードのサイズのことかテーブルの総容量、レコード件数のことかはっきりしないが、
サイズを小さくできるなら、どんなテーブルでも小さいに越したことはない。

328 ：NAME IS NULL：2008/03/14(金) 04:14:10 ID:???

ACID の原子性と独立性って意味するところかなり被ってないっすか?

329 ：NAME IS NULL：2008/03/14(金) 08:35:07 ID:???

Dirty　Readを行うトランザクションだと、
原子性(Atomicity)は保障されているかもしれないが、独立性(Isolation)は保障されない。

330 ：NAME IS NULL：2008/03/15(土) 19:23:15 ID:JuJf5Jao

きっちり第３正規化まですれば教科書的にはOKのはずが、
情報システム部のアホどもにコードだけじゃテーブル見ただけで内容がすぐに
わからないだの、全ての金額が１テーブルから取得できないから使いづらいだの
言われて激しく萎えた…

331 ：NAME IS NULL：2008/03/15(土) 20:31:08 ID:???

＞全ての金額が１テーブルから取得できないから使いづらいだの

これ本気で言ってるとしたら馬鹿だな

332 ：NAME IS NULL：2008/03/15(土) 20:46:25 ID:???

> 全ての金額が１ルーブルから取引できないから

nimieta

333 ：NAME IS NULL：2008/03/15(土) 23:12:58 ID:???

>>330
アプリケーションをつくる側の率直な意見だろ

正規化されたテ－ブル群とアプリケーションの作り手のデータのイメージの間に
レイアーが必要なんだよ

ビューでもいいし、データを抽象化させたクラスライブラリーでもいい

334 ：NAME IS NULL：2008/03/16(日) 01:07:26 ID:???

>>330
要件の認識相違が発生してそうだな。
情シス的にはアプリケーション用の簡易インターフェース（アプリ要求に対応するviewとかね）まで用意されてるって聞いてるかもな。

335 ：NAME IS NULL：2008/03/17(月) 22:14:11 ID:lmGtzTS2

有効期間をもつマスタのキーをサロゲートキーにした場合､トランザクションテーブルの外部キーには何を格納すれればいいの？
あとからマスタの有効期間を変更されるともう…

336 ：NAME IS NULL：2008/03/18(火) 08:41:48 ID:???

>>335
サロゲートキーの理解間違ってない？
普通はこうなのだけど
自然キー ○×コード＋期間
サロゲートキー ID（一意の連番）
で外部キーのリファレンスにはIDを使用する。

337 ：NAME IS NULL：2008/03/18(火) 09:41:06 ID:???

>>330
そんなときのためにビューがある思うんだけど。
ビュー使うと著しくパフォーマンスが落ちたりするわけ？

大きいシステム作ったこと無いからわからないんだけど

338 ：NAME IS NULL：2008/03/18(火) 15:28:41 ID:o6I3pzzP

>>336
じゃあ毎回トランザクションデータの外部キーに格納されたサロゲートキーでマスタ参照して自然キーを取得､その自然キーと適用期間でマスタを再度検索してマスタ情報を紐付けるわけですか？

339 ：NAME IS NULL：2008/03/18(火) 16:04:10 ID:???

はあ～

340 ：NAME IS NULL：2008/03/18(火) 19:28:07 ID:???

＞有効期間をもつマスタのキーをサロゲートキーにした場合

この前提からしてすでに糞設計の香りが・・・

341 ：NAME IS NULL：2008/03/18(火) 20:23:49 ID:pgewhZJh

サロゲートキーとマスタの有効期間についての矛盾点について、
まともな回答が得られたことがありません…

パッケージ屋は、マスタに変更があったら、
伝票１件づつ開いて登録し直せの一点張りだし

ソフトハウスのPGオタクはマスタに有効期間持たせたくないとごねるだけだし…

342 ：NAME IS NULL：2008/03/18(火) 20:26:08 ID:???

誰がピンサロでスマタやねん

343 ：NAME IS NULL：2008/03/18(火) 20:31:04 ID:???

そんなに不満があるならパッケージなんか使わずに
自前で実装すればいいのに。

話からすると設計＆実装のほとんどを外部に依存しているクセに
あーだこーだ後から文句いうのは男らしくない。

パッケージを使うなら、脳の仕組みをパッケージに合わせろ。
それが出来ないならパッケージは使うな。

344 ：NAME IS NULL：2008/03/18(火) 21:00:13 ID:???

>>341
＞まともな回答が得られたことがありません…

まともな質問が出来てないからだと思うぞ。

345 ：NAME IS NULL：2008/03/19(水) 01:52:09 ID:???

>>338
Join とサブクエリがすらすらと使えないやつはSQLを直接いじるな。

346 ：NAME IS NULL：2008/03/19(水) 03:57:41 ID:???

>>341
つまり矛盾を生じさせているのは>>341自身ってことか？？？

347 ：NAME IS NULL：2008/03/19(水) 06:45:22 ID:jgbHpnMh

つまりサロゲートキー推進派は有効期間という概念を理解できない奴等なわけだな。

348 ：NAME IS NULL：2008/03/19(水) 06:51:18 ID:???

ＤＢ板で珍しい自作自演を見たって感じだな。ｗ

349 ：NAME IS NULL：2008/03/19(水) 09:33:21 ID:???

大体なにが矛盾なのかわからん。

そもそも>>335でサロゲートキーの意味を間違ってて、
それを指摘されたら>>338でようわからんこと考えてる
（joinを知らないのかな？）ので、矛盾点とかいう
発想になるんじゃないかと。

350 ：NAME IS NULL：2008/03/19(水) 09:42:33 ID:vKyZWKXy

>サロゲートキーとマスタの有効期間についての矛盾点について、
>まともな回答が得られたことがありません…
どの辺が矛盾しているのかもう少し詳しく

351 ：NAME IS NULL：2008/03/19(水) 19:28:02 ID:jgbHpnMh

マスタの有効期間を後付けで変更できることで､トランデータから参照すべきレコードが変化する矛盾。

352 ：NAME IS NULL：2008/03/19(水) 19:45:51 ID:vKyZWKXy

参照すべきデータが変わるから、有効期間がついてるんだろ？

353 ：NAME IS NULL：2008/03/19(水) 19:55:47 ID:???

結局335はどんな回答をもらえれば満足できるんだ？

正直アホの子がダダこねてるだけにしか見えんのだが。

354 ：NAME IS NULL：2008/03/19(水) 20:44:33 ID:???

そもそもその「マスタの有効期間」というのが、新規登録についてなのか
参照についてのものなのか、それ次第で解は変わるだろ。
そこんとこ明示してないところをみると、本人も区別できてないんじゃないか？

(あー、言ってること矛盾してるし、そんなんで作れるかよ)
「マスターに変更があったら登録しなおしてください。(ｷｯﾊﾟﾘ)」

355 ：NAME IS NULL：2008/03/19(水) 20:49:23 ID:jgbHpnMh

>>352
通常はそうだか､後から付帯情報が変わったりするんだよ。先物系の単価の改定だとか､締日だとか､商品名だとか…

356 ：NAME IS NULL：2008/03/19(水) 21:11:26 ID:jgbHpnMh

具体的に書くと、悩みどころは

１．自然キーの場合、

・マスタ{Code,開始日,終了日,…}
※主キーはCodeと版数などの複合キー

・トラン{ID,日付,マスタのCode,…}

でマスタの有効範囲が後から変化してもCodeが変化するわけではないから、
SELECT * FROM マスタ WHERE Code = @マスタのCode AND @日付 BETWEEN 開始日 AND 終了日

で問題ないが、

２．サロゲートキーの場合、

・マスタ{ID,Code,開始日,終了日,…}
※主キーはIDのみ

・トラン{ID,日付,マスタのID,…}

となり、マスタの有効範囲が変化すると
SELECT * FROM マスタ WHERE ID = @マスタのID
では誤った結果となってしまい、
上記と同じ結果を得るためには

SELECT * FROM マスタ WHERE Code IN (SELECT Code FROM マスタ WHERE ID = @マスタのID) AND @日付 BETWEEN 開始日 AND 終了日

としなくちゃならんのかと…

357 ：NAME IS NULL：2008/03/19(水) 21:41:05 ID:???

なんで、根本的に設計が間違っていると気がつかないんだろう・・・。

ID:jgbHpnMhはマジでアホの子だと感じるが。

358 ：NAME IS NULL：2008/03/19(水) 21:44:34 ID:jgbHpnMh

じゃあ正しい設計とは？

359 ：NAME IS NULL：2008/03/19(水) 21:46:53 ID:???

そのSQLでは何を求めたいのかな？文章もSQLも意図が分からんよ。

サロゲートキーの例ではなぜパラメータをわざわざIDに変更するのか？
挙げられたけど説明には使われないトランテーブルの意味は？
妙に効率の悪そうなINサブクエリを使う理由は？

まぁ、設計やるならSQLくらいちゃんと使えるようになってからだな。

360 ：NAME IS NULL：2008/03/19(水) 21:54:52 ID:jgbHpnMh

トランに格納されているのがマスタのIDなので､マスタ抽出のパラメータをIDにせずにどうやって紐付けろけと？

361 ：NAME IS NULL：2008/03/19(水) 22:00:29 ID:???

ID:jgbHpnMhは素直に外注に作ってもらうか、全うな設計が出来る人の下で
３年働いてから、このスレで質問したほうがいい。

おそらくコイツの周りの大人も辟易してるんだろうなぁ・・・。

362 ：NAME IS NULL：2008/03/19(水) 22:03:52 ID:???

>>360
まさか、トランをなめて1レコードずつマスタを引き当てる処理をしようとしてるとか？
おまえコボラだろw

363 ：NAME IS NULL：2008/03/19(水) 22:05:13 ID:jgbHpnMh

その結果後付けでマスタの適用期間が変わる与件が無視されるわけですか？
業務のためにデータがあるわけで､データを作るために業務があるわけではないんですよ。

364 ：NAME IS NULL：2008/03/19(水) 22:09:39 ID:jgbHpnMh

>>362
SELECT トラン情報.*,マスタ情報.*
FROM トラン
INNER JOIN マスタ
ON マスタ.Code IN (SELECT Code FROM マスタ WHERE ID = トラン.マスタのID)
AND トラン.日付 BETWEEN マスタ.開始日 AND マスタ.終了日

こんな感じで結合できるのはわかっていますが…

365 ：NAME IS NULL：2008/03/19(水) 22:11:43 ID:???

漏れもこの質問者はコボラに思えてきた。

つかトランって単語使うのはジジイばっかな印象あるし。

366 ：NAME IS NULL：2008/03/19(水) 22:21:57 ID:???

>>364
ふむ、これなら理解できる。相変わらずINサブクエリは変だけど。
それで、いったいなにが不満なの？

367 ：NAME IS NULL：2008/03/19(水) 22:27:36 ID:jgbHpnMh

ＩＮのサブクエリについてこうしないと後から期間が変更になる場合を考慮できないとおもうのですが…

368 ：NAME IS NULL：2008/03/19(水) 22:45:12 ID:???

ID:jgbHpnMhにいい言葉を与えよう

2chでウダウダやってる暇あったらいい外注探せ、君には理解できないから。

369 ：NAME IS NULL：2008/03/19(水) 23:52:04 ID:???

>>367
なるほど、ようやく意図が分かった。
トラン→マスタという関係があるものと思っていたが、そうじゃないんだな。
この場合、論理的にはCodeというエンティティが存在して、本来ならば
トラン→Code→→マスタという関係となるところが、Codeが退化して
埋め込まれているとみなすことが出来る。
「自然キー」CodeはCodeエンティティのキーであって、マスタのキーではない。
これと、マスタのサロゲートキーであるIDとは論理的に異なる。

また通常、自然キーとサロゲートキーは相互に置き換えが可能だけれども、
キー値の更新が行われる場合には結果が異なる。ここでは、マスタの候補キー
(Code,開始日,終了日)がそれに該当する。

...ということをきちっと説明できるならばいいんだけどね。

370 ：NAME IS NULL：2008/03/20(木) 00:11:26 ID:O4slGcSD

ようやく一人理解してもらえたわけですが…､この場合トランにマスタのＩＤを格納すべきかＣＯＤＥをそのまま格納するのが正解か迷うのです。

371 ：NAME IS NULL：2008/03/20(木) 01:02:22 ID:???

＞マスタ.Code IN (SELECT Code FROM マスタ WHERE ID = トラン.マスタのID)
唯一のキーで絞り込めば1件しか取れない、というのは理解できるかな

372 ：NAME IS NULL：2008/03/20(木) 01:09:29 ID:???

そもそもサロゲートキーと有効期間を両方持たすなって話だ。
サロゲートキーだけで足りないケースってのは
（特殊な運用なら）あるだろうが
その場合でも有効期間だけ持たせれば足りるだろ。
有効期間を持たせてるのにサロゲートキーにこだわって
無駄に難しいことやってるだけじゃん

373 ：NAME IS NULL：2008/03/20(木) 01:17:21 ID:O4slGcSD

有効期間を含めて唯一のキーで絞っていますが…？候補キーの一部（コード）だけではレコードを特定できず､物理キーに従属する候補キーの一部（有効期間）の変更が可能であるという前提が理解できないんでしょうか？

374 ：NAME IS NULL：2008/03/20(木) 01:22:20 ID:???

だから、これじゃたりないなら
ID CODE NAME PRICE
1 A りんご 100
2 A りんご 120
3 A りんご 130
4 B みかん 500
5 B みかん 400
6 B みかん 300

これで足りるだろ、って話だ
CODE FROM TO NAME PRICE
A 1900 2000 りんご 100
A 2001 2005 りんご 120
A 2006 2999 りんご 130
B 1900 2001 みかん 500
B 2002 2008 みかん 400
B 2009 9999 みかん 300

後者にID持たせて無理やり使って何の意味があんの？

375 ：NAME IS NULL：2008/03/20(木) 02:00:10 ID:O4slGcSD

前者だと候補キーが存在しないのでそもそもＣＯＤＥが意味を成さないのでは？入力にも使えないし…
後者については､システム統合などによるコード体型変化への柔軟な対応というサロゲートキーの謳い文句が実現できないです。

376 ：NAME IS NULL：2008/03/20(木) 03:17:40 ID:???

>システム統合などによるコード体型変化への柔軟な対応
いきなり話広がりすぎだろw

377 ：NAME IS NULL：2008/03/20(木) 06:47:43 ID:???

こんなんで
>先物系の単価の改定
とかそんなシステムが作られていると思うとゾッとする

378 ：NAME IS NULL：2008/03/20(木) 06:55:43 ID:???

つかコイツずっと2chにはりついてｸﾚｸﾚ君してたのかよ。

ほんとにアホの子なんだな。

379 ：NAME IS NULL：2008/03/20(木) 07:02:50 ID:???

トラン(ID, マスタID, ... )
マスタ(ID, CODE)
マスタ詳細(ID, マスタID, 開始日, 終了日, ... )

SELECT
　...
FROM
　トラン t
　INNER JOIN マスタ m ON t.マスタID = m.ID
　INNER JOIN マスタ詳細 md ON
　　t.マスタID = md.マスタID
　　AND t.日付 BETWEEN md.開始日 AND md.終了日

こんなんではダメ？

380 ：NAME IS NULL：2008/03/20(木) 07:11:04 ID:???

>>375
要は、サロゲートキーは他の候補キーと一対一対応していなければならないということだ。
マスタのサロゲートキーであるIDはマスタの候補キーの一部でしかないCodeとは異なるから、
トランにどっちを持たせるかによって結果が異なる。
その「サロゲートキーの謳い文句」とやらを実現するには、Codeテーブルを明示的に
用意すればよい。

381 ：NAME IS NULL：2008/03/20(木) 07:21:40 ID:???

自分のためにも、世の中のためにも、転職をおすすめします。

382 ：NAME IS NULL：2008/03/20(木) 10:07:43 ID:O4slGcSD

379さんが示したものに近い設計は一度やったことがありますが､やはりこれが一般的な解なのでしょうか？

383 ：NAME IS NULL：2008/03/20(木) 10:29:12 ID:???

今北産業，要は

ID 商品ID 開始終了
1 A りんご 2000 2002 100円
2 A りんご 2003 2004 200円
3 A りんご 2005 2007 300円

で，トランザクション側には，
IDだけを持たせておけばおｋ？
自然キーの場合は商品IDと開始，終了期間が主キーになるよね？
何しろ期間によってキーが変わっちゃう訳だから．

384 ：NAME IS NULL：2008/03/20(木) 11:05:43 ID:O4slGcSD

後から期間が変更にならなければね…

385 ：379：2008/03/20(木) 11:22:45 ID:???

>>382
何か気に入らんことでもあるの？

>>381
同意

386 ：NAME IS NULL：2008/03/21(金) 04:27:06 ID:???

>>384
>後から期間が変更にならなければね…

期間が変更になっても、変更前の期間をトラン側では参照したいってこと？
じゃあ変更前と変更後で別モノとして管理しなきゃいけないって事じゃん。
マスタに新規登録しろよ。

サロゲートキーだのなんだのいう以前の問題じゃん。
DB設計なんて構える前に、一度落ち着いて
物の道理とかいうレベルで考えてみれば？

387 ：NAME IS NULL：2008/03/21(金) 10:38:29 ID:???

変更前の期間によるマスタの紐付けを正とするならサロゲートキーが正解なんだけど？

388 ：NAME IS NULL：2008/03/21(金) 16:11:03 ID:tELGxuVg

まあ、オーダーメイドのＤＢなら設計ミスだが、パッケージなら「仕様」だな。
パッケージに仕様以上の事を求めてはいかんよ。選定したヤツに文句言った方がいい。
仮にオーダーしても、このテの説明してもソフト屋ってついてこれないヤツ多いけどな。

389 ：NAME IS NULL：2008/03/22(土) 00:13:43 ID:???

＞仮にオーダーしても、このテの説明してもソフト屋ってついてこれないヤツ多いけどな。

そりゃ、Accessな案件ならともかく、DB2やSybaseなら半数はついていけるだろ。

390 ：NAME IS NULL：2008/03/22(土) 19:05:33 ID:wxTlY/NQ

趣味でデータベースをいじったことがある程度なんですが、
先日実務でいじることになりまして。データベースはSQL Serverなんですが、
客先から渡されたテーブル設計によると、Float型が主キーになってるテーブルがあるんです。
趣味レベルだった個人的な感覚では危険っぽいんですが、
実務レベルになれば普通ですか？

391 ：NAME IS NULL：2008/03/22(土) 19:13:32 ID:???

引き受けるのが危険

392 ：NAME IS NULL：2008/03/22(土) 20:52:38 ID:???

漏れも危険な香りがすると思うが、主キーという単語が出てくるだけマシなのでは？
COBOLerなんかが設計すると主キー以前に正規化という単語から存在しないからな。

393 ：NAME IS NULL：2008/03/22(土) 22:08:07 ID:???

そもそもfloat型なんて今まで組んできた業務アプリで一回も使ったことないわけだが・・・。

394 ：NAME IS NULL：2008/03/22(土) 22:35:02 ID:???

>>390
主キーがFloat型

本来、整数型であるべきカラム属性が実数型になっているのか
主キーに設定されている実数型のカラム自体が、主キーとして不適合なのか

>>390のレスを読んだ限りではわからない

395 ：NAME IS NULL：2008/03/22(土) 22:46:07 ID:???

>>394
そういうもんかね。
例えば「うちでは違う製品に同じ名前をつけることは絶対に無い」って保障があったとしても
製品名を主キーにはせんだろ。

396 ：NAME IS NULL：2008/03/23(日) 00:41:22 ID:???

なんで？

製品名がやたら長いとか、型番とかのもっといいデータがあるとかが
なければ俺なら主キーにするよ。

397 ：NAME IS NULL：2008/03/23(日) 01:34:36 ID:???

主キーじゃないけど、以前、必要とする能力を実数で計算して算出し、
その能力値を持つ製品を探し出すというシステムで、実数型に対し
WHERE句に能力値をそのまま「＝」で取ってこようとしてるのなら
見たことがある。

398 ：NAME IS NULL：2008/03/23(日) 05:45:13 ID:???

不動小数ならいいんだけどな
Floatはいかん罠

399 ：NAME IS NULL：2008/03/23(日) 06:04:34 ID:???

不動はいいけど浮動はダメってか？

400 ：NAME IS NULL：2008/03/23(日) 12:45:59 ID:???

>>397
普通は、必要以上の能力を持つ製品を検索すると思うけど、どんぴしゃの
能力でないとダメってこと？

て言うか、計算結果とデータベース上のデータが実数で合うって...

ほんとに実数が必要だったのか疑問だな。

>>399
不動 = 固定小数点ってことだろ。

401 ：NAME IS NULL：2008/03/24(月) 01:42:59 ID:???

>>396
IDを使えよ

402 ：NAME IS NULL：2008/03/24(月) 20:46:49 ID:???

なんで？

403 ：NAME IS NULL：2008/03/25(火) 09:50:55 ID:Wyt/otDa

製品名が変わるかもしれないから

404 ：NAME IS NULL：2008/03/25(火) 22:50:40 ID:???

じゃあ、製品名を変える事が絶対無いと保証されてたらいいの？

405 ：NAME IS NULL：2008/03/25(火) 23:27:35 ID:???

>>404
わざわざ賭けに出る事ないのに
そこまでこだわる理由がわからんけど
ギャンブル好きならご勝手にというところですな。

406 ：NAME IS NULL：2008/03/25(火) 23:41:59 ID:???

製品名インデックスをわざわざつくるのがどーしてもいやだとかｗ

407 ：NAME IS NULL：2008/03/25(火) 23:43:01 ID:???

キー以外のインデックスを作るという意味でね↑

408 ：NAME IS NULL：2008/03/26(水) 00:03:04 ID:???

>>405
意味のない議論してるからだろ。
「製品名」を「要件」に置き換えたら、あらゆるものを否定できるぜ。

409 ：NAME IS NULL：2008/03/26(水) 01:38:01 ID:???

>>408
主キーが主キーたるには3つの条件があってだな…

410 ：NAME IS NULL：2008/03/26(水) 15:27:56 ID:???

>405は常識的な話をしてるだけだろ
常識的じゃないけど「絶対に製品名は変わらない」って前提があるなら>404もありだと思うが

大抵そんな前提は崩れるもんだけどなｗ

411 ：NAME IS NULL：2008/03/26(水) 19:17:09 ID:???

また、サロゲートキーの流れか？
せっかく話題変わったとおもったのにｗ

412 ：NAME IS NULL：2008/03/26(水) 19:48:15 ID:???

論理学の問題だよ。
「Xという前提でYが成り立つか？」という話をしているときに「そもそもXが成り立つか？」
という話をごっちゃにしたら混乱するのは当然。
しかも>>410はトートロジーだし。

それと、「商品名」が変わるかもしれないと考える理由は何なのかな？
これが「製品コード」とか「ビールジョッキ」だったとしても同じように思った？

413 ：NAME IS NULL：2008/03/26(水) 20:31:20 ID:???

>>412
思ったね。製品コードなんかが「変わらないもの」って
雰囲気がある分だけ一番やっかいだ。
書籍関連のシステムやってたけど、
ISBNの13桁対応だって結構な仕事だったんだぜ。
これがキーだったら死んでたよ。

お客さんの「絶対」なんて信用できないでしょ。
結局変更があるかどうかの確率でしか話ができない。
なら余計な賭けに出るより、安全な方法を採るのがいいじゃん。
ギャブル好きならご勝手にどうぞってのはそういう事です。

論理学の問題？バカ言え、>>411のいう通り、
サロゲートキーの話を蒸し返してるだけだよ。

414 ：NAME IS NULL：2008/03/26(水) 20:31:52 ID:???

一意、必須、永続を満たさないものは主キーたりえない。
これはDB設計の入門書レベルの話。

製品名にそれが当てはまるかと言えば、そんな保障は無いといわざるを得ない。
例え客が「製品名は一意です」「必須です」「永続です」と言ってもだ。
結果として一意で必須で永続かもしれないが
その可能性に掛けるようなばくちを打つのは愚かだといわなければならない。

だからどこのシステムでも製品名を主キーにしたりせず
別に主キーを設けるわけだ。

サロゲートキーの話か？とか
商品名が変わるかもしれないと考える理由はなんだ、とか
あまりにレベル低すぎ。

415 ：NAME IS NULL：2008/03/26(水) 22:38:53 ID:???

>>412
>論理学の問題だよ。
全然ちがうよ。

416 ：NAME IS NULL：2008/03/26(水) 22:51:15 ID:???

>>413
客が言ってたらいいんじゃん。

製品名が変更になったら、「仕様変更」で受注すればいいだけだし。(w

417 ：NAME IS NULL：2008/03/27(木) 09:07:05 ID:???

>>416
そうそう、お主も悪よのうパターンもあるんだよな。
まあここは設計を語るスレだから、営業的側面は取り敢えず
おいとくってことでw

418 ：NAME IS NULL：2008/03/27(木) 09:38:13 ID:???

結論
客相手ならそのままＧＯ！
自社用開発ならやめておけ

419 ：NAME IS NULL：2008/03/27(木) 11:30:06 ID:???

>>414
別の候補キーを選択するってのならわかるが
別に主キーを設けるって、それ代替キーだろ
つまり、サロゲートキーの話じゃん
自分で自分のレベル低すぎって言ってるぞｗ

製品名を主キーにする話にすりかわってしまったが
もとの話は、390のFloat型が主キー・・・という話だったよな

420 ：NAME IS NULL：2008/03/27(木) 12:27:46 ID:???

俺は客相手でも嫌って言うけどなｗ

それでも名前でやれって言われれば渋々やるだろうけど

421 ：NAME IS NULL：2008/03/27(木) 17:29:02 ID:MVf/TxMn

>>418
客相手でも自社でも、代替キー使うだろ。
製品名が変更になったら、
　1.何にもしないで「仕様変更」で金だけもらう
　2.無料で対応しますと恩に着せておく
その時の状況でどっちでもイケるだろ。

結論：製品名は主キーにしない。

422 ：NAME IS NULL：2008/03/27(木) 17:54:23 ID:???

卑しいな

423 ：NAME IS NULL：2008/03/27(木) 18:07:13 ID:???

ナチュラルキーとサロゲートキーの違いが分かってない奴がいるな

424 ：NAME IS NULL：2008/03/27(木) 20:21:18 ID:???

>>419
入門書を読むか、最低でもネットで検索してみることをお勧めする

425 ：NAME IS NULL：2008/03/27(木) 20:39:19 ID:???

最近サロゲートキーって単語を覚えたらしい厨房がウザいな。

426 ：NAME IS NULL：2008/03/28(金) 00:18:58 ID:???

春だねぇ・・・

427 ：NAME IS NULL：2008/03/28(金) 00:49:34 ID:???

サロゲートとか言うから、文字コードの話かと思ったらシステム側で
振った連番のことね。

なんか最近昔からある技術に新しい名前付けるのがはやってるのか？

Ajax とか Web 2.0 とか、なんだかなぁ...。

428 ：NAME IS NULL：2008/03/28(金) 01:30:26 ID:???

>>427
昔からサロゲートキーって言うでしょ。

429 ：NAME IS NULL：2008/03/28(金) 07:16:33 ID:???

>>428
ソースは？と言ってみるテスト

430 ：NAME IS NULL：2008/03/28(金) 08:49:23 ID:???

>>428
いわねーよ、ばーかｗ
ひっこんでろｗｗｗ

431 ：NAME IS NULL：2008/03/28(金) 09:21:17 ID:???

そんなに昔ではないにしろAjaxほど最近ではないと思う。

でも実際に仕事じゃあまりいわないなあ。
なんか気取ってるみたいでこっぱずかしくって。

432 ：NAME IS NULL：2008/03/28(金) 10:02:31 ID:???

代理キーの英語名称をそのままカナ読みしただけのもの。概念自体は古くからある。

433 ：NAME IS NULL：2008/03/28(金) 10:15:16 ID:???

あのさぁ、「概念自体は古くからある」なんて事じゃなくて、
「SQL89に定義されていたがSQL92からは実装されている」とかの具体例のソースをだせよ。

でなきゃ、「昔からある」なんて誰も認めない。

434 ：NAME IS NULL：2008/03/28(金) 10:21:41 ID:???

なんだSQLの機能のことと思ってるのかよ。
代理キーというのは関係モデルの概念で主キーとしなかった候補キーのことだぞ。

435 ：NAME IS NULL：2008/03/28(金) 10:25:32 ID:???

>>430
この程度の人間が耳にしたのはごく最近（このスレが初？）かもしれないね。

436 ：NAME IS NULL：2008/03/28(金) 10:29:32 ID:???

アフォか。

じゃあ、その「関係モデルの概念」がANSIとかで公文書(?)として制定されて
エンジニアが実装しはじめたのはいつなんだよ？

どこぞの国の特許じゃねーんだから「概念は昔からある」と主張して
「おまいらそんな事も知らんのか？ﾌﾟﾌﾟﾌﾟ」とか一人で主張しているアフォにしか見えん。

437 ：NAME IS NULL：2008/03/28(金) 10:32:07 ID:???

そろそろ「サロゲート」を禁止文字にすべきじゃないのか？と思うが。

サロゲートバカが粘着してｳｻﾞ

438 ：NAME IS NULL：2008/03/28(金) 10:35:04 ID:???

サロゲートが信仰だということが分かる良スレですね

439 ：NAME IS NULL：2008/03/28(金) 10:37:55 ID:???

なんかちょっとおかしい人が混ざってますね。
話にならない。

440 ：NAME IS NULL：2008/03/28(金) 10:51:45 ID:???

そもそもは>>390の「主キーがFloat型」という話だったよね。

>実務レベルになれば普通ですか？
普通ではないし、止めた方がいいでしょう。
せめて固定小数点。
できれば別途ID（代替キー、サロゲートキーとか呼び方はいろいろあるけど）を付けるのが扱いやすいです。

設計した人が「よく分からないけど大は小を兼ねる」「でもなんとなく倍精度はもったいないかも」みたいな酷い理由でFloatになっていることも有り得るので、そのカラム自体がFloatである理由を聞くといいと思います。

441 ：NAME IS NULL：2008/03/28(金) 11:01:49 ID:???

>>412,427,430,433,436
このあたりは同一人物？
転職した方がいいよ。

442 ：NAME IS NULL：2008/03/28(金) 11:02:27 ID:???

都道府県マスタを作るときに

1:北海道
2:青森県
　：
　：

てな感じで都道府県コードが1からの連番で登録したとする。

>396は「俺なら都道府県名を主キーにする」
>414は「都道府県名を主キーにしたりせず別に主キー（都道府県コード）を設けるのは基本」
>419は「別に主キーを設けるって、それ代替キーだろ。つまり、サロゲートキーじゃん。」

って感じか？
「都道府県コードの変更が怖いから別にサロゲートキーを付加する」とかはナンセンスだと思うが

443 ：NAME IS NULL：2008/03/28(金) 11:20:48 ID:???

代替キーと、代理キーを同じだと勘違いしてるのがいるかもな

代替キーってのは、別途新たにつけたキーで、Surrogate key
代理キーってのは、>>434 のとおりで、Alternate key

まぎらわしいから、サロゲートキーと言う表現は禁止がいいかもしれん
Artificial key　とか、Alias Key　ともいうし、
人造キーとか、人工キーとかのが間違えなさそうだ

444 ：NAME IS NULL：2008/03/28(金) 11:28:30 ID:???

自然キーに対する言葉として人工キーというのが一番しっくりくる。

445 ：NAME IS NULL：2008/03/28(金) 12:17:40 ID:???

>>442
その例で、「都道府県コード」をシステム側で付番してるなら、
それが人工キーと言ってるやつなんだが・・・

既に人工キー付けてるのに、更に追加するのは、俺もナンセンスだと思うがな

446 ：NAME IS NULL：2008/03/28(金) 12:41:22 ID:???

都道府県名に都道府県コードを付けるとして
その都道府県コードが外部（ユーザー）から認識されるコードなら
人工キーであっても立派な主キーなんだよね。
代理キーはむしろ都道府県名になるはず。
逆に都道府県コードがテーブル間の関連でしか使わないものならそれは代替キーとなる。

さきの商品名の話しでは、
商品名を主キーにするか別に商品コードを付け主キーとするかというのが第一の問題で、
外部（ユーザー）から認識されない代替キーをつけるかどうかは本質的な問題ではない。

447 ：NAME IS NULL：2008/03/28(金) 13:02:44 ID:???

正直「それはサロゲート」と喚いているヤツは主キーすらまともに理解していない気がするな。

商品名の話で「商品名が主キーで、IDがサロゲートキーです！」とか
ヌカすアフォがいたら漏れは即効で設計・開発からソイツを除外する。

448 ：NAME IS NULL：2008/03/28(金) 13:26:26 ID:???

そもそもサロゲートキーって概念はDB設計じゃなくてシステム設計な気がするな
サロゲートであろうとなかろうとDBとしてはPKになるわけだし

CUIのシステムだとコード値はユーザに公開しないといけない情報だから自然キー
GUIのシステムだとコード値はユーザに公開する必要ないからサロゲートキー（と呼んでも問題ない）
って感じかね

449 ：NAME IS NULL：2008/03/28(金) 13:32:16 ID:???

>>442
JISで定められてる都道府県コードでも
俺は主キーにはしないなー。

気持ちはわかるんだけど、
他のテーブルについて、恣意的なコードは変更可能性があるから
主キーとしてIDを設けるけど都道府県に関しては別、とか
いちいちルールがごっちゃになると嫌なので。

これは主キーの三大原則うんぬんじゃなくて、
運用上のルールにすぎないけど、ルールはひとつの方がいい。

450 ：NAME IS NULL：2008/03/28(金) 13:46:21 ID:???

都道府県コードだろうが、ISO標準の何かのキーだろうが主キーにしない

451 ：NAME IS NULL：2008/03/28(金) 14:49:15 ID:???

ただのセカンドシステム症候群だな
YAGNIって考え方を覚えたほうが良い

452 ：NAME IS NULL：2008/03/28(金) 15:17:55 ID:???

DB設計について色々悩むことは多いけれど、主キーについては「全てID」で自分達としての答えが出たよ。
多対多の関連テーブルやログなんかも。
迷いがなくなったのはとても大きい収穫でした。

453 ：NAME IS NULL：2008/03/28(金) 15:19:37 ID:???

主キーの三大原則とか、わけかわらん
主キーとは、候補キーより設計者が、主に使用すべきものとして
任意に選定して決めるもの
候補キーは、リレーション中でタプルを一意に定められる属性の集合で、
冗長な属性を含まないものだ

理論上の定義と、実務上の経験則を一緒にしたらいかんと思う

他システムの情報で、他システムの人工キーは、
自分の所にもってきたら、自然キーと認識する
規格で決められたコードなんかを、主キーにする場合はこれにあたる
この場合、自分のシステムの外から与えられる情報からなる候補キーより
選択した主キー＝自然キーと考えるからだ
つまり、元情報にない情報で、人工的に自らが追加したキーと言う考えが
人工キーであり、他所からもってきた情報は、人工キーではない

主キーを選定する段階で、
１）与えられた情報での候補キーから選定する
２）与えられた情報での候補キー以外に、新たに人工キーの候補キーを追加する
３）候補キーが存在しないので、新たに人工キーの候補キーを追加する

２）と３）は話が違くて、３）のケースでは、あんまり問題にならんだろ
２）のケースで、追加する派と、追加しない派がいるって事だと思う

個人的には、次のケースでは、人工キーを検討する
絶対使うわけじゃないが、検討はするってカンジ
・候補キーが複合キーで属性が多く、全体に冗長になるヤツしかない時
・システムライフが尽きるまえに、属性変更が加わる可能性がある時
・他所のシステムの人工キーが、候補キーの時

454 ：NAME IS NULL：2008/03/28(金) 15:47:46 ID:???

>>453
> 個人的には、次のケースでは、人工キーを検討する
> 絶対使うわけじゃないが、検討はするってカンジ
> ・候補キーが複合キーで属性が多く、全体に冗長になるヤツしかない時
> ・システムライフが尽きるまえに、属性変更が加わる可能性がある時
> ・他所のシステムの人工キーが、候補キーの時

こういうことをいちいち検討するコストを考えたら
俺は全部IDの方がいいや。長々とおつかれさん。

455 ：NAME IS NULL：2008/03/28(金) 15:51:03 ID:???

どーでもいいが、この長文クンは実際にシステム組んだ事あるのかな？

なんか春休みの宿題でもやってそうな気がするが。

456 ：NAME IS NULL：2008/03/28(金) 15:55:25 ID:???

>>451
セカンドシステム症候群は
あるかどうかわからない後々のために
余計な手間をかけるから悪い。

全部IDにするのはなんの手間もないのでちょっと違う。
O/Rマッピングとか実装を考えても楽。

457 ：NAME IS NULL：2008/03/28(金) 16:02:48 ID:???

全部IDもいいんじゃね？
DB設計に金払ってもらうから、検討するんだし
金払ってもらえない会社は、検討しないってより、できないが正しいな

458 ：NAME IS NULL：2008/03/28(金) 17:07:11 ID:???

O/Rマッパーを使う事が前提ならマッパーが使いやすい様にID振る方針に
する時もあるな。

ただ、SQL直書きする方が効率がいい場合は普通に設計する。

システムにもよるが全部ID振るアフォを見たらクビにするが。

459 ：NAME IS NULL：2008/03/28(金) 17:42:20 ID:???

>>458
>SQL直書きする方が効率がいい場合は普通に設計する。
その場合でもIDの方が楽なのですが。

>全部ID振るアフォを見たらクビにするが。
全部IDではいけない理由って何だろう？

460 ：NAME IS NULL：2008/03/28(金) 17:53:11 ID:???

>>SQL直書きする方が効率がいい場合は普通に設計する。
>その場合でもIDの方が楽なのですが。

それは喪前がSQLを知らないか現実の仕事をしたことないからだろ。
SQL直書きの方が効率がいい集計や分析ケース明らかに存在する。

461 ：NAME IS NULL：2008/03/28(金) 18:04:43 ID:???

>>460
>SQL直書きの方が効率がいい集計や分析ケース明らかに存在する。
話がずれてるね。
「SQL直書きする場合でも、自然キーよりIDの方が楽だ」と書いたのですが。

462 ：NAME IS NULL：2008/03/28(金) 18:26:33 ID:???

>>460
SQLどころか日本語が不自由みたいだなあ。

IDだとSQL直書きの場合不利な点ねぇ・・・。
JOIN句を見て直感的に業務モデル上の
関連が想起しにくいって事くらいかねぇ、考えられるの。

実際にSQL直書きで仕事してみるとこんなの
だからなに？ってもんだけどな。慣れの問題なのかな。

463 ：NAME IS NULL：2008/03/28(金) 19:37:14 ID:???

JOINくらいしか連想できない自称ＳＱＬで仕事している厨房はそんな発想しか
でてこないんだろうなぁ。

それか「その場合でもIDの方が楽なのですが。」程度の仕事しかしてないんだろ。

464 ：NAME IS NULL：2008/03/28(金) 19:43:27 ID:???

Web系なユーザー登録とかショッピングとかそういう簡単なデータの読み書きしかやらないヤツと集計・分析やるヤツとは要求されるレベルが遥かに違うから話はあわんだろうから、そこそこにしとけ。

465 ：NAME IS NULL：2008/03/28(金) 20:06:49 ID:???

分析時の話と、物理設計時の話とで齟齬が生じているような気もします。
集計・分析をする高いレベルにおられる方に、IDのデメリットをお聞かせ願いたいです。

466 ：NAME IS NULL：2008/03/28(金) 20:21:51 ID:???

>>465
この話するとたいがい論理設計の話と物理設計の話がごっちゃになるんだよ。
もう仕方ないね。それはさておき今はどうやら物理設計の話みたいだよ。

UNIONつかいまくりクロス集計つかいまくりの
管理会計帳票担当だった俺でもID使わない理由がわからんなあ。

>>463も悪口言う前にメリットはこうだーまいったかーとか
書けばもっとみんなのためになるやりとりになると思うんだけど。
よろしくお願いします。

467 ：NAME IS NULL：2008/03/28(金) 20:23:35 ID:???

まあこういうのは煽ったら負けだよ。
がんばれ>>463

468 ：NAME IS NULL：2008/03/28(金) 21:13:51 ID:???

>>463
こんなレスをみると、「全部IDで」という方向は間違ってなかったんだなあって思います。

469 ：NAME IS NULL：2008/03/28(金) 21:34:43 ID:???

ID無しのメリット
・ストレージの節約。
・カラム数の節約。
・JOINしたテーブルを*で見たときに見やすい。

470 ：NAME IS NULL：2008/03/28(金) 21:41:29 ID:???

>>469
まいりました＞＜

471 ：NAME IS NULL：2008/03/28(金) 22:09:16 ID:???

472 ：NAME IS NULL：2008/03/28(金) 23:24:02 ID:???

>>469は>>463とは別人だよね、もちろん

473 ：NAME IS NULL：2008/03/28(金) 23:53:17 ID:???

>UNIONつかいまくりクロス集計つかいまくりの
>管理会計帳票担当だった俺でもID使わない理由がわからんなあ。

UNIONが完全悪と言うワケではないが、UNION使いまくるSQLを組む時点で、
あまりSQLと言うかデータを集合で扱うのが苦手なんだと思われる。

そして「ID使わない理由がわからん」と言う時点でテーブルの設計がアレなケースか
利用者が勘違いしているケースが多い。

現実問題として実装する段階でオブジェクト指向な言語(Java)とRDBMSの理念は相性が悪い。
それをある程度軽減する意味でO/Rマッパーがあったりするが、
単純なCRUDならともかく、集計・分析になるとO/Rマッパーで実装する方が
手間がかかる上に、実行速度が遅くなる。

たとえば、銀行の各科目残高の積数・平残を意識した報告書をJava&O/Rマッパー＋IDなテーブルと
普通設計ＤＢ＋統計情報＋マテリアライズ照会を使って実装するのとでは後者の方が生産性が高く
学習コストが低く、実行速度も速く、間違いや修正もすばやく対応できる。

そしてこの手のテーブルは複数のカラムを組み合わせてデータの一意性を確保しているので
「なんでもID」ってのはヴァカのする事で、むしろ実行効率が下がる。

道具や理論は効率的に使い分けるべきで、「なんでも○○」はお勧めしない。

言っとくが漏れも「商品名を主キー」は反対派だからな？w

474 ：NAME IS NULL：2008/03/29(土) 00:04:19 ID:???

>>473
IDなテーブル＋統計情報＋マテリアライズ照会だったらどうなるんだろう

475 ：NAME IS NULL：2008/03/29(土) 00:07:56 ID:???

分離設計進んでてO/Rマッピング使ってたりすると、
集計・分析段階でUNION頻度増えると思う。

476 ：NAME IS NULL：2008/03/29(土) 00:12:16 ID:???

>>474
IDなテーブルだとカラムのドメイン定義がダラダラだろうからSQLといっても
ストアドになるだろうからマテリアライズできない、もしくはSQLがかなり助長となる。
そのストアドで動的SQLになっていたら統計情報使われるか微妙。
結果カーソル回しまくりのCOBOLな泥沼ソースが出来上がり保守性落ち、
学習コストが上がり、実行速度がO/Rマッパーよりはマシだがマテリアライズよりは落ちる。

477 ：NAME IS NULL：2008/03/29(土) 00:19:07 ID:???

確かにO/Rマッパーって学習コストが半端じゃないからなぁ。
SQL文だけならAccessでも仮実装可能なので敷居が低いし。

478 ：NAME IS NULL：2008/03/29(土) 00:19:31 ID:???

どうしておまいらいちいち極論に走りたがるんだ……。
要件に応じて使い分けりゃいいだけだろうに。
原理主義者が一番タチが悪い。

479 ：NAME IS NULL：2008/03/29(土) 00:20:07 ID:???

糞と組んだときの、ただの経験談っぽい

480 ：NAME IS NULL：2008/03/29(土) 00:23:27 ID:???

> IDなテーブルだとカラムのドメイン定義がダラダラだろうから
この前提がなあ。

481 ：NAME IS NULL：2008/03/29(土) 00:25:34 ID:???

むしろIDともう2、3カラムしか無い設計とか好む

482 ：NAME IS NULL：2008/03/29(土) 00:28:15 ID:???

IDを使うのは物理設計の話なので、カラムのドメイン定義がダラダラかどうかには関係ないですよ。

483 ：NAME IS NULL：2008/03/29(土) 00:34:48 ID:???

>>482
ん？それは物理設計とではないだろう。

484 ：NAME IS NULL：2008/03/29(土) 00:51:58 ID:???

誤解があるよね。
ID派（としてしまうけど）は、なんでもORマッパー経由でホスト言語でこねこねするだとか、必要な一意性制約を洗い出さないだとか。

485 ：NAME IS NULL：2008/03/29(土) 01:36:15 ID:???

O/Rに勉強コストとかいってる奴が設計語ってんなよ
しかも今時ストアドって・・・

486 ：NAME IS NULL：2008/03/29(土) 01:53:07 ID:???

>>476
何重にも仮定を重ねてまったく意味の無い文章になってるな

487 ：NAME IS NULL：2008/03/29(土) 01:53:52 ID:???

SQLでOOPとのギャップ解消するほうがよっぽど難しい

488 ：NAME IS NULL：2008/03/29(土) 02:09:14 ID:???

なんにせよ「漏れ」はないよなって話

489 ：NAME IS NULL：2008/03/29(土) 06:20:32 ID:???

全部IDで問題ないという確信が深まりました。
みなさんありがとうございます。

490 ：NAME IS NULL：2008/03/29(土) 07:35:32 ID:???

>>473
O/Rマッパーうんぬんじゃなくって
SQL直書き＋IDの場合のデメリットが
いまいちわかりませんなー。
>>474さんへのレスをお願いします。

あとO/Rマッパー、一般論だとおっしゃる通りの弊害があるけど
JavaだったらiBatisとかS2Daoとかあるから。
SQL書きたい局面なら書けばいいじゃんっていう。
これは一般的なマッパーってわけでないので、ご参考までにという話。

UNIONはね、使いまくりってのは言いすぎだったよ。
使うのに抵抗ないくらいSQLは書けるよと言いたかっただけ。
これは俺が悪かったです。すまんこって。

491 ：NAME IS NULL：2008/03/29(土) 09:10:30 ID:???

なんというか一人が自作自演しているのがバレバレなスレですな。
しかもレス乞食かよ。

なんにしても「全てIDマンセー」以外の意見は認めない厨房なんだし
レスするだけ無駄だな。

492 ：NAME IS NULL：2008/03/29(土) 09:12:49 ID:???

>O/Rに勉強コストとかいってる奴が設計語ってんなよ
>しかも今時ストアドって・・・

こういうヤツの典型がホスト言語(特にVB)で実際コネコネしまくるんだよな。
であげく「テーブル設計が悪い！」と愚痴る能無しが多い。

493 ：NAME IS NULL：2008/03/29(土) 10:27:43 ID:???

>>490
>>493は銀行の情報系の分析を例に出しているのだが、あの情報は
「複数のカラムで一意性…」と説明しているのにID制を使う理由が逆に解らん。
つか無駄だろ。

喪前は勘定日付・作成日付・支店コード・科目コード・口座種目・残高、etcとあるテーブルに対して
IDを割り振ってナニするつもりなんだ？
ここからID付けて前月末残高や平残求めるクエリ流すのにIDがドコで使われるんだ？
金融系なのだとしたらさらに前期末やら年度末の集計・分析が入るんだがIDでどんなメリットがあるんだ？

そんな魔法のクエリがあるなら教えてください。おながいします。ｗ

494 ：NAME IS NULL：2008/03/29(土) 10:44:11 ID:???

>>493
>>473の間違いだよね。
473の内容は

・O/Rマッパー＋ID
・直書きSQL＋自然キー

で比較して、後者の方が生産性が高く学習コストが低く・・・・って
やってるから、O/Rマッパーの弊害の説明になっちゃってますよね。

そうでなくて、同じ条件においてIDと自然キーを比較して、
IDのデメリットを説明してほしいだけなんですよ。
ヴァカとか能無しとか言いたい気持ちもわかりますし
たぶん俺はそうなんだと思うので、それはごめんなさいしますので
心を落ち着けてよろしくお願いします。

せっかくのスレタイに沿った話題ですので。

495 ：NAME IS NULL：2008/03/29(土) 10:48:21 ID:???

で、「全部ID」にする意味は、ルールは単純な方がいい、ってのが大きいです。
だから、原理主義と批判された方も居ますが、
原理主義ってより、現実解って方が近いですかね。
細かにパフォーマンスを計測すると数字上不利な場合など
あるのかも知れませんが、体感速度に現れなければ問題ないですし。

細かいパフォーマンス気にしてややこしい事する方が
チューニング原理主義と呼べそうですね。

無駄というのも、IDのカラム分ディスク領域を消費するとかって話なのでしょうか。
コスト感覚が私とちょっと違うみたいですね。1TB超えHDDが2万切ったらしいですね。

私は、1つ1つのテーブルに対して、O/Rマッパーとの兼ね合いも考えつつ
IDにするか、自然キーやその複合キーにするか検討するコストを無駄と考えます。

もしIDだと大きな弊害がある場合があるならそのテーブルだけ
IDじゃなくするってのにはやぶさかではありませんが
幸い受発注から債権・債務などの管理会計までやって
困った事はないですね。幸せもんなのでしょうか。
ちなみに金融系はやったことないです。

496 ：NAME IS NULL：2008/03/29(土) 12:52:15 ID:???

マスターの変更履歴を残すのってどうやってる？履歴テーブル作って
トリガーで挿入？それともマスターのキーと日付をペアでキーにして
最新を参照してる？

497 ：kanchan：2008/03/29(土) 12:58:39 ID:???

>>492
> こういうヤツの典型がホスト言語(特にVB)で実際コネコネしまくるんだよな。
> であげく「テーブル設計が悪い！」と愚痴る能無しが多い。
こういう連中を相手にしてたらイライラもするだろうけど。

498 ：NAME IS NULL：2008/03/29(土) 13:35:23 ID:???

金融系も>>495で困りません。
統一性ってシステム作る上で大事な事じゃね？

499 ：NAME IS NULL：2008/03/29(土) 14:01:44 ID:???

>>495
いろいろとツッコミたいトコロがあるんだが。

>細かにパフォーマンスを計測すると数字上不利な場合など
>あるのかも知れませんが、体感速度に現れなければ問題ないですし

だからID振ってテメエでJOIN時のパフォーマンス図ってみろ。
金融系の過去２年分をやれば明らかに差がでる。

>細かいパフォーマンス気にしてややこしい事する方が
>チューニング原理主義と呼べそうですね。

IDでJOINする方がややこしくなると言っているんだが、盲目か？
ついでにあの例で魔法のクエリ（ｗ）書いてみろ。

＞コスト感覚が私とちょっと違うみたいですね。1TB超えHDDが2万切ったらしいですね。

世間知らずのアフォか。

じゃあIBMの鯖のDisk装置は35GBで30万するぞ。
壊れてもいいパソコンヲタのコスト感覚とミッションクリティカルな業務のコスト感覚を
一緒にするなよ。

最初からID原理主義者はおもちゃ業務前提だったら好きに作ればいいが、
「データベースは全てID制」トンチキな持論展開するな。

500 ：NAME IS NULL：2008/03/29(土) 14:08:00 ID:???

>そうでなくて、同じ条件においてIDと自然キーを比較して、
>IDのデメリットを説明してほしいだけなんですよ。

なんでこの人は上から目線かつ自分で試さないんだ？
それぞれの業務によって合う合わないがあるから
取捨選択すればいいのに。

ホントにｸﾚｸﾚ厨房がプロに噛み付いているだけにしか見えんが。

このスレ読んでメリット/デメリットが理解できないならこの人は設計すべきじゃないと思うな。

501 ：NAME IS NULL：2008/03/29(土) 14:30:59 ID:???

ttp://www.oracle.co.jp/events/soho03/dl/8i_DWH_techniq.pdf
ではサロゲートキーのメリットとして、「データ容量の節約」「リンクのパフォーマンス向上」が挙げられているのですが...。

502 ：NAME IS NULL：2008/03/29(土) 14:31:01 ID:???

>>499
金融系過去10年分使ってますが・・・問題ないです。
35GBで30万するHDDとかも使ってません。
なんか色々すいません・・・

503 ：NAME IS NULL：2008/03/29(土) 15:19:07 ID:???

>>493
それをO/R真っ裸ー使うときにはやっぱりID振りますか？

504 ：NAME IS NULL：2008/03/29(土) 15:20:31 ID:???

496が完全に埋もれてて可哀想だね

505 ：NAME IS NULL：2008/03/29(土) 15:21:59 ID:???

496乙

506 ：NAME IS NULL：2008/03/29(土) 15:54:48 ID:???

>>491
>なんというか一人が自作自演しているのがバレバレなスレですな。
>しかもレス乞食かよ。
自己紹介どうもです。

507 ：NAME IS NULL：2008/03/29(土) 16:24:34 ID:???

結局サロゲート厨は例の問題のSQLかかないと、持論の正当性を証明できないと思うが。
俺もあのテーブル設計でどうやってID使って結合させるのか興味あるがｗ

「速度は十分です」「金融系１０年」なんて脳内発言よりも現実解を見せて欲しいモノだ。

>>496
＞マスターの変更履歴を残す
なんの為に変更履歴をとるのかハッキリしとかないといけないと思う。
不正アクセスなコンプライアンス的な意味ならジャーナルでいいと思うが。

508 ：NAME IS NULL：2008/03/29(土) 16:58:34 ID:???

>>501
Oracle8の時代ってさ、統計情報はないしSQLのオプティマイザがバカで
人間がアレコレチューニングしていた時代のRDBじゃね？

#式の評価は左からとか・・・。

今はコストベースでSQLエンジン動くから普通にSQL書いても
速度的に問題になるケースは少ない。

OracleもIBMもそう発表しており「プログラマーが変な事スンナ」と発表していたが。

その資料は嘘じゃないけど、現在から見るとどーだかなー、な感がある。

509 ：NAME IS NULL：2008/03/29(土) 17:16:23 ID:???

元々の例になってる奴ですけど、見たところ残高ってあるから、
本来売掛買掛ほか諸々をを集計して導出できるのを、
パフォーマンス対策でテーブルにしたって感じですか。
確かにこういったデータにID振っても、殆どの用途は集計・分析だろうから
誰もID見ないよね。他のテーブルの外部キーにもならない。

だから無駄ってのは判ります。魔法のクエリなんてありません。

他には、多対多を実現するための関連テーブルにIDは要るかって議論もある。
これも誰も見なかったり外部キーにならない事が多い（時々あるけど）。
実はだれかこのつっこみしないのかなあと待ってたんだけどw

で、これはこの場合だからIDでこっちのテーブルは自然キーで、
って考えるの面倒でしょう？あとO/Rマッパーとの兼ね合いもある。

JOINのコストですが、こちらは販売から管理会計までですが、
仕訳の明細単位でレコード作って、えーとあれは前の前のワールドカップだから
2002年ですね、稼動し始めて、今の所大丈夫ですねぇ。
特に商品売買損益計算書が不安だったんですが（商品の種類の数が尋常じゃなかったんで）普通に動いてます。
一応都内一等地にでかいビルが建ってる商社の子会社さんなので
結構な取引量だったんですが。

でも2年で遅くなるって金融系って凄いですね。
これは門外漢でしたが、私の了見が狭かったですね。
どうも、生意気言って済みませんです。

510 ：NAME IS NULL：2008/03/29(土) 17:47:38 ID:???

>>509
なんでO/Rが絡んできてるのか未だによくわからんのだけど、ほんとに使った事あるの？
O/Rでview使わないで他方式ではマテビュー使うとか473なんて明らかに・・・

金融＋分析だと最低5年位データが無いと分析信頼度が得られないってエロイ人が言ってたよ。
貧弱なテスト環境でも確か3年分（足りてないのは諸事情ありｗ）使ってた。

金融系でDB2使ってる所ってあんまり聞かないなぁ・・・
普通は選択肢にも上がらないから調べてみるか。

511 ：NAME IS NULL：2008/03/29(土) 17:54:32 ID:???

そもそも残高の管理単位なんか変更になったら作り直しだろ？

512 ：NAME IS NULL：2008/03/29(土) 18:16:43 ID:M4L278l8

なんだかレベルが違うんですね...。
自分のようなショボい段階と金融系を扱うような凄い人達では、ちょっと言葉も通じてない感じです。

ってか、アレだなあって思います。

>>509
自分の扱うシステムは大した事ないので、関連テーブルでもなんでも、使われることがないであろうIDを付けます。もう機械的に。

513 ：NAME IS NULL：2008/03/29(土) 18:22:25 ID:???

俺も関連テーブルでもID付ける
関連も何かの個であったりするし特定楽だし

514 ：NAME IS NULL：2008/03/29(土) 18:47:39 ID:???

>>510
>なんでO/Rが絡んできてるのか未だによくわからんのだけど

商品名みたいなカラムを主キーにしていいじゃん
↓
そりゃないだろう、お客さんが変更がないといっても信じられないし
↓
そこから話がサロゲートキーの話なる
↓
IDにするメリットはなんだ？
↓
O/Rマッパー使うとき楽だし

という流れがあったから。

>>512
金融でも色々みたいよ。
高いハードでそろえなきゃいけないプロジェクトもあるんだろうなあ。
ミッションクリティカルか否かとは別の次元の理由で。
そう考えると確かにID追加する事によるストレージのコストにも
敏感になるのも理解できます。

515 ：NAME IS NULL：2008/03/29(土) 19:27:11 ID:???

＞金融系でDB2使ってる所ってあんまり聞かないなぁ・・・

銀行やカード系では普通にiSeriesと言うかAS/400が生き残っている。
昔結構売れたからな。コレ。
ホストがzSeriesなので営業的に情報系のサブシステムとして
iSeriesを使うトコはそこそこある。最近減ってるけど。

まあ、ココはココでCOBOLerが横長ＤＢ作りたがるので本気で
内容のレベルはピンキリだが、やってる事がかなりクリティカルかつ
データ量はハンパじゃねぇ。

しかも値を何回も変更してシミュレーションを行うので、
処理が速いほど行員の睡眠時間が変わってくる（ｗ）し、
行員が理解しやすく編集しやすい形で提供する必要があるので、
一エンジニアの自慰理論は却下される。

まあ、ここらの金融機関の予算を決める部署の行員は正直そこらの
プログラマーより遥かに頭がいいので、アフォな設計をすると「ナニそれ？おかしくね？」
とツッコミがはいるから安心汁。

516 ：NAME IS NULL：2008/03/29(土) 19:52:24 ID:M4L278l8

単純に結合のコストだけでいうと、整数なIDは自然キーよりも優れていると思います。
自然キーだと結合しなくてもよくなることもあるので、シビアな業務ではパフォーマンスに優れるでしょう。（非正規化してパフォーマンスアップと似た意味合いになりますね）

ID自体のディスク占有は、ケースバイケースで、大抵の場合は問題にならないと思います。複合外部キーがなくなりますし、逆にサロゲートキーの利点として「ストレージの節約」が挙げられることもあります。
ただIDを採用するとインデックスが増えるので、その影響はあると思います。

515のような人がまともにやれているようには思えないのですが、そういう世界もあるのでしょうし、なにも「全世界の主キーをIDに！」なんて言わないので安心して下さい。
多分515から得られることも（技術的に本当に515が優れているとしても）ないでしょうし、これで自分は終りにします。

517 ：NAME IS NULL：2008/03/29(土) 20:33:15 ID:???

>>516
もしかして、HxBxさん？

518 ：NAME IS NULL：2008/03/29(土) 20:35:01 ID:???

スレたって1年で200レスしかいかなかったのに
今回はすごい盛り上がりだったなw

519 ：NAME IS NULL：2008/03/29(土) 20:44:03 ID:???

>515のような人がまともにやれているようには思えないのですが、そういう世界もあるのでしょうし、なにも「全世界の主キーをIDに！」なんて言わないので安心して下さい。
>多分515から得られることも（技術的に本当に515が優れているとしても）ないでしょうし、これで自分は終りにします。

凄い上からな物言いだな。
サロゲート厨の「ボクが正しいんだ！」ってダダこねてたじゃん。

>>518
まあ、粘着＆自作自演のサロゲート厨がレスの半分以上占めてた希ガス。

520 ：NAME IS NULL：2008/03/29(土) 20:48:31 ID:???

固定長レコードすら使ってない俺はパフォーマンスの話題には加われない

521 ：NAME IS NULL：2008/03/29(土) 21:02:02 ID:M4L278l8

恥ずかしながらまた書きこんでしまいますが

>>519
>サロゲート厨の「ボクが正しいんだ！」ってダダこねてたじゃん。
そこがまず誤解というか妄想で、そのために話になってなかったのでしょうね。

>>517
もちろん違います。ただの末端孫請け土方プログラマです。
そういえば羽生さんと渡辺さんが議論してたときもなんか噛み合ってなかったですね。

どうせ過疎板なのでみんなsageないでもよかったですね。

522 ：NAME IS NULL：2008/03/29(土) 21:13:14 ID:???

>>521
違いましたかw 失礼しました。
けんかがとても上手なのでそうかとww

羽生さんと渡辺さんは噛み合ってなさそうで設計と実装の違いって感じで、
あまりぶつかってなかったように思えました。設計と実装で
上手い事切り替えられる記法があれば無問題な話だったように思います。

それに比べて今回のやりとりはなんだか一方的な煽りが多くて、並べちゃ悪いです。

523 ：NAME IS NULL：2008/03/29(土) 21:59:52 ID:???

ダダこねにしろ上からな物言いにしろ
どっちかというと、どっちかというとだけど
ID否定のお兄さんの方が当たってると思うけど。

524 ：NAME IS NULL：2008/03/29(土) 22:56:56 ID:???

ちょっと相談に乗っていただけないでしょうか。

社内ユーザ向けの質問・障害受付の過去事例検索システムを
作ってるのですが、なかなか良いフィールド名が思いつきません。
必要なフィールドは下のとおりです。

・発生日時（DATE）
・件名（TITLE）
・内容（NAIYOU）
・対応（TAIOU）
・種類（CATEGORY）
・質問者（仮）（思い浮かばず。エンドユーザ側担当。依頼・クレームなど質問とは限らない。）
・受付担当者（UKETUKEにしようか思案中）

すでに決めた分についても、もっといいのがあれば教えてください。

525 ：NAME IS NULL：2008/03/29(土) 23:05:22 ID:???

>>515
iSeriesかぁ・・・そういわれればあったね。
でも使ってる所って大概・・・

しかしiSeries使ってるからクリティカルって妄想甚だしいなｗ

あと言っておくと金融機関の予算決める部署が自部署要件以外で開発に関わる事は無いよ。
奴等は自己防衛の塊だからリスクのあるところ（開発）に口出したりしない。

まぁ、頑張ってくだちぃ

526 ：NAME IS NULL：2008/03/29(土) 23:08:44 ID:???

>>524
作らなくてもBTS使えばいいのに・・・

527 ：NAME IS NULL：2008/03/29(土) 23:09:14 ID:???

これがやっぱおもしろい。余談も多いけど、それも含め。
http://d.hatena.ne.jp/habuakihiro/20060829/1156819448

コメント欄の煽ってる人も面白いです。

528 ：NAME IS NULL：2008/03/29(土) 23:12:03 ID:???

>>524
なんとなく決定済みのカラム名見てると
いっそ全部日本語ローマ字表記の方が
保守しやすいと思う・・・・。

529 ：NAME IS NULL：2008/03/29(土) 23:15:46 ID:M4L278l8

>>524
これもいろいろ流派？があるでしょうが、自分は大概ローマ字にしています。
オフショアなどで外国人が開発・保守に関わる可能性がない限り（というか自分程度ではそんなこともほぼないので）。

いくつかXXX_DATE, XXX_NAME, XXX_NO, XXX_TELなど一部使用する英単語は規約で決めておきます。FAXなどの外来語も。

なので
・発生日時（HASSEI_DATE）
・件名（KENMEI）
・内容（NAIYOU）
・対応（TAIOU）
・種類（SYURUI）
・質問者（SITUMONSYA）
・受付担当者（UKETUKE_TANTOUSYA）

ダサいけど名前付けに悩むこともなくなります。

530 ：NAME IS NULL：2008/03/29(土) 23:22:15 ID:???

>>529
ローマ字にした場合、ヘボン式で統一とか
決めないと結構難儀しますよね。
私の案件では英語にしてました。

逆に英語にした場合の弊害というと、女性がいるチームで
性別ってカラムがあった場合にやりとりに困るのがなあw

531 ：NAME IS NULL：2008/03/29(土) 23:27:07 ID:M4L278l8

>>530
そうですね。自分は訓令式の方が統一性があるので、そちらにしています。
英単語だと名前決めにワンクッションあって、しばらくして忘れてしまって、意味をまた調べ直して。
日本独自の言葉も上手く変換できずにそこだけローマ字。
それならっていうことで、「全部ローマ字（笑）」にしました。

自分達程度の英語力で頭をひねったところで、ネイティブには通じない変な単語を使っちゃいますしね。

532 ：NAME IS NULL：2008/03/29(土) 23:34:43 ID:???

>>530
>逆に英語にした場合の弊害というと、女性がいるチームで
>性別ってカラムがあった場合にやりとりに困るのがなあw
あるあるｗ過敏に反応されるから恥ずかしくなるｗ

533 ：NAME IS NULL：2008/03/29(土) 23:42:08 ID:???

>>532
性別の件を見てあえてすべての項目英語に統一したくなったオレはセクハラで訴えられますか？

534 ：NAME IS NULL：2008/03/29(土) 23:45:37 ID:M4L278l8

>>527
面白いですね。自分も感化されました。
今、改めて見てみると、コメントの通りすがり氏になんだか既視感を覚えます。
「あれ？この人。。。」

535 ：NAME IS NULL：2008/03/29(土) 23:46:37 ID:???

>>533
xxxmanCodeってカラムがあった事がありました。
声に出すたびに「ｘｘｘマン・・・コード」
・・・意識してなかった分恥ずかしくなったわｗ

536 ：NAME IS NULL：2008/03/29(土) 23:57:41 ID:???

>>534
最近wwどっかでみたようなwwww

537 ：NAME IS NULL：2008/03/30(日) 00:02:27 ID:???

>>535
その発想はなかったw

538 ：NAME IS NULL：2008/03/30(日) 00:27:11 ID:???

ところでDB設計ツールでオススメとかある？
今はObjectBrowserERか、JDeveloper、EclipseのAmaterasERあたり使ってます。

539 ：NAME IS NULL：2008/03/30(日) 00:32:34 ID:???

>>538
ObjectBrowserERあるならそれでいいんじゃない？
EAはDB設計だけ使いづらかった気がする。
金ないならDBDesignerとかあるけど開発停止してるしな・・・

540 ：NAME IS NULL：2008/03/30(日) 00:40:03 ID:???

ObjectBrowserERは日本人好みの定義書が吐けるのがいいよね。
DBと同期とるとなるとOracleとPostgres限定になっちゃうけど。
記法もIDEFとIEなのがいい。DBDesignerやToadとかフリーの奴って
なーんでかヘンな記法なんだよねぇ・・・。
所詮記法なんだけど気分が乗らないw

541 ：NAME IS NULL：2008/03/30(日) 00:56:56 ID:???

Toadは使ったこと無いけど、DBDesignerは記法を選べるよね

542 ：NAME IS NULL：2008/03/30(日) 01:06:17 ID:???

ほんげーそうなんですか？知らなかった・・・。
あのひし形がどうも好きじゃなかったんだよなー。
チェンのERDを意識したのかな。

Toadは三本足なんだけど、エンティティが
どっちかというとUMLのクラス図ぽかった。

543 ：527：2008/03/30(日) 03:49:35 ID:???

>>534
やっぱりそう来ましたねw＞既視感
でも、私は楽器板にも顔出すんですが、
煽る人ってみんな同じですよ。すごく似てる。

はぶさん、けんか上手いですよね。
というか、煽りに対して余談とはいえデイトやらラルフ・キンボールやらまで引いて
こんだけ徹底的に相手するって、大人げないよなあw
外野はとても勉強になったんで煽り様々ですが。

544 ：NAME IS NULL：2008/03/30(日) 08:14:37 ID:???

この妄想バカは書き込みやめると言って朝から晩まで2chに張り付いていたのか？

しかし、都内一等地やら不思議な芸暦を聞かれてもいないのに語ったり、
2TB１万円切りましたとかのパソコンヲタがメインフレーム・ホスト・オフコン屋に
机上の空論で噛み付いてたりして不思議なスレになったな。

545 ：527：2008/03/30(日) 09:37:14 ID:W6kVMddH

>>544
おはようございます。実は録画しておいた
とことん石ノ森章太郎見てたらあんな時間に。
おはずかしいww

煽りをスルーするととてもためになるお話でした。
特に行員の睡眠時間に関わる、とかちょっと面白いし
世の中ちょっとしたパフォーマンスの差も
ちり積もでそこまで影響するくらいのトランザクション量を
考えなきゃいけない世界もあるんですねぇ。

書き込みやめると書いてた方と自作自演みたく
思われると先方に悪いのでsageるのやめときます。
sageてもID出りゃいいのに。IDって面倒ww

546 ：NAME IS NULL：2008/03/30(日) 10:12:15 ID:???

お前ら落ち着けよ。
くだらないネタでageるのは大人気ないぞ。
スレ内容に関して質問があるときにageのはともかく
煽りでageるのは子供のする事だ。
>>545は半年ROMっとけ。

だいたい見てると、どちらかと言えばID否定派は煽り口調ではあるが
現実的な例を持ち出して「適材適所で使い分けろ」と言っているだけなのに、
サロゲート信者は丁寧口調ではあるが「統一ルール。メリット・デメリットが解りません。
ボクのやってきた仕事では大丈夫でした。オマエのトコロが異常」と
現実的な面が見えない例をだし議論にならん展開をしていて、
相手を見下しているから荒れるんだろ。

どっちもどっちと思うが、信者はｳｾﾞｰよ。

547 ：NAME IS NULL：2008/03/30(日) 10:25:00 ID:8S8b6WfW

ID厨はうまくｽﾙｰしてたと思うよ。
特に持論に都合の悪い発言に関しては。
それを妄想と思いこむあたり病気か？っておもったくらいだ

548 ：NAME IS NULL：2008/03/30(日) 10:44:29 ID:W6kVMddH

>>546
いやいや、先方も「ボクの所ではそれではダメです。
お前のところがオモチャ」とおっしゃってますし
お互い様だったかなと思います。

適材適所はごもっともなんですが
その適所ってのが、金融系未経験の私の感覚だと
特別な感じがするんですよね。
それがすれ違いの元で。それは反省してます。

でもこのネタ、面白かったですよ。下らなくない。

IDでうれしい事、RESTのリソース指向アーキテクチャとの
親和性が高いってのもありますね。これまた世界が違っちゃって来ますけど
そういうオモチャな世界もあるってことで。

549 ：NAME IS NULL：2008/03/30(日) 11:23:34 ID:???

捨て台詞ｶｺﾜﾙｲ

550 ：NAME IS NULL：2008/03/30(日) 12:02:35 ID:AFfJrt8W

確かに聞かれてもいないのに変な講釈たれるヤツだな
会議でこんなヤツいたら、殴るかシカトかどっちかする

551 ：NAME IS NULL：2008/03/30(日) 13:02:17 ID:???

>>550
こういうヤツが上司だったときの対処法を是非教えてくれ。困ってるんだ。

552 ：NAME IS NULL：2008/03/30(日) 13:12:32 ID:???

ID厨必死だな

553 ：NAME IS NULL：2008/03/30(日) 14:29:19 ID:???

>>530
「え？カラム名がよく聞き取れなかった。もう一回ハッキリと」とかやるわけだな

554 ：NAME IS NULL：2008/03/30(日) 17:54:35 ID:???

「 . . . . . 」
「ジェンダー. . .」

555 ：NAME IS NULL：2008/03/31(月) 01:26:45 ID:???

全カラムNOT NULLとかしてる？

556 ：NAME IS NULL：2008/03/31(月) 01:31:01 ID:???

特に理由がなければデフォルトはNotNullですねぇ。
ついでにデフォルト値も設定するのを標準としたい今日この頃。

SQL書いたときにNull値であることが原因で値が漏れたりするのは勘弁なんで。
そう言う意味では某メジャーDBの''とNULLが同値なのはマジ辞めて欲しい。

557 ：NAME IS NULL：2008/03/31(月) 01:37:14 ID:???

必須の項目に空文字が入ってしまう方もどうかと思うが

558 ：NAME IS NULL：2008/03/31(月) 01:51:29 ID:???

備考に空文字が入ってる。

559 ：NAME IS NULL：2008/03/31(月) 01:53:29 ID:???

住所2にも

560 ：NAME IS NULL：2008/03/31(月) 01:55:23 ID:???

なんで入れなくていい項目をNOT NULLにするのか

561 ：NAME IS NULL：2008/03/31(月) 02:02:12 ID:???

NULLの扱いが面倒だから

562 ：NAME IS NULL：2008/03/31(月) 02:06:50 ID:???

RDBMS側がの扱いも統一されてないからNOT NULLでOK

563 ：NAME IS NULL：2008/03/31(月) 02:11:32 ID:???

統一されてないからこそNOT NULLじゃマズいんじゃないの。
ORACLEで
WHERE カラム名 = ''とか書いても絶対に0件だし
NOT NULLに''をINSERTしたらコケるし。

564 ：NAME IS NULL：2008/03/31(月) 02:28:05 ID:???

Oracleぐらいだよな

565 ：NAME IS NULL：2008/03/31(月) 07:30:35 ID:???

それはOracleだけじゃないのか？
正直それは違うと思うんだが。

566 ：NAME IS NULL：2008/03/31(月) 10:19:33 ID:???

外部キーにもNULL

567 ：NAME IS NULL：2008/03/31(月) 20:55:38 ID:???

「統一されてないから」というから統一されてない話をしたわけで
「ORACLEだけ」とか言うのは正直違うと思うんだが

568 ：NAME IS NULL：2008/03/31(月) 21:18:09 ID:???

Oracleの文字列はNULL許可で他DBはNOT NULL
空文字とNULLを区別したいケースはほぼ無い

569 ：NAME IS NULL：2008/03/31(月) 23:40:11 ID:???

＞「統一されてないから」というから統一されてない話をしたわけで
＞「ORACLEだけ」とか言うのは正直違うと思うんだが

確かOracleだけ扱いが違ったはず。
DB2,MySQL,PostgreSQL,SQLServerは同一だったかと。

570 ：NAME IS NULL：2008/04/01(火) 01:01:29 ID:???

だ　か　ら
「わざわざ」そいういう例を挙げたのに
そういう突っ込みは頭悪すぎだろ、と

571 ：NAME IS NULL：2008/04/01(火) 01:23:57 ID:???

そもそもNULLを入れなければならない状況は正規化しなければならない時ではないか？
結合したときに出現するならともかく、普通はNULLを入れたいという状況がおかしい！！

572 ：NAME IS NULL：2008/04/01(火) 01:39:27 ID:???

なんじゃそりゃ。
住所２テーブルや備考テーブルを作れってことか？

573 ：NAME IS NULL：2008/04/01(火) 06:27:10 ID:???

Oracle信者もモノの考え方がおかしい人が多いな。

574 ：NAME IS NULL：2008/04/01(火) 08:43:47 ID:2sq4kbEf

はしゃいでるとこスマンが
>>570=>>572な

575 ：NAME IS NULL：2008/04/01(火) 09:34:58 ID:???

日付にNULLの代わりの値入れてるケースってインデックスによくないよな

576 ：NAME IS NULL：2008/04/01(火) 09:36:56 ID:???

>>572
Ｔ字型だと理論的にはそういう事になってたと思うよ＞住所2テーブルとか
インスタンスが生成された時点で値の入らない属性は存在しちゃだめっていう。

受注テーブルの属性に請求番号があって、受注時にはNULLで
請求時に値が入る、みたいなのだと正規化必要だけど
住所2とかオプション属性みたいなのはなあ・・・。

577 ：NAME IS NULL：2008/04/01(火) 10:12:52 ID:???

T字形がそこまでNULLを排除する理由ってよくわかんないや

578 ：NAME IS NULL：2008/04/01(火) 10:19:51 ID:???

OOPもその流れな感じだが

579 ：NAME IS NULL：2008/04/01(火) 20:37:09 ID:???

>>572
てめえその二項目はNULLを入れる必要ないだろうが。
そこはデフォで空文字列だ。だからテーブルをわけなくてよろしい。

580 ：NAME IS NULL：2008/04/01(火) 20:40:06 ID:???

じゃあNULLを入れる必要があるケースを教えてくれ

581 ：NAME IS NULL：2008/04/01(火) 21:32:00 ID:???

>>580
そうなったら正規化して排除しろってことでしょ？

582 ：NAME IS NULL：2008/04/01(火) 21:44:21 ID:???

NULLを入れなければ正規化しなくてもいいよ。

583 ：NAME IS NULL：2008/04/01(火) 22:03:13 ID:???

>>581
排除すべきNULLが入るケースとは？ってことでしょ？

584 ：NAME IS NULL：2008/04/01(火) 22:25:26 ID:???

>>575
どうよくないの？そんなのはデータベースの実装側の都合じゃないの？

585 ：NAME IS NULL：2008/04/01(火) 23:03:04 ID:???

一時期0001-01-01とか1900-01-01とか入れてたけどやっぱNULLにすべきだと思った。

586 ：NAME IS NULL：2008/04/01(火) 23:36:45 ID:???

ッアー！

587 ：NAME IS NULL：2008/04/01(火) 23:47:37 ID:???

>>585
なぜ？

588 ：NAME IS NULL：2008/04/02(水) 01:23:57 ID:???

そんあありえない日付入れるくらいなら数字項目にするかNULLにしとけ、って思う。

589 ：NAME IS NULL：2008/04/02(水) 01:33:10 ID:???

オマエは今全国の108歳を敵に回した

590 ：NAME IS NULL：2008/04/02(水) 01:34:54 ID:???

>>588
それはもちろんそうなんだけど、インデックスをはったり日付範囲の検索だったりと、実装上は何か値を入れておく方がいいと思う。

591 ：NAME IS NULL：2008/04/02(水) 02:05:29 ID:???

>>590
そうなんだよねぇ。バッドノウハウではあるんだけど
パフォーマンス向上のためには仕方ない。

592 ：NAME IS NULL：2008/04/02(水) 06:41:26 ID:???

RDBMSによるんだろうけど日付型・NULL可・INDEXで
パフォーマンス上問題でるの？

593 ：NAME IS NULL：2008/04/02(水) 09:43:58 ID:???

NULL率とNULLを抽出したいかどうか

594 ：NAME IS NULL：2008/04/02(水) 10:11:19 ID:???

ぬるぽ

595 ：NAME IS NULL：2008/04/02(水) 12:15:44 ID:???

NOT NULLだと若干パフォーマンス落ちるんじゃない？

596 ：NAME IS NULL：2008/04/02(水) 18:23:11 ID:???

>>592
例えば前回締め日みたいな日付カラムがあって、
取引開始したばっかりだともちろんNULLになるはずだけど
これを1900/01/01とかにしておくとIS NULLを書かなくて済むので
全件フェッチが防げる。

そもそも前回締め日なんて導出出来るだろうと
おっしゃる方もいると思いますが、パフォーマンス対策で
持ちたい場合もあるのですよ・・・。

597 ：NAME IS NULL：2008/04/02(水) 18:29:18 ID:???

あ、そんなややこしいのでなくても
有効期間のFROMとTOなんかがわかりやすいか。

TOが未定の場合なんかもNULLじゃなくて
すんごい未来日付を入れておくと
to_data >= now() or to_data is null
なんてしなくても済むわけです。

こういうのが当たり前みたいになっちゃてるんですが
なんか他にかっこいい方法ありますかねぇ。まじで知りたい。

598 ：NAME IS NULL：2008/04/02(水) 21:34:35 ID:???

そんな設計していると
9999年問題が起こり、後で自分達が苦労するぞ

599 ：NAME IS NULL：2008/04/02(水) 22:47:58 ID:???

タイムマシンが出来たら色んな設計が崩壊する

600 ：NAME IS NULL：2008/04/03(木) 09:11:18 ID:???

Toが未定だって状態を別の項目で持てば？

601 ：NAME IS NULL：2008/04/03(木) 20:57:23 ID:???

タイムマシンが出来たら20世紀の世界に行って
2000年問題のバグを直しておきたい

602 ：NAME IS NULL：2008/04/03(木) 20:59:24 ID:???

>>600
そうやって、どんどんぐちゃぐちゃに...

603 ：NAME IS NULL：2008/04/03(木) 21:13:57 ID:???

しかしNULLを許可してしまうとクエリの方がぐちゃぐちゃに・・・。

604 ：NAME IS NULL：2008/04/03(木) 21:41:19 ID:???

1) データ構造がぐちゃぐちゃ
2) プログラムがぐちゃぐちゃ

俺なら、2) の方を選択する。

605 ：NAME IS NULL：2008/04/03(木) 22:04:43 ID:???

グチャグチャではないだろ。Nullableな型というのはNULLを判別するビットが
どこかに埋め込まれてるわけで、それがデータとして表に見えてるか見えてないか。
それだけではないだろうか。

606 ：NAME IS NULL：2008/04/03(木) 22:18:28 ID:???

>>605
テーブルのつくりがぐちゃぐちゃになるか
SQL文がぐちゃぐちゃになるかという話であって

607 ：NAME IS NULL：2008/04/03(木) 22:58:00 ID:???

どっちの手法も確立してると思うが
理由無しにNOT NULLほとんど入れない奴はなんとかしてほしい

608 ：NAME IS NULL：2008/04/04(金) 00:17:21 ID:???

>>606
いやだからテーブルの作りはぐちゃぐちゃではないだろと言ってるわけで

609 ：NAME IS NULL：2008/04/04(金) 00:23:55 ID:???

>>608
キミが言ってるのはテーブルの中のデータの有りようなわけで

610 ：597：2008/04/04(金) 07:06:28 ID:???

>>600
その手もあるんですけど
目的はパフォーマンス対策なんで
なるたけ絞込み条件をORでつなげたくないってのと、
有効期間と他のテーブルの日付カラムをJOINしなきゃいけない場合に
軽くめまいがw

でも、レスありがとうございます。

611 ：NAME IS NULL：2008/04/04(金) 09:02:02 ID:???

NULLと日付不明は別にあらわせるようにして欲しかった

612 ：NAME IS NULL：2008/04/04(金) 11:04:10 ID:???

日付を格納する項目で「Toが未定」って状態を表す設計は微妙な気がする
解決策の一つではあると思うけど日付型に「状態」の意味を持たせるのはイマイチ

ちなみにレスポンスはほとんど（数㍉秒は変わるかも）改善されないと思う・・・
SQLは多少読みやすくはなると思うけど「9999年は未定」って前提を知らない人が見たらｗｗｗｗって思うだろうしな

613 ：NAME IS NULL：2008/04/04(金) 13:15:28 ID:???

論理設計と物理設計の話が混ざると話が進まないね。

>>612
>ちなみにレスポンスはほとんど（数㍉秒は変わるかも）改善されないと思う・・・
IS NULLはフルスキャンになるから、影響はあるんじゃないかな。
つまるところは「計測しろ」となるけど。

614 ：NAME IS NULL：2008/04/04(金) 13:46:15 ID:???

日付型のis nullがフルスキャンになるってどのDBMS？
普通のDBMSならそんなことありえんと思うが・・・

615 ：NAME IS NULL：2008/04/04(金) 13:56:02 ID:???

論理設計と物理設計を分けて考える理由って何？
分けて考える意味が見出せない

616 ：NAME IS NULL：2008/04/04(金) 14:10:30 ID:???

>>614
MS SQLの他はほぼすべてそのはずだよ。一般にNULLは索引に含まれない。
例えばNULL許可のユニーク索引を作ったときNULLのレコードが複数追加できるが、
MSSQLは１件しか追加できない。

617 ：NAME IS NULL：2008/04/04(金) 14:18:20 ID:???

>>614
そうなの？知らなかったよ。どういう理屈かよく分からんけど。

>>615
物理設計ではパフォーマンスのために、NULLの代わりとなる値を入れるとか、導出項目も予め計算しておくとか、そういうことを考慮する。
論理設計ではしてはいけない。

618 ：NAME IS NULL：2008/04/04(金) 15:00:58 ID:???

>>614
いい加減なことをいうなよ。しかも何故か強気で。

619 ：NAME IS NULL：2008/04/04(金) 16:37:16 ID:???

>例えばNULL許可のユニーク索引を作ったときNULLのレコードが複数追加できるが、
>MSSQLは１件しか追加できない。

それはSQLServerのおかしい仕様だと思うが。
漏れはUNIQUE制約のついたカラムにNULLを許可するのはダメ派だ。
つか意味ない。

null可能のカラムにindexを張ってあるならその項目に関してフルスキャンするかは
RDBMSによって動作が違うとｵﾓ。
SQLのオプティマイザのエンジンが索引と統計情報とレコード情報を参照して
NULL情報を検索するエンジンがいくつかあったはず。
DB2とかはNULL情報をブロック単位＆専用ビットで保持しているので、
それらを利用して「最速ケースはどれか？」と判断し動いている。

＞論理設計と物理設計の話が混ざると話が進まないね。

これらを混ぜて考えられないヤツは設計＆実装しないほうがいい。

620 ：NAME IS NULL：2008/04/04(金) 18:43:11 ID:???

>>619は「有効期間のTOが未定」ということがある場合、どういう設計にするの？

621 ：NAME IS NULL：2008/04/04(金) 20:24:16 ID:???

>>620
？
有効期間のTOはユニークにしないし（FROMだけで一意のはず）
>>619の話と関係ないんでは

622 ：NAME IS NULL：2008/04/04(金) 20:38:33 ID:???

>>619
>＞論理設計と物理設計の話が混ざると話が進まないね。
>これらを混ぜて考えられないヤツは設計＆実装しないほうがいい。
おかしなことをいうな
あと「漏れ」とか恥ずかしいから止めろ

623 ：NAME IS NULL：2008/04/04(金) 23:08:03 ID:???

数値なら-1。文字なら空文字。日付型だけNULLの変わりになりそうな値が無い。

624 ：NAME IS NULL：2008/04/05(土) 00:29:52 ID:???

is null は全件スキャンが基本。
そうじゃないのは3値論理をゆがめて実装まっしぐらで
他の所でなにかほころびが出るかも。

この話題は結構実践的かつすんごい有意義なので
なるたけ煽りはなしで続けて欲しい。
色んな現場でも色んなプラクティスが聞きたいです。

625 ：NAME IS NULL：2008/04/05(土) 00:58:09 ID:???

日付型を使わずに文字列形で日付格納してるのが多かった気がする

626 ：NAME IS NULL：2008/04/05(土) 01:12:42 ID:???

Oracleは文字列が多い
DB2は数値型が多い
MSSQLは日時型が多い

多分

627 ：NAME IS NULL：2008/04/05(土) 01:33:26 ID:???

NOT　NULL指定の無いカラムを真っ先に検索しはしないだろう
ふつう

628 ：NAME IS NULL：2008/04/05(土) 08:02:42 ID:???

>>＞論理設計と物理設計の話が混ざると話が進まないね。
>>これらを混ぜて考えられないヤツは設計＆実装しないほうがいい。
>おかしなことをいうな

おかしいと主張するヤツの脳はほとんどの場合おかしい。
こういうやつの設計＆実装は100%くらいの確立で糞だったりする。

629 ：NAME IS NULL：2008/04/05(土) 09:59:47 ID:???

落ち着け。
1行目と2行目が矛盾してるという話だろ

630 ：NAME IS NULL：2008/04/05(土) 10:53:39 ID:???

　　　　　　　＿＿＿_　　　　　　　　　＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　／_ノ　　ヽ､_＼　　　　　(　もう・・・私のばか・・・・！！！
.　　　　　／　（● ）　(● ）＼　　　（　　また本心と・・・・違うこと・・言っちゃったお・・・
　　　　／//////（__人__)///＼　　 ◯　　　ほんとは・・・素直になりたいのに////
　　　　|　　　　　　　　　　　　|　。O　　￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　＼　　　　　　　　　／
　　　　ノ　　　　　　　　　　　＼
　／´　　　　　　　　　　　　　　ヽ
　|　　　　ｌ　　　　　　　　　　　　　　＼
　ヽ　　　 -一''''''"~~｀`'ー--､　　　-一'''''''ー-､.
　　ヽ＿＿＿＿(⌒)(⌒)⌒)　)　　(⌒＿(⌒)⌒)⌒))

631 ：NAME IS NULL：2008/04/05(土) 11:34:47 ID:???

＞is null は全件スキャンが基本。
～
＞この話題は結構実践的かつすんごい有意義なので
＞なるたけ煽りはなしで続けて欲しい。

コイツって前のID厨か？
相変わらず具体例ださずに決め付けてるんだが。

持論以外は認めないのにｸﾚｸﾚしてる辺りがそんな匂いする。

632 ：NAME IS NULL：2008/04/05(土) 18:42:34 ID:???

またか？
ID丸出しでやったら面白いことになるかもな。

633 ：NAME IS NULL：2008/04/05(土) 19:22:57 ID:???

今度はID厨からフルスキャン厨でつか

知識が乏しくマニュアルがないとなんにも出来ないタイプの人間なんだろ。

＞MS　;SQLの他はほぼすべてそのはずだよ。一般にNULLは索引に含まれない。
＞例えばNULL許可のユニーク索引を作ったときNULLのレコードが複数追加できるが、

この辺りはRDBMSによって違うんだからMSSQL(ﾅﾆｺﾚ?前後の文からSQLServerか？)しか
知らん厨が世界の中心みたいに設計を語るのは滑稽だな。

SQLServerが99%くらいシェア獲ってるならともかくなー。

634 ：NAME IS NULL：2008/04/05(土) 20:09:05 ID:???

MSQL知らないってどんだけー

635 ：NAME IS NULL：2008/04/05(土) 20:19:36 ID:???

>>633は人にどうこう意見する前に自分の恥ずかしさを理解すべきだな

636 ：NAME IS NULL：2008/04/05(土) 20:28:21 ID:???

MSQLってマジでどんな製品なんだ？
商用OracleやオープンなMySQLよりもシェア獲ってる製品なのか？

637 ：NAME IS NULL：2008/04/05(土) 20:42:08 ID:???

>>636
MSSQLね、>>634は入力ミス。

638 ：NAME IS NULL：2008/04/05(土) 20:44:55 ID:???

MySQLよりも昔、黎明期のPostgresと同時期に存在した
オープンソースのRDBMSだよ。

639 ：NAME IS NULL：2008/04/05(土) 20:49:54 ID:???

とりあえず、この板のスレ名に使われないくらい有名なRDBMSだな。w

640 ：NAME IS NULL：2008/04/05(土) 21:03:45 ID:???

MSSQL表記知らないとか

641 ：NAME IS NULL：2008/04/05(土) 22:07:53 ID:???

自分も知らなかったけど
「知らないのにえらそうに語ってしまってすみません」でいいじゃん。
なに必死になってんだか

642 ：NAME IS NULL：2008/04/06(日) 00:30:57 ID:???

mSQL

643 ：NAME IS NULL：2008/04/06(日) 06:57:17 ID:???

自分も見たことも聞いたこともないRDBMSだけど、
そんなドマイナーな製品に対して「知らんのか？」と言う方がアタマおかしいと思う。

なに必死に自作自演しているんだか。

644 ：NAME IS NULL：2008/04/06(日) 11:25:01 ID:???

>>643
普通にしてて知らなかったってだけなら
ここまで叩かれないでしょ。
煽った方がばかっぽくなっちゃうのな、ここは。

645 ：NAME IS NULL：2008/04/06(日) 11:42:42 ID:???

スレの流れ的に技術的な話をしている最中に
煽りフルスキャン厨が話の腰を折っている(MSSQL知らんのか？)に見えるんだが。

技術的な間違いのﾂｯｺﾐにはｽﾙｰしているしな。

646 ：NAME IS NULL：2008/04/06(日) 11:45:22 ID:???

確かに間違いを指摘されてから、叩きｶｷｺしかしてねーな。
MSQL厨は。ｗ

647 ：NAME IS NULL：2008/04/06(日) 12:35:23 ID:???

ばれてるよ

648 ：NAME IS NULL：2008/04/06(日) 15:40:17 ID:???

ばればれw
ミッションクリティカル厨だろw

649 ：NAME IS NULL：2008/04/06(日) 20:40:43 ID:???

よほど悔しかったと見える。

650 ：NAME IS NULL：2008/04/07(月) 06:07:38 ID:???

三値理論がいい加減な実装の具体的な例。
postgreSQLの7.x以前のcaseの動作で
case NULL then ....と書くと、true/falseで返ってくる。
8.x以降だとちゃんとunknownになる。

ありゃはまった。まあ、最初にはまるようなSQL書いた俺が悪いのだが。

651 ：NAME IS NULL：2008/04/07(月) 06:08:55 ID:???

おっと間違えた、三値論理。

652 ：NAME IS NULL：2008/04/07(月) 07:14:18 ID:???

と言ってもこのスレ的にはMSQLが全てらしいからなぁ。ｗ

653 ：NAME IS NULL：2008/04/07(月) 10:23:21 ID:???

ちがうよ。このスレは、ミッションクリティカルで
メインフレーム・ホスト・オフコン屋がすべてなんだよ。

句読点の後にwつけるのあんただけだよ。気をつけな。

654 ：650：2008/04/07(月) 10:46:00 ID:???

自分で書いておいてこれはひどい。寝起きに書くのはやめよう。

case hoge when null then "nullです"
else "nullじゃない" end

とか書くと、nullだろうとそうでなかろうと"nullじゃない"と
表示されるべきなんだけど、ポスグレ7.xだと
nullだと"nullです"って表示される。

というような事を書きたかった。
8.xに移行したら表示がおかしくなってまいった。
こんなの書く俺が悪いけど、動いてくれるんだもんなー。

655 ：NAME IS NULL：2008/04/07(月) 17:30:46 ID:???

DB設計関連で、コレは読んどけ！という本があれば教えて下さい

656 ：NAME IS NULL：2008/04/07(月) 22:07:50 ID:???

データベース実践講義

657 ：NAME IS NULL：2008/04/07(月) 23:19:16 ID:???

業務寄りなら渡辺幸三さんの本なんかがよいと思う。こちらは自然キー派。
ID厨ってなに？って人は『楽々ERDレッスン』。
偉そうな文章読んで気分高揚させたい場合は佐藤正美さんのT字形の本。
RDBMSの実装の話で入門編だと『RDBMS解剖学』って本がとてもわかりやすかったです。
設計とは違うけど、設計する時やSQLを書くときに気を使うようになりました。

658 ：NAME IS NULL：2008/04/08(火) 23:15:25 ID:???

659 ：NAME IS NULL：2008/04/08(火) 23:39:24 ID:???

>>654が混乱しているのは確かだけども
> nullだろうとそうでなかろうと"nullじゃない"と表示されるべき
というのは合ってるんじゃないか？

660 ：NAME IS NULL：2008/04/09(水) 01:30:32 ID:???

> 不明な値同士が同じかどうかは識別できません

同じかどうかわからないだけで、必ず違うと言ってるわけじゃないよ。

661 ：NAME IS NULL：2008/04/09(水) 02:21:42 ID:???

>>660
同じかどうか分からないから、foo = NULLはunknownであって絶対にtrueにはならない。
３値論理の話な。

それがpostgresの7系だと間違った実装で、fooがnullの場合にtrueになってたと。
そのダメ実装に依存した「when null」という勘違いSQLを654は書いてたのだけど
8.xに移行したら挙動が変わっててハマったといいたかったのだろう。

662 ：654：2008/04/09(水) 14:13:18 ID:???

>>661
そうそう、その通りです。
だから無知をさらしてるってのは、まあ合ってるんだけど。

三値論理の間違った実装の具体例をあげろみたいなレスが
あったから参考までにって書いただけなのに・・・・。
なんでここは>>658みたいなのがわくんだか。
例のホスト屋さん？

663 ：654：2008/04/09(水) 14:19:47 ID:???

ああ、俺が "nullじゃない" なんて文字列を
例に使ったのが紛らわしかったのか。

else "nullじゃない" end だから、unknownだったら
こっちが表示されるべき、ってことです。
お騒がせでした、煽ってごめん>>658

664 ：>>660：2008/04/09(水) 21:37:50 ID:???

>>661-662
すまん、その通りだ。

ちょっと勘違いしてた。orz

665 ：NAME IS NULL：2008/04/09(水) 23:36:18 ID:???

ＤＢの設計とはちょっと違うけど、セキュリティはどうしてますか。
もしユーザーが悪意を持ってＤＢにアクセスしてきたらと思ったら
つまってしまいます・・・。内部の人間がデータぶっこぬきとか

666 ：NAME IS NULL：2008/04/09(水) 23:54:14 ID:???

>>665
内部の人間とは、アカウントのユーザー名とパスワードを知っている人間ということ？
だとしたら、打つ手はない。

新聞やテレビでしばしばみるのは、開発者による違法アクセス。
これなんかお手上げだよね。

667 ：NAME IS NULL：2008/04/09(水) 23:59:59 ID:???

DBA権限持った人間がデータ抜けないようにするって話なら
リムーバルメディア使えなくしたり
施錠や警備員等物理的セキュリティをしっかりさせたり…
本当に関係ない話になっちゃうな

668 ：654：2008/04/10(木) 00:03:54 ID:???

>>664
いやいや俺もここ最近の荒れ具合から
脊髄反射みたく煽っちゃってごめんなさい。

でも俺が無知なSQLを書いちゃったのは本当だからさw
みなさん反面教師にしていただければこれ幸い。

>>665
セキュリティは、ロジックを伴う所はアプリ任せにしてます。
この権限の場合はこのデータが見れる、とか。
如実にお客様からの要件が反映される所だから。
で、アプリからはひとつのDBのユーザーで接続するようになってて
他のユーザーは最初から作らない。

制約をどこまでDB側に持たすかって話と近いかも。

内部の人間がぶっこぬきとかの話はもう
ソーシャルエンジニアリングの世界だからアプリだろうと
DBだろうと、やる奴はやるからねぇ・・・・・。

669 ：NAME IS NULL：2008/04/10(木) 00:06:15 ID:???

データベース管理者が違法アクセス防止のために、ユーザー名とパスワードを頻繁に変更できる
ようにしとけば安心かな？

でも、そこまでやっているＤＢシステムか見たことがない。多くがプログラム埋め込み。

670 ：NAME IS NULL：2008/04/10(木) 00:14:00 ID:???

正直、内部の人間が不正アクセスでデータが抜かれるのはある意味仕方ないと言うとアレだが
DBにしてみれば不正も正当も区別がつかないので、ジャーナルとかで
アクセス記録とっておけばいいんじゃね？って感じだな。

671 ：NAME IS NULL：2008/04/10(木) 00:20:27 ID:???

監査証跡（audit trail）というやつか

672 ：NAME IS NULL：2008/04/10(木) 20:01:24 ID:???

今やってるのが漏れると損害賠償でうん億円の世界なのでびびってます・・・

673 ：NAME IS NULL：2008/04/10(木) 20:37:38 ID:???

主キー　顧客コード　表示順　　名称
120　　　　　50　　　　10　　ＸＸＸＸ
105　　　　　50　　　　20　　xxxxxx
110　　　　　50　　　　30　　ＸＸＸＸ
106　　　　　90　　　　10　　ＸＸＸＸ
104　　　　　90　　　　20　　YYYYYYY
111　　　　　90　　　　30　　@@@@@@@

今使っているシステムでこんなテープルがあります。
同一顧客コード内でレコードの表示順番を制御するために「表示順」列を設けています
。
　「表示順」列は重複許可でNULL不許可。
　　同一の顧客コードのレコード数は1～50件程度で不定。
今は、表示順番を変えるために、このテーブルの修正入力画面で表示順の数値を手入力
しています。
リストビューやツリービューみたいな画面でレコードをドラッグ＆ドロップ等で簡単に
できたらと
考えてるんですけど、このテーブルに対して、
　● クライアント画面で、レコードをドロップしたら表示順番を更新するストアドを呼
び出す。
という処理でいいんですかね。
それとも「表示順」列で制御、っていう考え自体おかしくて、見直した方がいいですか。

近くこのシステム全体を作り直すんで、テーブル設計自体が変だったらそこから直しち
ゃおうか
と思ってるんですが。

674 ：NAME IS NULL：2008/04/10(木) 21:14:13 ID:???

何のテーブルか分からん

675 ：NAME IS NULL：2008/04/10(木) 21:18:00 ID:BYawDpKG

名寄せだろ

676 ：NAME IS NULL：2008/04/10(木) 21:27:47 ID:???

表示順カラムは別におかしくないよ。
順番の更新処理はストアドでもホスト言語ででもどっちでもいいんじゃね？

677 ：NAME IS NULL：2008/04/10(木) 21:37:11 ID:???

>>673
データをデータベースに反映させるタイミングは考えたほうがいいだろうね。
ドロップ時点で即座に反映する必要性はどの程度あるのかとか。

678 ：NAME IS NULL：2008/04/10(木) 22:30:38 ID:???

表示順の変更以外はありえない、というケースは少なくて
大概は画面で顧客名変更やレコードの追加・削除もありうるから
決定ボタン押したタイミングで顧客コードでDEL/INSが普通かなぁ。

679 ：NAME IS NULL：2008/04/10(木) 22:47:05 ID:???

ちょっと基本的な質問ですまん。
高速道路のETCゲート通過とETCカードとWEB上でのETC利用歴検索
のリンクがどうなってるのかちょっと知りたい（興味半分だけど）
皆さん忙しいと思うけどよろしく頼みます。

いや、この前ねある病院で電子カルテシステムがダウンしたのよ。
その当日に出くわしてね、本日のすべての処理は紙の伝票システムで
運営するとの事、医者は紙のカルテに書くのは久しぶりだとかで手間取り
診療科目をまたぐと大変時間がかかるし、医療事務の精算はできないし
投薬の履歴は出てこないしとさんざんだった。
そこで思ったのがETCシステムのことでしたね、あの膨大なデータの
処理をどうしてるか気になりだして仕方なくなりました。

680 ：NAME IS NULL：2008/04/10(木) 22:49:31 ID:???

確か日本野鳥の会がやってたはず

681 ：NAME IS NULL：2008/04/10(木) 23:55:54 ID:???

>>679
WEB上でのETC利用歴検索はリアルタイムというわけではないでしょう。

682 ：NAME IS NULL：2008/04/19(土) 16:10:53 ID:???

病院のシステムって二重化してないんかｗ

683 ：NAME IS NULL：2008/04/19(土) 16:48:07 ID:???

カルテシステムとかだと、ダウンタイム "0" を要求されるわけじゃないから、
ハード障害には当日オンコール保守で対応と言うのがが多いんじゃないかな。

あと二重化してあってもソフトのバグとかで両系ダウンすることもあるし。

684 ：NAME IS NULL：2008/04/19(土) 17:13:10 ID:???

電カルは医療機器の組み込みとは違うもんね。

うちのヨメの勤め先でも電カルがダウンした時は
忙しかったけどまあ手でなんとかしのいだって。

685 ：NAME IS NULL：2008/04/19(土) 19:56:28 ID:???

オーダリングのみのダウンならば、導入以前の紙の伝票を回しての運用に戻せばいいんだろうけど、
電子カルテがダウンしたらどうなるんだろうか。カルテが参照できないってこと？診療自体がストップしない？

686 ：NAME IS NULL：2008/04/19(土) 21:47:21 ID:???

時系列の変化は見えなくなるけど、目の前に患者はいるんだし現在の検査数値は
見えるんだから最低限の診療はできると思うよ。

まあ、ほんとのところは医者に聞かないとわからないが...。

687 ：NAME IS NULL：2008/04/20(日) 00:02:29 ID:???

>>685
ヨメに聞いてみた。
電カル導入以前からあった基幹システムみたいなのがあって、
それが機能拡張で電カルの保存サーバみたく機能してたので、
参照は出来たんだって。その日の分は紙で回して
診療がストップする事はなかったけど
何が大変って受付業務がてんやわんやだったらしいです。

688 ：NAME IS NULL：2008/04/20(日) 00:20:58 ID:???

自動受付機と自動会計機が停止してしまうからでしょう。
受付と会計のすべてが手動作業になる。これが一番大変。
受付担当者も大変だが、患者さんも長時間待たされることになる。

あとは処方かな。システムが稼動していれば、処方は前回のコピペでほぼ済むんだが、
システムが停止してしまうと、医者は手書きで処方箋を書かなくてはならなくなる。

システムが停止するのは、開発運用者にとっては最大の汚点のひとつなのだが、
システムの有用性・価値を認識してもらう機会でもあるわけだ。
もちろん、ないに越したことはない。

689 ：NAME IS NULL：2008/04/29(火) 22:35:25 ID:476VLZj4

マスタとトランザクションデータのカラム設計について。

マスタは、データを履歴管理（＝マスタデータの有効期間）で持っているとします。
トランザクション発生時において、
マスタのデータをトランザクションデータ内にコピーするかどうか、
どのような方針が適切なのでしょうか。

具体的には、下記テーブル設計の場合に、
　○Tマスタ（master_id, master_data, 有効期間）
　○Tトランザクションデータ（tx_id, master_id, tx発生日）
Tトランザクションデータにカラムmaster_dataを設けるかどうか、ということです。

カラムを設けない（＝TマスタをTトランザクションデータから常に参照する）というのが綺麗なのは分かります。
ただ、実運用上で問題が出ないかどうかが心配です。
たとえば、ある一部のトランザクションだけマスタデータの値の修正をする必要が出るとか。

690 ：NAME IS NULL：2008/04/29(火) 23:07:02 ID:???

>>689
１．マスターの有効期間が変化する。常に最新の期間条件で読み出す必要がある。
２．マスターの有効期間は変化しない。
３．マスターの有効期間は変化するが、登録時の情報を参照すればよい。
１の場合は仕方ないとして、２，３の場合は有効期間をキーにしないで、
有効期間が異なれば別のIDをふる、または、ID＋履歴番号をキーとする。
やり方はケースバイケースであるが、主キーに有効期間そのものを含んでたら
間違った設計と思ったほうが良い。

691 ：NAME IS NULL：2008/04/29(火) 23:18:39 ID:???

>>689

おまい、>>335か？まだ悩んでたのか。

692 ：NAME IS NULL：2008/04/29(火) 23:21:13 ID:???

日付の項目と複合でPKにするのは煩雑杉て保守で死ぬ予感
綺麗かもしれないけど、管理する必要があるかどうかで判断してみては？

693 ：NAME IS NULL：2008/04/30(水) 02:47:41 ID:???

元気かなあ、あの句読点の後にwの人。

694 ：NAME IS NULL：2008/04/30(水) 13:51:07 ID:1zoOlTvF

aiueo

695 ：NAME IS NULL：2008/04/30(水) 13:51:36 ID:1zoOlTvF

www.oracle.co.jp
otn.oracle.co.jpがみれないんだけど。。

696 ：NAME IS NULL：2008/04/30(水) 14:45:55 ID:???

両方ともトップページは普通に開けるけど。

697 ：sage：2008/04/30(水) 15:15:50 ID:1zoOlTvF

みれました。すいません。なぜかFireFoxでは見れませんでした。
IEで見れました。お手数おかけしました。
でもなんでだろう。なにか設定しちゃったのかな。。。
どうもです。

698 ：NAME IS NULL：2008/04/30(水) 20:38:22 ID:kArgI2Pd

Windowsのエクスプローラのような再帰的な階層リストを、DB化しようと思ったのですが、
考えてみると意外と難しい。。

階層フィールドを作って、ゴリゴリ頑張るような設計しか思いつかないのですが、
スマートな設計がありましたら、ぜひ伝授して下さい。

よろしくお願いします。

699 ：NAME IS NULL：2008/04/30(水) 21:25:52 ID:???

普通に

create table 階層リスト (
　id int not nul primary key auto_increment,
　上位 int, -- 上位ノードの id を指す
　情報1 ...,
　情報2 ...,
　...
);

でいいんじゃないかな。

使うには、再帰 SQL を覚えておいた方がいいけど。

700 ：NAME IS NULL：2008/04/30(水) 21:53:38 ID:???

正直iノードを自前で実装するのと大差なくなってくると思うが。

701 ：NAME IS NULL：2008/04/30(水) 22:35:47 ID:???

まあ、定番だからな。

702 ：NAME IS NULL：2008/05/01(木) 10:30:29 ID:???

生産管理のデータベース設計の本とか参照するとか。
BOMは大変だよなー。

703 ：698：2008/05/01(木) 14:14:39 ID:???

>>699-702
thx!

上位ID + 階層でやってみます。

再帰SQLは、SQLServer2005から対応との記述をみました。
2000では無理そうですが、プログラムの方でなんとかしてみようかと思います。

704 ：NAME IS NULL：2008/05/01(木) 23:21:38 ID:???

こういうのは普通はCで実装するからなぁ。

705 ：NAME IS NULL：2008/05/03(土) 18:52:29 ID:???

全てのテーブルに必ず対応するビューを定義するって設計は実際ありますか？

706 ：NAME IS NULL：2008/05/03(土) 18:56:46 ID:???

>>705
無い

707 ：NAME IS NULL：2008/05/03(土) 19:29:13 ID:???

コッドが泣いてる

708 ：NAME IS NULL：2008/05/03(土) 20:47:09 ID:???

>>705
設計ではないが要望されてやった事はあるな。
英数字のカラム名しか認めないRDBMSに接続するAccessがあって、
「英語のカラム名はよく解らん」と言う理由でAccess上に日本語カラムを入れた
ビューを作った事はあるけど・・・。

でも意味のないビューは作らないとｵﾓ。

709 ：NAME IS NULL：2008/05/03(土) 21:30:30 ID:???

昔はよくやったな。
参照は全てビュー経由にすることで、
項目変更などの影響を受けにくくする、
みたいな目的で。

今はビュー作るの自体が流行らん感じ

710 ：NAME IS NULL：2008/05/03(土) 21:55:11 ID:???

>>709
>今はビュー作るの自体が流行らん感じ
そうなん？マテビューとか便利だしちゃんと設計されたDBにアクセスするなら必須だと思うけど？

711 ：NAME IS NULL：2008/05/03(土) 22:15:39 ID:???

ちゃんと設計されたDBでビュー使うメリットって基本的にないからね。
アプリケーションフレームワークが関連までサポートしてくれる現状、
DB側でおせっかいされてもうっとうしいだけだし。

マテビューは使うけど、ありゃ厳密にはビューじゃないしな

712 ：NAME IS NULL：2008/05/03(土) 23:12:15 ID:???

そんなアホポリシーをわざわざ披露してくれなくてもいいよ。

713 ：NAME IS NULL：2008/05/04(日) 01:23:41 ID:???

>>711
すまんな、「ちゃんと設計されたDB」の認識が全然違ったみたいだ

714 ：NAME IS NULL：2008/05/04(日) 09:08:17 ID:???

今のビューの使い方だと「ちゃんと設計されてないＤＢ」を「ちゃんと設計されたＤＢ」に仲間入り
させる時に使うくらいだなぁ。

横長ＤＢを普通のＤＢにするとか。

715 ：NAME IS NULL：2008/05/04(日) 12:22:17 ID:???

マテビュはパフォーマンス目的だしな

変更に強くなる・・・っていう目的で使ってる奴いないの？
情報処理の試験でそう覚えたからなんかがっかりだよ

716 ：NAME IS NULL：2008/05/04(日) 12:53:42 ID:???

まあ、ちゃんと設計されてれば >>714 みたいな本来不要なビューは
なくなるんだろうけど、ちゃんと設計されてても有益なビューはあ
ると思うぞ。

717 ：NAME IS NULL：2008/05/04(日) 13:36:45 ID:???

正規化したらアプリインターフェースとしてテーブルは余り適さないと思うんだけど・・・
専用DBは除いて。

718 ：NAME IS NULL：2008/05/04(日) 13:38:49 ID:???

>変更に強くなる・・・っていう目的で使ってる奴いないの？
>情報処理の試験でそう覚えたからなんかがっかりだよ

逆に聞きたいんだが「変更に強いビュー」と言う例をあげてくれないか？

正直、強いも弱いもないと思うが。

719 ：NAME IS NULL：2008/05/04(日) 13:43:27 ID:???

＞正規化したらアプリインターフェースとしてテーブルは余り適さないと思うんだけど・・・

こういうExcelやCOBOL志向の人が横長ＤＢを作って他のエンジニアから
ウザかられるんだろうなぁ。

720 ：NAME IS NULL：2008/05/04(日) 13:47:47 ID:???

なんだGWか・・・

721 ：NAME IS NULL：2008/05/04(日) 16:38:51 ID:???

>>718
> 逆に聞きたいんだが「変更に強いビュー」と言う例をあげてくれないか？

「変更に強いビュー」じゃなくて、(テーブルの変更を) ビューで吸収する
ことで、テーブルの変更に強い (=アプリ側の変更をしなくて済む) ように
するってことだろ。

722 ：NAME IS NULL：2008/05/04(日) 17:00:30 ID:???

単にアプリ側の修正で済むかRDBMSの修正で済むかの違いなんだろうけど、
現実的にテーブルの変更をビューで吸収する設計ってあんま見たことないが。

アクセス権とかユーザーに見せたくないカラムがあったりするとかそういう意味で
ビューを用意する事はあるけど、「変更ありき」でテーブル＆ビュー設計って
やってる人は見たことないなぁ。

723 ：NAME IS NULL：2008/05/04(日) 17:24:05 ID:???

お前の周りはそう言う開発ポリシーなんだろ。

別に何の問題もない。

でかいシステムで

・DB 周りの設計者とアプリの開発が別組織

なんかのケースだと、アプリの変更はおおごとになるからビューで
何とかするのは割と良くある話。

724 ：NAME IS NULL：2008/05/04(日) 17:57:05 ID:???

お前の周りはそう言う開発ポリシーなんだろ。

別に何の問題もない。

でかいシステムで

・DB 周りの設計者とアプリの開発が別組織

なんかのケースだと、ＤＢの変更はおおごとになるからアプリで
何とかするのは割と良くある話。

-----

つか別組織って別会社でもあるまいし。
小さい組織の自称「でかいシステム」はビューでなんとかするかもしれんな。

725 ：NAME IS NULL：2008/05/04(日) 18:42:20 ID:???

> つか別組織って別会社でもあるまいし。

別会社のケースもあるよ。

そう言うシステム知らんだけだろ。

726 ：NAME IS NULL：2008/05/04(日) 18:59:18 ID:???

アプリ変更するとテストがたくさん発生するからやっかい
それに作った奴らなんて数年したらいなくなるし
仕様書なんてまともに残ってねぇ

最適解は次回リプレース時のどさくさにまぎれて変更だ

727 ：NAME IS NULL：2008/05/04(日) 19:21:05 ID:???

ビューの方が好き勝手に作っても迷惑かける分が少ない

728 ：NAME IS NULL：2008/05/04(日) 22:02:34 ID:???

>>724
ある程度の規模なら別会社が普通だよ。
「出来ませんでした」の影響を最小限にとどめる。
血税使う所は例外だった気もするが・・・

729 ：NAME IS NULL：2008/05/05(月) 01:42:56 ID:???

>>723
そのくらいの規模でやっていれば、たとえ論理的にイコールでアプリに直接影響が
出ない変更であっても、確認・検証は必要だしそれなりにおおごとになるのでは？
一方で、ビューで吸収できる変更というのは、ビューを使っていなかったとしても
DB側だけで解決できるものだから、アプリ開発が別組織だったとしてもビューを
使う理由になるとは思えん。
本当にそんなによくある話なのか？

730 ：NAME IS NULL：2008/05/05(月) 07:56:43 ID:???

結局、どちらが修正コスト低いか？なんて現場によりけりなのに、
「ビューの方が変更に強い」なんて迷信を信じてるのがオカシイってだけだと思うが。

なんかマニュアル命で現場によって技術を使い分ける事を知らん厨が
声だかに喚いているだけに思えるが。

731 ：NAME IS NULL：2008/05/05(月) 08:20:32 ID:???

>>729
> DB側だけで解決できるものだから

テーブル変更しろって？

もう少し実務に携わってから書き込んだほうがいいと思うよ。

テーブル変更のリスクは経験しないと分からんことも多いから。
(普通の頭もってりゃちょっと考えれば分かるとも思うけどな。)

>>730
「現場によりけり」「技術を使い分ける」と書きながら、
「ビューの方が変更に強い」を迷信と断言するあたりが
バカっぽいんですが、今時釣りでしょうか？ (w

732 ：NAME IS NULL：2008/05/05(月) 09:05:23 ID:???

ナニこのヒト？
学生？

733 ：NAME IS NULL：2008/05/05(月) 09:24:07 ID:???

>>731
いずれにせよ実表の変更なんてものはたいへんなことだ。特に大規模案件であれば。
ビューで解決すればリスクが小さいなんてことはないし、ましてや最初からそれを
織り込んだ設計をするなんて非常に考えにくいんだが。

そもそもここで想定している変更とはなんだ？
フィールドの追加か？それとも実表の分割か？

734 ：NAME IS NULL：2008/05/05(月) 15:36:10 ID:???

何回書いてもわからん奴っているんだな...。

「現場によりけり」「技術を使い分ける」んだろ？

・ビューで解決のリスク < アプリで解決のリスク

のケースがあるということぐらい想像できないのか？

もし常に

・ビューで解決のリスク > アプリで解決のリスク

だと言うなら、それを証明してくれ。

735 ：NAME IS NULL：2008/05/05(月) 16:59:28 ID:???

物理表にはアクセスしないようにするのが真のRDBの定義だっけ

736 ：NAME IS NULL：2008/05/05(月) 18:50:21 ID:???

>>734
まぁGWだしさ、放置ﾏｼﾞｵﾇﾇﾒ
設計概念からビューの位置付けまで全然違うんだから

737 ：NAME IS NULL：2008/05/05(月) 20:54:26 ID:???

ビューって管理がめんどい。
ER図に表現できないから、たくさん作ったらわけわからんくなる。

なんかいい方法ある？

738 ：NAME IS NULL：2008/05/06(火) 08:12:41 ID:???

>>734
アプリ修正の話じゃないよ。

>>723の言うような、アプリ変更を避けるために予めビューを介してアクセスするような
設計が本当に大規模事案で本当に「よくある」話なのかどうか、そして、それは
テーブル直接アクセスに比べてどのような変更のケースで優位なのかという話だ。

739 ：NAME IS NULL：2008/05/06(火) 09:46:02 ID:???

1つのテーブルに2つ以上のサブシステムがアクセスしている場合、
ビューを用いたほうが改修とテストが少ない場合がある

サブシステムAを改修したいのに、サブシステムBまで改修する必要がでてくるのは面倒
別ビューで参照しとけばテストも不要だしね

740 ：>>723：2008/05/06(火) 11:16:17 ID:???

>>738
> アプリ修正の話じゃないよ。
> アプリ変更を避けるために

言ってることがさっぱりわからん。

修正と変更が違うと言いたいのか？

> 本当に「よくある」話なのかどうか

ああ悪かった、「俺の職場では」良くある話だ。

これで満足か？

# 理解 {できない|しようとしない} 奴にも何を言っても無駄。

741 ：NAME IS NULL：2008/05/06(火) 16:21:43 ID:???

>>737
>ER図に表現できない
「表現」の捉え方が違うンだと思うが、出来ない事無くないか？
大概のER図作成ツールにはビューはあるし。

俺は一応ER図に載せて、定義書も書いて（出力して）ある。

742 ：NAME IS NULL：2008/05/06(火) 19:38:05 ID:???

で、どんどんビューが増えて、結果的に負の遺産となる。ってパターンだろうなぁ。

743 ：NAME IS NULL：2008/05/06(火) 20:11:21 ID:???

はいはい、君の言うことは全て正しいから、満足したらさっさと巣に帰れ。

744 ：NAME IS NULL：2008/05/06(火) 20:36:33 ID:???

なんでこんなに必死なんだろう？

745 ：NAME IS NULL：2008/05/06(火) 21:22:59 ID:???

どうせそのうちまた被害妄想と自演認定始めるんだろ。
またの登場を待ってましたよ。

746 ：NAME IS NULL：2008/05/06(火) 22:02:35 ID:???

きっと自分のいう事は全て正しいと思い込んでいるんだろな。

だから、ちょっとした反論があると「奴にも何を言っても無駄。」と
思考停止に陥るおこちゃまってトコだろ。

747 ：NAME IS NULL：2008/05/06(火) 22:05:54 ID:???

つかツッコミうけると排他主義者はすぐファビョるよな。

748 ：NAME IS NULL：2008/05/06(火) 23:14:34 ID:???

つかみんな小規模か作り投げしかして無いの？
739なんて至極まっとうな事書いてると思うけどスルーだし・・・

正直、738は日本語ムツカシイ人でしょ。読んでくと小規模って言われてファビョっちゃった感アリアリ。

749 ：NAME IS NULL：2008/05/06(火) 23:52:48 ID:???

俺も >>739 は正しいと思う。

ただ正しいことが理解できない奴が暴れてるだけでしょ。

GW も終わりなので、スルーしときましょ。

750 ：NAME IS NULL：2008/05/07(水) 08:10:26 ID:???

>>740
いや、>>729 >>739ではアプリ修正を「しない」前提でビューで解決する場合と
テーブルを直接変更する場合の比較だから。

>>739のようにサブシステムごとに異なるビューを介してアクセスする設計も
ありはするが、一般的には>>722の言うような目的だろう。
将来の変更へのバッファとしてみた場合、それが有効である条件とういうのは
限られていると思っているんで、どのような変更を想定していたのか聞いてみた
だけだが。

751 ：NAME IS NULL：2008/05/07(水) 08:46:47 ID:???

レス内容から分かるレベルで経験無いのに一般的とか使うかね・・・

752 ：NAME IS NULL：2008/05/07(水) 20:39:03 ID:???

日本語でおｋ

753 ：NAME IS NULL：2008/05/07(水) 20:59:02 ID:???

>739のケースでひとつのテーブルに複数のシステムがあったらとか言っているけど
table1 {col1 int,col2 int,col3 char(10)}とかあったとして
このテーブルに二つのサブシステムだろうが、二つのプログラムだろうが、
select col1 from table1やらselect col2 from table1やら別々クエリ投げていたとして
こういうのでビューを使う必然ってドコにあんの？
仮にここでcol3 char(10)がcol3 char(12)になったらcol3を使うクエリ部分のアプリ修正が
入るのは必ずあると思うけど。

もしかしてビューで left(col3,10) as col3とか定義してアプリ側は修正なし！とか
言うのは違うだろ、と思うけ。郵便番号とか会員IDとかサ。leftならともかく
rightやmidな変更をビューで吸収しようなんて漏れは考えないけど。
たとえアプリの修正がなくてもテストはするだろうし。
そんな変更要件ならアプリ側で「leftで読んで、そこをユニットテスト汁」と言うけど。
>>722が言っているのはこういう変更を見越して（ｗ）、全てのテーブルにビュー定義
している人は多くないだろ、って事だとｵﾓ。

754 ：NAME IS NULL：2008/05/07(水) 21:12:14 ID:???

>>753
ビューを作成する主な目的は
複数のテーブルがあって、それがあるキーによってリンクしているようなケースだろ

つまり、JOINしたものをアプリケーション側にひとつのテーブルとしてみせる
ということ

755 ：NAME IS NULL：2008/05/08(木) 22:08:30 ID:???

>>754
そういう目的であらかじめビューを作っておくというのは、後から

create view table_a as
select hoge, hoge
from real_table_a
join real_table_b

のように変更できるよう、最初から

create view table_a as select * from real_table_a

として作っておくということなのかな？激しく無意味な気がするが。
そうじゃないとするとどういう意味なんだろう？

756 ：NAME IS NULL：2008/05/08(木) 23:29:33 ID:???

RSSリーダーの設計を下記のようにしました。
User *---1 Subscription 1---* Feed 1---* Item

Rails的にはこうです。
User
has_many :subscriptions
has_many :feeds, :through=>:subscriptions

Subscription
belongs_to :user
belongs_to :feed

Feed
has_many :subscriptions
has_many :users, :through=>:subscriptions
has_many :entries

Entry
belongs_to :feed

このとき、あるユーザの購読しているFeedのEntry全部を日時順にまとめ読みしたい場合
order by entries.created_atとしますが、mysqlのexplainでどうしてもfilesortがでてしまうとおもいます。
こういった関係になるケースは割とあると思うのですが、どう対処したらよいのでしょうか。
filesortは気にしない、UNION、サブクエリ、アプリ側でソート、etc...

757 ：NAME IS NULL：2008/05/09(金) 07:21:29 ID:???

>>754
>ビューを作成する主な目的は
>複数のテーブルがあって、それがあるキーによってリンクしているようなケースだろ

だろ、って断定されても困るが。
その理屈だと「全てのアプリはそのアプリに割り当てられたビュー経由でしかアクセスは
許しません」って設計思想なんだろう。

正直、手間と管理コストばかりかかって廃れていくと思う。

758 ：NAME IS NULL：2008/05/09(金) 21:44:41 ID:???

実際俺の周りでは廃れてきた。
経験的に、面倒くさいだけってことがわかってきたようだ

759 ：NAME IS NULL：2008/05/10(土) 08:41:35 ID:???

今の時勢でDB触る開発内にこんな奴いるんだな・・・

760 ：NAME IS NULL：2008/05/10(土) 09:14:41 ID:???

なんかこのスレって、胡散臭い教科書に載ってた過去の都市伝説を信じて
「俺の大規模システムの職場では・・・」とか偉そうに語るやつがいるけど
実際に現場の実装レベルの話で具体的に反論されると
「今の時勢でDB触る開発内にこんな奴いるんだな・・・」なんて
子供な捨て台詞を言う素人がウザいな。

悔しいなら具体的に証明すればいいのに。

761 ：NAME IS NULL：2008/05/10(土) 09:32:04 ID:???

>>760
大規模経験無い人間が書いた「実際に現場の実装レベル」ってどんなレベルだよｗ
みんな頑張って相手してあげてるじゃん。こんなアホ臭いレベルに

762 ：NAME IS NULL：2008/05/10(土) 10:16:08 ID:???

前から思ってるんだけど、
「大規模やったことないだろ」とか
「ミッションクリティカルなやつでは通用しないよ」って
いわれたらさ、
「小規模やったことないだろ」とか
「軽いシステムじゃ通用しないよ」とか
言い返せばいいんじゃないの？

763 ：NAME IS NULL：2008/05/10(土) 10:57:26 ID:???

ビューとかストアドとかはＤＢ屋が業務に関わるための死線だから、
どうしても擁護に必死になってしまうのは仕方ない。

でも、最近はアプリ側のフレームワークがなんでもしてくれるようになって
DBサイドでどうにかしようってのは本当に減ってきたね。

764 ：NAME IS NULL：2008/05/10(土) 11:17:39 ID:???

そもそもDB屋がいなくて困っている……。

765 ：NAME IS NULL：2008/05/10(土) 13:07:09 ID:???

>>762
つか、単に現実味のない話をする妄想なビュー信者の厨房はスルーすればいいのでは？

なんだかんだ言って具体的な技術論になると逃げて「アホ臭いレベルに！」とか
涙目になってキーボード叩くだけの無能だし。

766 ：NAME IS NULL：2008/05/10(土) 13:08:52 ID:???

＞ビューとかストアドとかはＤＢ屋が業務に関わるための死線だから、
＞どうしても擁護に必死になってしまうのは仕方ない。

ああ、だから涙目になって反論しているか。

767 ：NAME IS NULL：2008/05/10(土) 13:27:27 ID:???

>>765
うーん、ビューの話に限らず、IDの話の時もNULLの話の時も、
なんかすぐに「大規模だと通用しない」とかって話になるじゃん。
まさか同一人物だとは思わないけど、でもそれも真実ではあるんだよ。
確かに通用しないんだろうから。

でもさ、じゃあ大規模のやり方が中小規模のシステムで
通用するかっていうと、そうじゃないじゃん。
なのに、「大規模は～」って言われると黙っちゃうのが不思議なんだよなー。

ってそんだけ。

768 ：NAME IS NULL：2008/05/10(土) 14:00:17 ID:???

>>762
規模の大小ってのは漠然としすぎているかも知れんが、そういう前提条件を
明確にして議論してりゃ別に問題ないはずなんだよな。

例えば他スレでPreparedStatementの議論があったけど、一般的には推奨される
PreparedStatementも、データの分布に偏りがあるデータベースでは必ずしも最適な
実行計画が得られないし、1クエリに何分もかかるような分析アプリケーションでは
パース・実行計画のコストよりも実行計画自体が最適であることの方が重要だから
動的SQLが使われることが多かったりするわけだ。
これは一般的な例ではないかもしれないけれども、「一般的な常識」が必ずしも
すべての場合で有効とは限らない例ということで。

769 ：NAME IS NULL：2008/05/10(土) 14:06:59 ID:???

> 「現場によりけり」「技術を使い分ける」

と自分で書きながら、実践できてない奴が暴れてるだけだろ。

ビュー信者もウザイけど、フレームワークがどうのこうのとか言ってる奴も
同レベルだし。

770 ：NAME IS NULL：2008/05/10(土) 14:48:38 ID:???

大規模はとりかえしのつかない設計を引きずってるところが多いからあてにならない

771 ：NAME IS NULL：2008/05/10(土) 21:08:52 ID:???

全然技術な話じゃなくインターフェース定義なんだけどねぇ・・・

アプリ側で考えみなよ
別会社が設計したER図ポンと渡されてちょっとした説明だけとアプリ要求に即したビューがあるのと。

そのインターフェースさえ崩れなければ
改修時はアプリ側は最悪UPDATE側のテストだけで済むからコスト大幅に減るし、
開発時は最低限SELECTが簡易になってるからコスト減るしねぇ。

それが何故かビュー=制約の前提だからねぇ、ちゃんとビューの説明もしてもらってるのに・・・

772 ：NAME IS NULL：2008/05/10(土) 22:25:07 ID:???

>>771
そういうのもあるけど、そういう場合って必須キー指定、JOIN禁止とかにしてない？
要はアプリ開発側に勝手なSQL書かせてパフォーマンス障害を起こさないよう、
DB設計側でアクセス方法を指定するやりかた。
似たようなのでは、ビューを作らずともSQLをまんま渡して、これだけを使え、
ってのもあるよな。
逆に、アプリ開発側でSQLも組むんであれば、ビューの中身がブラックボックス
だとかDB側で勝手に変更するとかは考えにくいけど。

773 ：NAME IS NULL：2008/05/10(土) 23:11:29 ID:???

> そういう場合って必須キー指定、JOIN禁止とかにしてない？

そうであるところもあるし、そうでないところもある。

> DB側で勝手に変更するとかは考えにくいけど。

自分が変更するにしても、DB 側だけで済む方が楽なケースだってあるだろ。

# 自分の世界が常に正しいと信じてる人なのか...。

774 ：NAME IS NULL：2008/05/10(土) 23:21:02 ID:???

>>772
このスレは制限するのが大好きだなｗ
方向性が全然違うんだが・・・

インターフェース定義はアプリ開発会社ときっちり詰める、どう使われるかなどね。
まぁ、ER図渡す場合にきっちり詰めても、タスクがアプリ会社に移るかこっちで持つかの違いだけ。
諸事情ありこっちで受けた。

775 ：NAME IS NULL：2008/05/11(日) 06:59:26 ID:???

>> DB側で勝手に変更するとかは考えにくいけど。
>自分が変更するにしても、DB 側だけで済む方が楽なケースだってあるだろ。
># 自分の世界が常に正しいと信じてる人なのか...。

自分の世界が常に正しいと信じてる人の典型的なレスだな。

その楽なケースを具体的に説明して欲しいモノだ。
存在しない脳内妄想なんだろうけど。

776 ：NAME IS NULL：2008/05/11(日) 10:33:33 ID:???

>>774
ちゃんと情報共有してんならごく普通でない？

問題があるとすれば、どういう使い方しているか把握していないのに
連絡もせずにビュー定義の内容を変更するとかしちゃう場合だろうね。

777 ：NAME IS NULL：2008/05/11(日) 11:38:28 ID:???

>>775
> その楽なケースを具体的に説明して欲しいモノだ。

例えば１つのデータベースに複数のアプリがアクセスしているなら、
いちいちアプリを変更するよりデータベース側を変更する方が楽な
場合があると言うことぐらい、ちょっと脳味噌あったりわかりそう
なもんだが...。

778 ：NAME IS NULL：2008/05/11(日) 14:29:08 ID:???

>>775
だから調整とかインターフェース定義経験無いでしょｗ
わかりやすいように772に書いたんだけどねぇ・・・
って単なる鸚鵡返しの煽りかｗ

>>776
それを制限の方向に独自解釈してウダウダ言ってるからおじさん笑ってた訳。

>問題があるとすれば、どういう使い方しているか把握していないのに
>連絡もせずにビュー定義の内容を変更するとかしちゃう場合だろうね。
一応ER図・定義書には区分け・コメント（修正時の影響範囲）入れてあるから余程のミスアサインが無い限り問題ないと思うよ。

779 ：NAME IS NULL：2008/05/11(日) 14:54:58 ID:???

>>778
すまん、772→771ね。

780 ：NAME IS NULL：2008/05/12(月) 07:17:15 ID:???

>>778
ここで言っている「制限」というのがアクセス規約のことであれば、そこは別に
方向性が全然違うというわけではないんだがな。

おじさんは>>774で、インターフェースをどう使うかちゃんと詰めると書いてるけど、
重要なのはその部分で、単なるインターフェース定義だけを共有するのではなく
どのようにアクセスされるかまで共通認識を持つ必要があるということ。

ここで、おじさんのように全部事細かに確認できればいいんだけど、規模が大きい
場合はさすがに全部は確認しきれないから、「こういうルールでアクセスする分には
問題ないですよ」として、あとはまかせるわけ。

781 ：NAME IS NULL：2008/05/12(月) 22:19:04 ID:???

> 規模が大きい場合はさすがに全部は確認しきれないから、
> 「こういうルールでアクセスする分には問題ないですよ」
> として、あとはまかせるわけ。

経験ないこと丸わかりのレス乙。(w

782 ：NAME IS NULL：2008/05/12(月) 23:42:08 ID:???

なんかアレだな。
持論以外は「経験ないこと丸わかりのレス乙。(w」とかいって
都合の悪い事はスルーしまくってる当人が言うのもかなり滑稽なんだが。

>>781のツッコミなんか>>774のいう事を全否定だし。

って書くとツマラネェ煽りが返ってくるんだろうなぁ。

783 ：NAME IS NULL：2008/05/12(月) 23:42:18 ID:???

>>781
この手のレスはやたらあるけど、じゃあ具体的にはどうしてるのか、というのはほとんどないのな。
俺も経験ないから、そういう情報を知りたくてこのスレウォッチしてるんだけど……。

784 ：NAME IS NULL：2008/05/13(火) 01:26:58 ID:???

>>780
>方向性が全然違うというわけではないんだがな。
下読んだらわかったけど、それにしてもマイナス方向並べすぎｗ

>ここで、おじさんのように全部事細かに確認できればいいんだけど、規模が大きい
>場合はさすがに全部は確認しきれないから、「こういうルールでアクセスする分には
>問題ないですよ」として、あとはまかせるわけ。
同じ経験あるけどさ、Project全体としての進行手法として違う気がする訳よ。
上流でその必要性を顧客説明して言ってる？ちゃんと説明すれば食いつくと思うけどねぇ。
774はそのコストが出たから出来たのは言うとおり。

必要性・プラマイ説明して数字並べても出し渋る顧客なら・・・ルール付けだけになっても仕方ない。
なんら拘束力無いルールだし、俺は人信用しないから逃げ道確保に力を注ぐねｗ

しかし、自分で言うのはいいが、人にオジサンと言われると少し凹むな・・・

785 ：NAME IS NULL：2008/05/13(火) 01:28:34 ID:???

句読点の後ろにwつけてんのは
無視していいよ、鬱陶しい事になるから。

786 ：NAME IS NULL：2008/05/13(火) 23:47:25 ID:???

>>
> >>781のツッコミなんか>>774のいう事を全否定だし。

煽りがどうのこうの言う以前に、どう理解したら全否定に思えるのか不思議でならない。

>>783
> じゃあ具体的にはどうしてるのか

地道にやるしかないよ。

大規模だからと言って妙手があるわけじゃないし、仮にあったとしてもよほど実績がな
いと怖くて使えないから、結局きちんと仕様書書いてよってたかってレビューして、問
題点を管理してと言うのをひたすらやっていくしかない。

結局はそこの設計をどこまできちんとできるかで勝負が決まるのはわかっているけど、
わかっていてもなかなか辛い作業ではある。

しかし、だからと言って、>>780 みたいに「あとはまかせる」なんてやったら、そこら
じゅうで思い違いが発生して収拾つかなくなる。小規模ならどうにでもなるけど、大規
模でそんなことやったらデスマどころかプロジェクトが崩壊する。

>>780 に少しでも大規模ＤＢの経験があったらあんなことはやらないし、周りがやらせ
ないよ。

787 ：NAME IS NULL：2008/05/21(水) 02:46:49 ID:a5f8YH2n

カラムの命名の話なんですが、うちのシステムではテーブルごとに決めた
接頭辞を全カラムにつけています。
userテーブルならusr_id, usr_name, usr_email。classテーブルならcls_id...みたいに。
これならどんなテーブルを結合してもカラム名が重複しなくて
けっこういいアイデアだと思うのですが、よそでやっているのを見たことはありません。
この方式ってどうでしょうか？

788 ：NAME IS NULL：2008/05/21(水) 03:08:14 ID:???

>>787
メリットって大した事ないんじゃないでしょうか。
外部キーで結合時にUSINGを使えるくらい？
その他はuser.nameがusr_nameになる程度でしょ。

789 ：NAME IS NULL：2008/05/21(水) 12:06:09 ID:???

よく見る規約だけど廃れ傾向だと思う

790 ：787：2008/05/21(水) 14:25:43 ID:???

>>788
テーブル名が長いと大変じゃないですか。
長ければエイリアスを使えばいいと言っても、SQLによってエイリアス
の命名法が違うと混乱の元になってしまいますし。

Ruby on Railsなどのフレームワークが広まるとこの規約は
完全に廃れてしまうでしょうね。

791 ：NAME IS NULL：2008/05/21(水) 14:45:24 ID:???

>>790
>SQLによってエイリアスの命名法が違うと混乱の元になってしまいますし。
そんな程度では混乱しないっしょ？

792 ：NAME IS NULL：2008/05/21(水) 21:13:47 ID:???

昔はそういう命名よくやったけど最近はないね。
もっさりした、いかにも昔のやり方って感じ

793 ：NAME IS NULL：2008/05/21(水) 23:03:00 ID:???

今も昔も、そんなのは一般的ではないよ。

794 ：NAME IS NULL：2008/05/21(水) 23:14:46 ID:???

結合したとき、名前が衝突するカラムに対してエイリアスを設定するという作業が不要なので、俺も悪くないと思うんだが、あんまり見ないねぇ。
論理的、具体的にどこがマズいという意見も挙がってないし。

ORマッパ全盛の時代なので、余計なプリフィックスが付いてると美しくない、というのは個人的にあるんだけど。
あとは、似て非なるテーブルで、同じ意味のカラムに違う名前が付くのもNGな点かねぇ。

795 ：NAME IS NULL：2008/05/22(木) 00:21:54 ID:???

ORマッパが流行ってんのってJavaの世界だけ？

796 ：NAME IS NULL：2008/05/22(木) 00:52:20 ID:???

主系と待機系の2重構成にシステムを組む時は、主系が壊れた時にどのようにして待機系を主系にするのが普通でしょうか？

797 ：NAME IS NULL：2008/05/22(木) 01:12:12 ID:???

一般的な話が知りたいんなら、MS とかのサイトでクラスタサーバの
概要とか見ればいいんじゃね。

# スパッと壊れればいいけど、中途半端に壊れて両系起動してパニクルとか、
# 主系を修理後に副系から処理を戻すかどうかとかでトラぶりやすいから注
# 意した方がいい。

798 ：NAME IS NULL：2008/05/22(木) 01:21:05 ID:???

そういうテストはしていないよね
メーカーや販社は値段が高いからクラスタサーバを入れるけど

799 ：NAME IS NULL：2008/05/22(木) 01:24:03 ID:???

797さんは同期はどのように取ることが多いですか？

800 ：NAME IS NULL：2008/05/22(木) 02:37:16 ID:???

>>793
集約テーブルの場合どうすんの？
id(primary) id id　になっちゃうんじゃね？

801 ：NAME IS NULL：2008/05/22(木) 02:40:32 ID:???

>>800
何を言っているのやら

802 ：NAME IS NULL：2008/05/22(木) 07:04:37 ID:???

>>795
.NETでもあるけど周りでは使ってる人見ないね。
C（非DBアクセス）, VBer→.NETだとORどころかDaoすら知らない人が多い。

>>799
4大は全部レプリケーションサポートしてるでしょ。って誤解釈してる？

803 ：NAME IS NULL：2008/05/22(木) 08:55:30 ID:???

外部キーは相手のテーブル名入れるだろ

804 ：NAME IS NULL：2008/05/22(木) 11:32:36 ID:???

>>801
テーブル名の接頭辞をつけないなら
リレーション張るためのテーブルならidだらけになってしまうんでないかということ

805 ：NAME IS NULL：2008/05/22(木) 12:47:46 ID:???

そのテーブル自身のidをあらわしてないなら、
そのカラムはidって名前にならないだろ

806 ：NAME IS NULL：2008/05/22(木) 13:00:48 ID:???

>>804
>>787
＞userテーブルならusr_id, usr_name, usr_email。classテーブルならcls_id...みたいに。

まあ、好みの問題のような気もするが、接頭辞を付けない方が良いような。

付けない場合は、通常、user.id と表現するが、 u.id や usr.id と表現させる事も
簡単に出来る。
なんで、別にテーブル名が長くてもさして困る事は無いので、出来るだけテーブル名は
分かりやすい方が良い。

類似するテーブル名がたくさんあった場合、カラムに接頭辞がついている方が面倒。
また、カラムをユニークにするのは規模が大きくなればなるほど管理が大変。
中途半端に同じカラムがあったりするとイライラ増大する上に、
付いている接頭辞によって逆に惑う場合が発生してしまう。

そしてあんまり考えたくないが、テーブル名が変更された場合はかなり絶望的。

という事で、テーブルは、出来るだけそのテーブルだけで完結している方が良いと思う。
接頭辞をつけるという事は、そこに他のテーブルの意思が紛れ込んでいる。

まあ、それでもカラムに接頭辞を付けた方が見やすいと言うのであれば、
カラム名だけを変えたViewを作ればよいんじゃないかな？

って思うけど、どうだろ。

807 ：NAME IS NULL：2008/05/22(木) 14:24:57 ID:???

正規化の過程でテーブル分けた場合、違う名前だとややこしくなる、気がする。

808 ：NAME IS NULL：2008/05/22(木) 15:17:10 ID:???

>>804
そんなバカなことを言ってるとは思わなかった。すまん。
外部キーはXXXX_idとかにするよ、もちろん。

809 ：NAME IS NULL：2008/05/22(木) 16:59:27 ID:???

大体そうじゃなきゃCreateTableできないし。

810 ：NAME IS NULL：2008/05/22(木) 20:54:36 ID:???

>>802
VBやっててDAO知らないなんてことはないだろう

811 ：NAME IS NULL：2008/05/22(木) 21:27:59 ID:???

>>802
ですな。
同意。

812 ：NAME IS NULL：2008/05/22(木) 21:49:17 ID:???

DAO違いな気がする。おそらくADOの親戚のことではない。

813 ：NAME IS NULL：2008/05/22(木) 22:01:15 ID:???

>>808
お前がバカな勘違いしてたんだよバカ

814 ：NAME IS NULL：2008/05/22(木) 23:02:26 ID:???

>>813
そうだな。バカだった。

>リレーション張るためのテーブルならidだらけになってしまうんでないかということ
こんなこというバカなんて存在しないハズだと、身勝手な前提を設けてしまっていた。
反省。

815 ：NAME IS NULL：2008/05/23(金) 00:43:17 ID:???

俺はテーブル名を素にしたプリフィックス付けたカラム名にしてるよ。
ＤＢデザイナーみたいなソフトに読ませたときに、カラム名からある程度のリレーションを引いてくれるから。
確かに重複とか、ネーミングとか悩むけどな。

まぁ、ドキュメント類を都度、ちゃんとメンテしてないから↑みたいなことやる羽目になるわけだがｗ

816 ：NAME IS NULL：2008/05/23(金) 08:46:23 ID:???

>>814
いい加減ちゃんと反省しろボケ

817 ：NAME IS NULL：2008/05/23(金) 11:56:51 ID:???

>>800
なにを？

818 ：NAME IS NULL：2008/05/23(金) 12:09:22 ID:???

>>815
同じカラム名じゃないと自動的にはリレーション貼ってくれないんじゃないか？

何によって、相互のカラムが関係あるとしているんだろうか。

819 ：NAME IS NULL：2008/05/24(土) 00:23:01 ID:???

各々のフィールドが絡むかどうかで...

820 ：NAME IS NULL：2008/05/24(土) 16:45:14 ID:???

>>819
行をタップリと

821 ：NAME IS NULL：2008/05/24(土) 22:01:01 ID:???

カラム名にテーブル名のプレフィックスをつけるのって

東京都千代田区永田町という地名を
東京都東京＿千代田区東京＿千代田＿永田町
にするようなものだろう。

822 ：NAME IS NULL：2008/05/24(土) 23:24:07 ID:???

別にテーブル名を付けている訳ではないだろ。

823 ：815：2008/05/25(日) 02:56:42 ID:???

>>818
あ、ゴメン。ちょっと説明が足らんかった。

user_master
┌─┬──┬────┐
│id│name│yomigana│
└─┴──┴────┘

occupation_master
┌─┬──┐
│id│name│
└─┴──┘

user_occupation_index
┌─┬────┬───────┐
│id│user_id │occpuation_id │
└─┴────┴───────┘

↑こういうんじゃなくて↓こういう風にしてるよ

user_master
┌────┬──┬────┐
│user_id │name│yomigana│
└────┴──┴────┘

occupation_master
┌───────┬──┐
│occupation_id │name│
└───────┴──┘

user_occupation_index
┌─────────┬────┬───────┐
│user_occupation_id│user_id │occupation_id │
└─────────┴────┴───────┘

↑ってことを言いたかったのね。

824 ：NAME IS NULL：2008/05/25(日) 03:03:29 ID:???

好きにすればいいから・・・他所でやってくれ。

825 ：NAME IS NULL：2008/05/25(日) 15:21:56 ID:zyDCfy4f

DBを使ったシステムを構築するに当たり、実際のシステムでは、
1.入力時にデータをチェックして、DBにはまともなデータしか入れないようにする
2.DBに入れるデータは何でも許可して、データを使う時にプログラムでチェックする
のどっちが一般的ですか？
私としては1の方策をとり、データの入力ミスが発覚した場合は入力プログラムに
フィードバックすべきと思うのですが。

826 ：NAME IS NULL：2008/05/25(日) 15:47:01 ID:???

少なくともNOT NULL制約と外部キー制約はつけるが
それ以上のことはやらないな

827 ：NAME IS NULL：2008/05/25(日) 15:58:33 ID:???

参照制約も使わん。

828 ：NAME IS NULL：2008/05/26(月) 20:58:05 ID:???

>>825
一般に、データチェックは入り口で行うのがセオリー
データチェックがあとになればなるほど、リカバリーが困難になる。

829 ：NAME IS NULL：2008/05/28(水) 22:38:35 ID:???

アプリでチェックしてるつもりでもチェック漏れ等は有りうるからなー。
「氏名必須なのに気づいたら氏名NULLのデータが大量にあった。発覚したのが3ヵ月後だから
NULLになっている氏名の欄に何が入るはずだったか、もはやわからない」とかよりは
例えDBエラーでも最初の1件目で発覚してくれたほうが安全。

アプリチェックは当然必須だけど
DB側でも最低限の制約は付けておくべきだと思う。

830 ：NAME IS NULL：2008/05/28(水) 23:21:32 ID:???

それこそ、NOT NULLくらいだろ。
キー以外のUNIQUEも場合によっては使うかも知れんけど。
参照とかチェックはまず使わんな。

831 ：NAME IS NULL：2008/05/30(金) 16:05:51 ID:???

性別とか年号とかあんまり増えなさそうなテーブルって作っておいた方がいいですか？
項目名のためだけにJOINしないといけなくなるけど

832 ：NAME IS NULL：2008/05/30(金) 16:26:14 ID:???

>>831
作ってもいいが、
JOINしないことを前提としたパラメータテープル扱いがいいと思う。
プログラム起動時に最初に読み込んでマップに取り込んでおく。
悩ましいのは帳票系のツールにダイナセット直結のものが多くて
JOINしないわけにいかないのがあるのがつらい。

>>830
参照整合性で悩むのは外部キー（参照先でないほう）に索引をつけるか
どうかなんだよな。１：ｎでｎの数が多い場合は特に悩む。

833 ：NAME IS NULL：2008/05/31(土) 14:55:42 ID:6ka7bWrL

主キーとなるべきカラムにPrimarykeyでなく
インデックスの設定で済ませる意味は確かにわからん。

インデックスって、厳密にはどんな制約かかります？

検索時に使用されるだけで、そのカラムに入る値については何の制約も与えないという
のが個人的想像なのだけど、それはDBの種類によって変わってきますか？

834 ：NAME IS NULL：2008/05/31(土) 16:54:44 ID:???

設計上の概念が制約、それを実現する手段（実装）として索引がある。
主キー制約は非NULLのユニーク索引で実現される。

もうひとつ歴史的な背景としてANSI-SQLでPrimary Keyキーワードが
DDLとして規格化されたのはかなりあと（ANSI-89くらい？）で
古い時代のRDBでは主キー制約をあらわすために非NULLのユニーク索引を直接使っていた。

＞検索時に使用されるだけで、そのカラムに入る値については何の制約も与えないという
NULLありの非ユニーク索引ならそうなるかな。

835 ：NAME IS NULL：2008/05/31(土) 17:21:44 ID:QpkHEgUM

主キーは何でも ID にして不正なデータを一杯突っ込んでいた馬鹿パッケージがあって困ってたんですが、このスレを見て分かりました。
駄目なことが流行ってて困りますし、そんな馬鹿にテーブル設計して欲しくないですねぇ。
必要があってID使いたいときは、主キーは自然キーで、別途ユニークキーでIDを宣言すればよいと思います。
何でもID派の人は論理的なユニーク制約の代わりを人間が実施しないといけなくなるんですが、そんな設計する奴がきちんとできるとは思えん。

836 ：NAME IS NULL：2008/05/31(土) 17:30:48 ID:???

>>835

837 ：NAME IS NULL：2008/05/31(土) 17:45:26 ID:???

また例のヤツか

838 ：NAME IS NULL：2008/05/31(土) 18:58:21 ID:???

同じ話題しか出せない=思考停止=理解力が無いだけ　とも考えられるねｗ
単に粘着質なんだろうけど

839 ：NAME IS NULL：2008/05/31(土) 19:05:10 ID:QpkHEgUM

いいえ、違いますよ。

啓蒙ですよ。

840 ：NAME IS NULL：2008/05/31(土) 20:35:42 ID:???

DBMSに主キー発番させたいからID使います

841 ：NAME IS NULL：2008/05/31(土) 20:37:20 ID:???

このテーマは終結したんじゃなかったっけ？

842 ：NAME IS NULL：2008/05/31(土) 20:51:48 ID:???

暴れてるのは最初に質問した人とは別なのか。
かまってちゃんなんだろ。

843 ：NAME IS NULL：2008/05/31(土) 21:49:30 ID:???

>>839みたいな頑なDB屋さんがいると結構やっかいだよねぇ・・・アプリ側の勉強ももっとして欲しいもんだ

844 ：NAME IS NULL：2008/05/31(土) 21:59:42 ID:???

質問に解凍するレスより粘着を煽るレスが多い件

845 ：NAME IS NULL：2008/06/01(日) 01:18:03 ID:???

>>835
それって主キーをIDにして、別途自然キーにユニーク制約つけとけばいいんじゃないの？

846 ：NAME IS NULL：2008/06/01(日) 18:33:29 ID:???

CASE文にサブクエリ書くのは汚いSQLになる

847 ：NAME IS NULL：2008/06/01(日) 22:18:01 ID:???

CASEによる

848 ：NAME IS NULL：2008/06/02(月) 14:54:08 ID:???

case by case と言って欲しかった

849 ：NAME IS NULL：2008/06/02(月) 20:51:43 ID:???

だれがうまいことを

850 ：NAME IS NULL：2008/06/26(木) 23:19:26 ID:9Bdxxe1P

質問です。通常は多対一（一対多）なんだけれども、例外的に多対多になる場合は
どの様に対応されているのでしょうか？
例えば社員と部署を考えてみると、一般的にその関係は多対一ですが、現実には
複数の店舗を掛け持ちしたりとかで多対多になるケースもあるとかです。
きっちりやるなら関連テーブルを作って対応ってことなんでしょうけど、
実際には多対一で設計して運用で対応してるのが多いんじゃないのかな？って疑問です。
どうなんでしょう？

851 ：NAME IS NULL：2008/06/26(木) 23:46:24 ID:???

それを言うなら、「多対多で設計して運用(あるいはアプリ側)で対応」じゃないの？

852 ：NAME IS NULL：2008/06/27(金) 00:04:55 ID:???

>>851
レアケースで多対多になる場合は、関連テーブルを作っているのでしょうか？
というのが主旨の質問です。この例ですと、多対一の設計にして、社員を重複登録等にして
関連テーブルを作成しない対応をするのが多いのでは？というものです。

853 ：NAME IS NULL：2008/06/27(金) 00:06:24 ID:???

>>850
兼任してるのがすごい稀なら、ダミーの社員作って対応してる例はあったよ。

ダミーの社員には元の社員の社員番号 + 追い番付けといて、

select * from 社員テーブル where 社員番号 like 'xxxxx%'

みたいにして全ての所属部署を取得するとかしてた。

854 ：NAME IS NULL：2008/06/27(金) 00:28:40 ID:???

>>853
レスありがとうございます。
すいませんが取り込んでしまいましたのでレスは後ほどいたします。

855 ：NAME IS NULL：2008/06/30(月) 07:02:58 ID:???

「例外」をノーマルとして扱うものを最初から設計するのがシステム作りの基本。
このケースでは「多対多」でつくる。
そのほうがシンプルな構造になるし、あとあとの管理も楽。

部署コード＋社員コードからなる担当テーブルを作るってことになるのかな？

ただし、「例外」を実装するのにコストがかかるケースでは別途考える。

856 ：NAME IS NULL：2008/06/30(月) 22:15:57 ID:???

>>855
> 「例外」をノーマルとして扱うものを最初から設計するのがシステム作りの基本。

費用対効果とかトレードオフって知ってる？

857 ：NAME IS NULL：2008/06/30(月) 22:21:10 ID:???

N:1だろうとN:Nだろうとなんでもかんでも
関連テーブル作っておけばいいよ。

858 ：NAME IS NULL：2008/06/30(月) 22:45:04 ID:???

>>856
基本N:1の設計に例外でN:Mサポートを作りこむのと、最初からN:Mの設計に
通常N:1とする制約を作りこむのとでどっちがコストが低いのかという話だろ。
で、費用対効果というものを知っているとどっちの結論になるの？

859 ：NAME IS NULL：2008/06/30(月) 22:58:06 ID:???

>>858
いや、つっこまれてるのはその話じゃなくて、最初の1行目でしょ。
この場合、関連テーブル作っておくなんて「例外」でもなんでもない。
「エンティティ」って言葉の通りだよ。

860 ：NAME IS NULL：2008/06/30(月) 23:01:54 ID:???

>>858
> で、費用対効果というものを知っていると

状況も考慮せずに、「どっちの結論になるの？」なんてバカなことを言わなくなる。

861 ：NAME IS NULL：2008/06/30(月) 23:08:00 ID:???

>>856
その下に、
> ただし、「例外」を実装するのにコストがかかるケースでは別途考える。
って書いてあるのが目に入ってないのは何故だ。

862 ：NAME IS NULL：2008/06/30(月) 23:45:27 ID:???

そんなものは別途考えるんじゃなくて、最初に考えることだから。

863 ：NAME IS NULL：2008/07/01(火) 01:00:21 ID:???

一部のデータだけが多対多、なんてのを例外扱いするのがまず違和感。

その上、例外をノーマル扱いするのが基本、って言い方すれば
コスト意識ねーなーってつっこまれるのもしかたない。

まあ気持ちは一緒なんだと思いますよ。言葉のあやみたいなもんかと。

864 ：NAME IS NULL：2008/07/01(火) 01:14:39 ID:???

はい、言葉のあやです。
スキップ！スキップ！

865 ：NAME IS NULL：2008/07/01(火) 03:00:36 ID:???

「例外的に」としてしまうのは素人
客が「レアケースだから」と無意識に無いことにしてしまっているのを引き出す仕事なのだから、この意識は重要だと思う

866 ：NAME IS NULL：2008/07/05(土) 22:01:44 ID:???

相手を信じることによって信頼関係って成り立ってると思うんだ。
俺は客が言うことを信じるぜ！

867 ：NAME IS NULL：2008/07/06(日) 03:14:11 ID:???

多対多の時は関連テーブル作るのは分かるけど
多対一の時に関連テーブル作らないとしたらどうやって表現するんだ？

868 ：NAME IS NULL：2008/07/06(日) 03:50:58 ID:???

>>867
普通に外部キー

869 ：NAME IS NULL：2008/07/09(水) 10:39:43 ID:???

テーブルの中に1個だけサイズが大きなカラム(MySQLのtext型とか）
がある場合、それだけ分離したテーブルにすることってよくありますか？

870 ：NAME IS NULL：2008/07/09(水) 17:15:34 ID:???

そのカラムのせいで固定長が崩れるなら分離する

871 ：NAME IS NULL：2008/07/09(水) 20:21:35 ID:???

分離する意味がないからしない

872 ：NAME IS NULL：2008/07/09(水) 23:53:50 ID:???

データを分析して全体の数%にしか巨大なテキストがあるとか言うなら
分離するとかするかもしれんが、常に一定量のテキストがあるなら、
分離する意味が解らん。

873 ：NAME IS NULL：2008/07/10(木) 00:20:31 ID:???

この資料の「TEXTフィールド分割」という場合はどうでしょうか?
http://www.php.gr.jp/seminar/20070901/data/phpcon-2007-dist.pdf

874 ：NAME IS NULL：2008/07/10(木) 06:44:06 ID:???

RDBのTEXT型がVARCHARかCHARかで多少話しが変わってくるかもしれんが、
その会社でMySQLで鯖の容量とレスポンスとjoinのコストを総合的に判断して
分けた方がいいと判断したから分けたんじゃね？

「テキスト型は分離する」なんてマニュアルはないぞ。

875 ：NAME IS NULL：2008/07/10(木) 06:50:52 ID:???

>>873
パフォーマンスチューニングっていうのは「HDDのシークをどれだけ減らすか」
ということだから、TEXTフィールド分割は一つの手段だけども、基本は

「計測しろ」

だ。

876 ：NAME IS NULL：2008/07/11(金) 23:01:18 ID:???

計測しないとわからないなんて設計者としてどうなの？

877 ：NAME IS NULL：2008/07/11(金) 23:14:15 ID:???

DBに関しては予断が一番危ない。
DBMSとバージョンと諸条件まで合わせないと違う結果になることが多い。
事前と事後の測定なしでちょろっとチューニングを頼まれるのは辛いし危険、基本的に断ってる。

878 ：NAME IS NULL：2008/07/11(金) 23:20:50 ID:???

>>873
ここでいうTEXTフィールドはCHAR型、VARCHAR型の文字フィールドでなく
最大2^16文字格納できるtext型のフィールドなんだろう。

index検索しかしないのであれば、別テーブルに分ける必要はないが、
データをスキャンするような検索がある場合は、別テーブルにしたほうが無難。

879 ：NAME IS NULL：2008/07/11(金) 23:58:07 ID:???

TEXT型というのが文字タイプのラージオブジェクト（CLOB）の場合は、
レコードにはポインタだけで本体は専用の別領域に格納するものが多い。
例えばMSSQLは2000まではこれであったが、
2005からはオプションでデータがブロックに納まる規模ならレコード本体にしまうようになった。

880 ：NAME IS NULL：2008/07/12(土) 02:08:57 ID:???

>>876
大量データのシーケンシャルサーチとインデックスサーチみたいに、どう考えてもこっちの方が速いだろう、というケースでない限り、事前の予測はあてにならない。
逆に、その予断のせいで酷い設計になるケースも少なからずある。

881 ：NAME IS NULL：2008/07/12(土) 02:42:51 ID:???

>>876
正しいと思う

882 ：NAME IS NULL：2008/07/12(土) 02:51:56 ID:???

ある程度の予測ができないと設計はできない

883 ：NAME IS NULL：2008/07/12(土) 03:02:52 ID:???

>>882
予測はするが、計測をするのが基本だ

884 ：NAME IS NULL：2008/07/12(土) 09:04:58 ID:???

実際に設計する時に要件の規模を聞いて、ダミーでもいいので
重いデータとか作って計測するけどな。

ショボイ案件と言うと語弊があるが、データの量が少なくて
事前の予測がハズしても体感的に大差ないと言い切れる
ケースだと計測しない場合はあると思うけど。

885 ：NAME IS NULL：2008/07/12(土) 10:51:34 ID:???

運用中の改修で計測できない場合はどうすんの？

886 ：NAME IS NULL：2008/07/12(土) 11:01:32 ID:???

運用中の改修って本番稼働中のシステムに対してテストとかせずに
本番環境を直接変更、本番一発稼動の事を言っているのか？

仮に障害対応とかマッハな緊急対策な話は別として、
そんな対応に設計も予想もクソもないと思うが。

887 ：NAME IS NULL：2008/07/12(土) 12:07:26 ID:???

>>885
要緊急対応→お願いっ！
通常対応→模擬本番環境用意して計測。

888 ：NAME IS NULL：2008/07/12(土) 12:29:34 ID:???

意味あるデータを取れる模擬環境を持っているシステムってどのくらいの
割合なのかな？
二重化されているシステムならスタンバイ側を利用できるかもしれんが。

889 ：NAME IS NULL：2008/07/12(土) 12:58:21 ID:???

>>888
きっちり同じのは見たことないな。実運用では、
「テスト系で20分だったからまぁ大丈夫なんじゃね?」
くらいで済ますことが多かった。

890 ：NAME IS NULL：2008/07/13(日) 13:14:48 ID:IMrAjHtQ

mixiのコミュニティの様にユーザが自由に作成可能で、
作成される数が1000-1000000まで想定される掲示板の設計を考えています。

1.1000テーブルを作成する（コミュニティ数分だけテーブルを作る）
2.1つのテーブルで管理をし、インデックスを適切に貼る

管理面は間違いなく2番の方が楽ですが、現実問題として1番の方法が
適切なパターンもあるでしょうか？

891 ：NAME IS NULL：2008/07/13(日) 13:37:49 ID:???

コボルで開発する場合とか？

892 ：NAME IS NULL：2008/07/13(日) 16:43:05 ID:???

>>890
普通の RDBMS 使えるなら環境ならまずないと思う。

１テーブルあたりのデータ量の上限がやけに低い変態 DBMS とか、
プロジェクトの方針や要件定義で複数のコミュニティのデータを
１つのテーブルに入れるのはまかりならんとかなってるのならそ
の限りではないけど。

893 ：NAME IS NULL：2008/07/13(日) 17:00:42 ID:???

mixiのように巨大なものになってくると、一般的な話とは違ってくるだろうね。

894 ：NAME IS NULL：2008/07/13(日) 19:04:13 ID:???

テーブル分割の話が出てくるんだろね。
水平分割、垂直分割・・・('A`)

895 ：NAME IS NULL：2008/07/13(日) 20:21:37 ID:???

mixiはOSがfedoraでRDBはMySQLだから、ちょっと工夫してパーティション切ってるとｵﾓ。

楽したかったらDB2/400やOracleみたいにOSが半自動的にクラスタや
パーティショニングしてくれるRDBMS使うとか。

896 ：NAME IS NULL：2008/07/14(月) 00:00:10 ID:FB0wjp69

>>892-895
大変参考になりました。ありがとうございます。
1番の方向で設計して、後は保守や拡張で対応をしたいと思います。

897 ：NAME IS NULL：2008/07/14(月) 00:47:46 ID:???

後は営業の口先で対応すればいいと思います。

898 ：NAME IS NULL：2008/07/14(月) 02:52:07 ID:???

記事やコメント相互の関連性がほとんどなしでいいなら集中して管理する意味はほとんどない。
ぶっちゃけ２ｃｈ方式ならDBさえいらない。
スレに対してコメントを追記すればいいし上限１０００コメントなら検索は先頭からのサーチで十分。

それでも１サーバで管理できる範囲なら１テーブルにぶち込んだほうが楽。
２サーバ以上分散させるなら、それぞれ独立した板に分けてしまったほうが楽だし負荷分散もしやすい。

あとはnewsgroupのようなやりかたもあり。
データの同期が遅れることはあるが記事相互の関連は取れるうえ負荷分散に対応できる。

899 ：NAME IS NULL：2008/07/15(火) 23:23:05 ID:???

テーブル名について質問です。

以下のような３つのテーブルを作っています。

□会社テーブル
・会社コード
・会社名

□所属テーブル
・所属コード
・所属名

□会社and所属テーブル
・会社所属コード（代替キー）
・会社コード
・所属コード

□社員テーブル
・社員コード
・社員名
・会社所属コード

ここで気になっているのが、"会社and所属テーブル"というテーブルの名前なのですが、
いい名前がどうしても思いつかないのですが、どのようなテーブルの名前にするのが適切でしょうか？

900 ：NAME IS NULL：2008/07/15(火) 23:34:55 ID:???

とりあえず日本語はやめような？

901 ：NAME IS NULL：2008/07/15(火) 23:52:01 ID:???

>>899
仕事だったら上司かお客に聞けばいいし、
学校の宿題なら好きに汁。

おそらく宿題だとは思うが。

902 ：NAME IS NULL：2008/07/16(水) 10:14:20 ID:???

いまどき、英語にこだわる事も無いんじゃないか。

と言うか、使えないくせに無理やり分け分からん単語を使われるぐらいなら、
日本語に統一してある方がよっぽど良いが。

俺は英語が出来ないから、日本語をじゃんじゃん使う。
最近ではコードの関数名・変数名からして日本語だし。

いや、便利になったものだよ。

>>899
その法則であれば、自分なら会社詳細テーブルか所属詳細テーブルかな？
どういう意図でそのテーブルが必要なのかを明確にすれば名前は自ずと決まるけど。

903 ：NAME IS NULL：2008/07/16(水) 13:33:29 ID:???

日本語はサ変と複数形が困る

904 ：NAME IS NULL：2008/07/16(水) 14:55:08 ID:???

フィールド名は日本語にするか、英語にするか
http://pc11.2ch.net/test/read.cgi/db/1150352890/l50

905 ：NAME IS NULL：2008/07/16(水) 19:40:11 ID:???

>>899
所属名というのは部署名のことですか、そうだとしたら

□会社テーブル
・会社コード
・会社名

□部署テーブル
・会社コード
・部署コード
・部署名

□社員テーブル
・社員コード
・社員名
・会社コード
・部署コード

で、いいんでないかい？

906 ：NAME IS NULL：2008/07/16(水) 22:26:53 ID:???

普通に「会社所属テーブル」って名前で良さそうだが。
所属ってのは「正社員」とか「派遣」とかの区分のことかな？

907 ：NAME IS NULL：2008/07/17(木) 00:00:22 ID:va5rM8gD

ADO.NETの自動コード生成だと日本語があると変なコードになるから
使わないようにしてる。

908 ：NAME IS NULL：2008/07/17(木) 06:04:32 ID:uqRdek/R

>>905
会社と部署との関連がなくなるだろｗ
テーブル設計自体は、>>899で問題ないと思う。

で、名前は>>902のいっているとおり、どういう意図でそのテーブルが必要なのかを明確にすれば名前は決まるわけだ。
会社and所属テーブルが何のために必要かというと、会社と所属の関連ということになるわな。
だから、名前は、会社別所属一覧テーブルでおｋ。

>>900
おっさんはあっちいけｗ
最近は普通に日本語使うんだよ。（英語使うことのほうが多いけど）

909 ：NAME IS NULL：2008/07/17(木) 08:14:31 ID:???

フリー（偽装派遣）なんでいろんな現場を転々としてるが
日本語使ってるのは1回しか見たこと無いな。
20万行ぐらいあるストアドパッケージとか、いろんな意味で滅茶苦茶なプロジェクトだった。

910 ：NAME IS NULL：2008/07/17(木) 08:53:08 ID:???

>>909
それは日本語とは無関係のような･･･

それはともかく､日本語のオブジェクト/フィールド名を使っているデータベースでまともなものに出会ったことがないな｡
大手が関係しているプロジェクトはみんな英語だったし｡OBCの内部DB構造も英語｡

>>907
同意｡

911 ：NAME IS NULL：2008/07/17(木) 10:45:47 ID:???

>908
>最近は普通に日本語使うんだよ。（英語使うことのほうが多いけど）

少数派なのに「普通」？
あれか、「普通に美味しい」とかいう「普通」ですか？

俺は日本語、2回見た。両方ともバカな設計だった。
バカ設計と日本語である事と無関係なのは判ってるんだけど
どうにもこうにも、うーん。

912 ：NAME IS NULL：2008/07/17(木) 11:41:38 ID:???

>>911
>>908は桐ユーザー

913 ：NAME IS NULL：2008/07/17(木) 12:35:10 ID:???

マルチバイト文字を使うかどうかなら環境が許すならやってみたいものだ。
以前のプロジェクトで漢字OKというふれこみだったのだが、
漢字の第２バイトに'\'があったらバグが出るという代物だったのでやめた（笑

ところで外国企業や外資系の開発でもない限りローマ字で日本語を使うことは多いのだが、
最近は訓令式が主流なのだろうかヘボン式育ちとしてはちょっとすわりが悪い。

914 ：NAME IS NULL：2008/07/17(木) 12:46:44 ID:???

>>913
訓令式の方がルールがシンプルでいいという気がする。
普段のローマ字使うときはヘボン式なんだけどね。

915 ：NAME IS NULL：2008/07/17(木) 13:05:35 ID:???

こちらは適当でいろいろ混ざってる。特に英単語を使えという指示もない。
ただ外来語は本来のつづりでというルールはあるな。
テレビはTVやtelevisionにしてterebiはよしてくれということらしい。
なるほどterebiはさすがにアホっぽい。

916 ：NAME IS NULL：2008/07/17(木) 13:28:40 ID:???

>>915
外来語は英語の綴りでないと読みにくいね。
あといくつかの一般的な英単語(name, dateなど)もある程度規則をつくってる。

917 ：NAME IS NULL：2008/07/17(木) 13:28:58 ID:???

審判はヘボン式でshimpan

918 ：NAME IS NULL：2008/07/17(木) 16:03:39 ID:???

>>905俺もこうだなー

919 ：NAME IS NULL：2008/07/18(金) 00:35:28 ID:???

DB勉強中の学生から質問。

>905 の、社員テーブルに会社コードいらないと思うんだけど
それじゃまずいの？

920 ：NAME IS NULL：2008/07/18(金) 00:39:50 ID:???

>>919
>>899に「会社and所属テーブル」があるのは何故かっつーと
会社と所属がｎ対ｎだからであろうと考えられる。
とすれば部署から会社を特定することはできない。
よって部署と会社両方を社員テーブルに持たせる必要がある

921 ：NAME IS NULL：2008/07/18(金) 00:57:46 ID:???

大学と学部みたいな通り一遍みたいなのならわかるけどなー
○○大学××学部

たとえば大きな会社って、いろいろ部署ない？
捜査一課とか庶務二課とか。
翻って小さな会社の場合、部署なんて無い方が多いと思うな。

会社によっては、他には無いような課とかあるんじゃないかな？
特車二課とか？

そういうのでもあのテーブルにいれるの？
あと、社員の所属が会社にないとか発生しない？

922 ：NAME IS NULL：2008/07/18(金) 01:06:18 ID:???

捜査一課ｗｗｗ

923 ：922：2008/07/18(金) 01:06:54 ID:???

失礼。悪気はない。

924 ：NAME IS NULL：2008/07/18(金) 01:14:57 ID:???

>>921はもてると思った。

925 ：NAME IS NULL：2008/07/18(金) 01:19:10 ID:???

>>921
こまかい仕様は>>899にしかわからない。
所属が部署を意味するかどうかさえわからん。

ただし、他には無いような課だからテーブルに入れないなんて理屈は無いし
社員の所属が会社にないとかもありえない（無いものを使うな、または無いなら作れという話でしかない）

926 ：NAME IS NULL：2008/07/18(金) 01:23:58 ID:???

そもそも>>899の「所属」って、なんのことなのかね？
複数の会社にまたがる可能性のあるグループで、
すべての社員は必ずそのどれか一つに属している？

プロジェクトみたいなものなら複数の会社でってことも
考えられるけど、複数のプロジェクトに参加する社員も
普通にいるからなぁ。

>>908 >>920は理解できているみたいだが。

927 ：NAME IS NULL：2008/07/18(金) 01:28:28 ID:???

最近の流行はシステムに合わせて会社のルールを変えさせることだよ

928 ：NAME IS NULL：2008/07/18(金) 01:38:17 ID:???

所属＝国とかだと、まあ意味は通るでしょ。

929 ：NAME IS NULL：2008/07/19(土) 04:17:33 ID:cVCG1agQ

>>926
＞そもそも>>899の「所属」って、なんのことなのかね？
会社の中の所属でいいと思うよ。
所属が会社を横断するようなものであれば、会社and所属テーブルというものが存在してはいけない。

930 ：NAME IS NULL：2008/07/19(土) 14:02:59 ID:???

してはいけない。？

931 ：NAME IS NULL：2008/07/19(土) 14:37:39 ID:???

>>929
kwsk

932 ：NAME IS NULL：2008/07/21(月) 23:12:19 ID:???

>>919
子会社を持つグループ企業などの社内システムには必要。
（よくあると思うけど）
どこの会社に所属している社員かわからなくなるから。

933 ：NAME IS NULL：2008/07/22(火) 21:21:19 ID:???

簡単な社内システムを作る事になり、
DB設計の担当として、現在論理DB設計を行なっております。

上司の方からアドバイスを頂いた際に、
「トランザクションテーブルから、マスタテーブルへの関係を引く場合は、
　トランザクションが親。マスタのIDに外部キーを設定するように」
と言った内容のご指導を頂きました。

トランザクションへ外部キーを設定する物とばかり思っていまして、
先に記述した上司様からの話は聞いた事がなく、
google等を利用して調べても、参考になる物がほとんど見つかりません。
どなたかマスタを外部キーにする事の理由や、意味、
参考になるサイトのURL等をご教授願えませんでしょうか。

934 ：NAME IS NULL：2008/07/22(火) 21:27:50 ID:???

>>933
ttp://www.23ch.info/test/read.cgi/prog/1190530598/

935 ：NAME IS NULL：2008/07/22(火) 21:50:32 ID:???

一概に言えんのだがトランザクションテーブルやらマスタテーブルって
単語が出てくる時点で、ダメダメな悪寒。

936 ：NAME IS NULL：2008/07/22(火) 21:53:19 ID:???

>>934
そんな止めを刺さないでください・・・。
今年入社したばっかで、何かの間違いor知らない考え方が存在すると思い、
質問をしてみたのですが、諦めたほうが良いのでしょうか。

>>935
そうなのですか？
正確にはマスタ、トランと呼称しておりましたが、
そういう問題とはまた違う問題ですか？

937 ：NAME IS NULL：2008/07/22(火) 22:07:05 ID:???

少なくとも、一般論ではないらしいと確認が取れたんだから、あとは上司に聞け。
大技林にも載ってない物凄い裏技があんのかも知れないだろ。

報・連・相って学校で習わなかったのぉ？ゆとりちゃん。

938 ：NAME IS NULL：2008/07/22(火) 22:13:48 ID:???

>>937
了解しました。

本日、上司の方に確認を取りに行こうとしたのですが、
ちょっと忙しい、との事でお話が出来なかったのです。
もし知らぬ何かがあるのなら、予習しようかと思いまして。

確かに一般的ではないようですし、
もうドキュメントを探す作業も疲れましたので、
2行目を希望にして、明日を迎えたいと思います。
本日はどうもありがとうございました。

明日、＼(＾o＾)／ｵﾜﾀという報告・・・というか愚痴を吐きに、
またここを訪れるかもしれませんが、その際は慰めて貰えると嬉しいです。

それでは失礼致します。

939 ：NAME IS NULL：2008/07/22(火) 22:33:43 ID:???

別に珍しい話でもないと思うけど。
例えばネット通販だと、まず販売実績ありきで
売上テーブルにない顧客が顧客マスタにいたらそれはおかしい。

940 ：NAME IS NULL：2008/07/22(火) 22:44:20 ID:???

忙しくてちょっと言葉を間違えただけじゃないの？

941 ：NAME IS NULL：2008/07/22(火) 22:54:34 ID:???

単純に聞き間違いとか、使う言葉の意味が両者で統一されていないだけかも。
マスタテーブルがトランザクションテーブルへの参照を持つようなことって、少なくとも基本的な設計ではないよね

942 ：NAME IS NULL：2008/07/22(火) 23:45:43 ID:???

>>932
そう言うことじゃなくて、

社員テーブル.部署コード ⇒ 部署テーブル.会社コード ⇒ 会社コード.会社名

で会社名がわかるんだから、社員テーブルになくてもいいんじゃね？

と言うことだと思うけど。

943 ：NAME IS NULL：2008/07/23(水) 03:38:28 ID:???

>>933
COBOLそれもマグネットテープ時代の用語だと
マスターが主データで
トランザクションは更新データ（キー99を削除、キー88のデータをXXに更新といったデータ）と
いう意味で使っていた。
上司の年齢が５０台以上なら要注意な。

944 ：NAME IS NULL：2008/07/23(水) 03:40:52 ID:???

>>933
まあなんだ、外部キーをリファレンス先のキーと混同することはありがちなこと。

945 ：NAME IS NULL：2008/07/25(金) 14:39:36 ID:???

>>933
http://www.grapecity.com/japan/devclub/Consultants/how_to_database/025/page01.htm
> というのは、かつては基本情報を記録する「マスターテーブル」に対して、
> 日々書き換えられる販売や勤怠、在庫などの情報を「トランザクション
> テーブル」と呼んでいたからです。過去の業務処理ではテーブルに対して
> 『マスターとトランザクション』という ...

夜間バッチの世界なんだろうな。

946 ：NAME IS NULL：2008/07/26(土) 03:24:39 ID:oNJlmvYG

トランザクションテーブルは、サロゲートキー派が多いが、
伝票データのとかの主キーをDBMSで発番（連番）すると、
DBMSによっては同一ページに対するロックが競合しまくって
パフォーマンスが悪くなりませんか？

947 ：NAME IS NULL：2008/07/26(土) 08:40:12 ID:???

>>946
PAGE LOCKを使ってなければ問題にならない。
もし最大値＋１の処理やってるならそりゃ論外。

948 ：NAME IS NULL：2008/07/26(土) 10:32:29 ID:???

>>946
正直何を心配してるのかさっぱりわからない。
ナチュラルキーならロックが起こらないと？

949 ：NAME IS NULL：2008/07/26(土) 12:25:21 ID:oNJlmvYG

主キーがクラスタ化インデックスになる場合、
連番だとPAGE LOCKのかかる範囲が分散しないのではという疑問です。

950 ：NAME IS NULL：2008/07/26(土) 12:43:16 ID:???

とりあえず、>>946のレベルではそのへんのパフォーマンスのことを気にしても
しょうがない。へたに「工夫」して変な設計にしてしまうのがオチ。

951 ：NAME IS NULL：2008/07/26(土) 15:52:17 ID:???

とりあえずどのDBMSの話をしてるのかはっきりしろ。

952 ：NAME IS NULL：2008/07/26(土) 23:44:54 ID:???

ロックが競合しまくってパフォーマンスが悪くなったとしても
運用上支障がでる程度のパフォーマンス低下なのかどうかが問題

953 ：NAME IS NULL：2008/07/28(月) 09:59:53 ID:???

＞主キーがクラスタ化インデックスになる場合、
といってるからMSSQLサーバーなのだろうが、
そこでPAGE LOCKがかかるとするとver.7より古い？

DBMSのチューニングは３犠牲にして５性能をアップするようなことをするもので、
等価ではないがある程度のトレードオフはつきもの、
一部だけ取り上げてどうこういうのはどんなものか。
例えばクラスタ索引のfill factorに十分余裕を持っている場合
挿入するキーが分散していればパフォーマンスはあがるだろうが、
fill factorが100%に近ければあっちこちでページ分割が起きてパフォーマンスは下がる。
クラスタ索引のfill factorはその特性からディスク容量への影響が大きく余り低く出来ない。

954 ：NAME IS NULL：2008/07/30(水) 12:29:21 ID:???

テキストが PRIMARY KEY なテーブルってどう思う？
たとえば

CREATE TABLE tbl (
　name TEXT PRIMARY KEY

955 ：NAME IS NULL：2008/07/30(水) 13:08:56 ID:???

TEXTの実装がDBMSでまちまちだしなぁ

956 ：NAME IS NULL：2008/08/04(月) 17:39:10 ID:???

あいまいな日付を格納したいとき
日付型使ったらいいか悩む
文字列型にするしかないのか

957 ：NAME IS NULL：2008/08/04(月) 19:03:35 ID:???

どんな検索やソートをするかにかかってる。
俺は日数や時間の計算をSQLでやりたいから
DATETIMEを使うことが多い。

958 ：NAME IS NULL：2008/08/04(月) 21:26:33 ID:???

>>956
あいまいな日付って、そもそもどんなのを想定してるの？
「8月」「8月上旬」「8月第1週」「8月4日前後」とか？

959 ：NAME IS NULL：2008/08/04(月) 21:38:00 ID:???

そういうのってさあ、業務側では、月末扱いとか翌月初扱いとかなるもんじゃないの？
無理にDBに曖昧なデータ入れる必要があるのか？

960 ：NAME IS NULL：2008/08/04(月) 22:06:32 ID:???

あいまいとは何か

961 ：NAME IS NULL：2008/08/04(月) 23:25:33 ID:qp/dDDtF

テーブル設計について質問があります。

某物流会社のシステムを作っているのですが、
そのシステムではログインに関して以下の要件があります。
・システムにログインするためには、社員番号とパスワードを入力する必要がある。
・システムには、サブシステムが５つほどあって、役職によってそれぞれのサブシステムにアクセス可能かどうかが決まっている。
・ただし、あるサブシステムにアクセス権限のない役職でも、特定の社員だけ一時的にのサブシステムにアクセス可能にすることもできる。

これらの条件を満たすために、以下のテーブル設計を考えてみました。
□社員テーブル
・社員コード
・社員名
・役職コード

□役職テーブル
・役職コード
・役職名

□権限テーブルA
・サブシステムコード
・役職コード

・権限テーブルB
・サブシステムコード
・社員コード

あまり、テーブル設計の経験がないので、この場合はこうするべきだ！とか、こっちのやりかたの方がいいよ！みたいな
意見をお伺いできればなと思います。

よろしくご教示願いいます。

962 ：NAME IS NULL：2008/08/04(月) 23:41:30 ID:???

それであってる。
申し分ない

963 ：NAME IS NULL：2008/08/05(火) 01:24:15 ID:???

964 ：NAME IS NULL：2008/08/05(火) 01:25:10 ID:???

>>961
もし、役職が課長の人だけアクセスできるサブシステムについて、山田課長だけアクセスさせたくない場合を考えた場合、
権限テーブルBに、山田課長以外の課長を全員登録する必要があると思うんだ。
だから、アクセス許可レベル（権限なし、レベルA、レベルB、etc...）を追加したらどうだろう。

□権限テーブルA
・サブシステムコード
・役職コード
・アクセス許可レベル

□権限テーブルB
・サブシステムコード
・社員コード
・アクセス許可レベル

小規模のシステムなら、>>961さんの設計で問題ないと思うけど、
ある程度規模が大きいなら汎用的に作るべきだと思うんだ。

>>962
昔、中学の先生がいってました。「意見が無い奴は、知性が無い。」

965 ：NAME IS NULL：2008/08/05(火) 01:56:11 ID:???

>>964
何かしらケチをつけなきゃ意見が無いって考えか。歪んでるな。
賛同したら負けだとか思ってそう。

言われても無い仕様を追加すりゃ、そりゃいくらでも付け加える要素はあるさ。
>>964で実現できない（そして誰も要求していない）仕様はたくさんあるだろ。

966 ：NAME IS NULL：2008/08/05(火) 03:02:24 ID:???

まあありがちな病気だから。

967 ：NAME IS NULL：2008/08/05(火) 03:13:57 ID:???

>>964
っYAGNIの原則

968 ：NAME IS NULL：2008/08/05(火) 03:19:45 ID:???

>>967
YAGNIの法則は、大規模システムでは向かない

969 ：NAME IS NULL：2008/08/05(火) 06:41:35 ID:???

個人的にはそういうのはOSレベルで制御した方が
あとあと後悔しないと思わなくもない。

現に後悔しているシステムを見たことあるので。

DB2/400みたいなヤツだと管理とか楽。

YAGNIはあれはあれでちゃんと意味があるから、出来るなら実践すべきだと思う。

970 ：NAME IS NULL：2008/08/05(火) 09:02:55 ID:???

意見が無い奴は、知性が無い。

うちのプロジェクトがグダグダな原因は、これだ。
どいつもこいつも他人の仕事に首突っ込みすぎ。
決まるものも決まらない。言うだけ言って責任取らないし。
いかにも教職員って感じの思想だよね。最悪。

971 ：NAME IS NULL：2008/08/05(火) 09:24:08 ID:???

有用な意見は歓迎だが、無駄に話を引っ掻き回すのは勘弁してくれってやつだな。

＞この場合はこうするべきだ！とか、こっちのやりかたの方がいいよ！みたいな意見をお伺いできればなと思います。
と聞いてるのだから、それで十分と答えるのも、聞かれたこと以上のことを答えるのも回答として成立する。

>>969
OSやDBMSレベルのアカウントを使うか、アプリケーションで独自に持つかというのはいつも悩みます。

972 ：NAME IS NULL：2008/08/05(火) 11:12:37 ID:???

>>964
>962は明確に肯定しているから意見が無いのとは根本的に違う。
汎用的に作るならいっそ役職と権限を独立させて
□社員テーブル
・社員コード
・社員名
・役職コード
・権限コード
□権限テーブル
・サブシステムコード
・権限コード
としたほうがすっきりすると思う。

973 ：NAME IS NULL：2008/08/05(火) 11:47:41 ID:???

>>964は煽った割には
たいした話をしてないのがだめだったな。

つかこれ、YAGNIとかいうレベルじゃないでしょ。
頼まれもしないのによかれと思ってやってみました、って奴。

974 ：NAME IS NULL：2008/08/05(火) 22:05:39 ID:???

>>973
ときどき、なぜかユーザーより自分の方が「ユーザーの真の要件」を理解しているという
妙な自信を持った開発者がいたりするもんな。

そんで、ユーザーが「役職の権限を変更しても反映されない社員がいるんだけど…」とか
質問してくると、小馬鹿にしたような態度で「ちゃんとアクセス許可レベル設定しましたぁ？」
とか言ったりして。

975 ：NAME IS NULL：2008/08/05(火) 23:33:14 ID:???

まあ所詮2ch、仕事じゃないんだし、
こんなケースも考えられるよって出すのは
別によかったと思うんだけどさあ、
最後の１行でそんなフォローする気なくす。

976 ：NAME IS NULL：2008/08/05(火) 23:50:16 ID:???

>>971
＞OSやDBMSレベルのアカウントを使うか、アプリケーションで独自に持つかというのはいつも悩みます。

サブシステムが５個しか(?)ないなら、サブシステムをスキーマ毎に分けて、社員テーブルを
OSのユーザープロファイルにすれば、そういう社員テーブルや役職テーブルとか無しで
>>961の要件に対応可能だけど。

そのうちアクセスログやらジャーナルとか、パスワードは定期的に変更とか英数字まぜこぜじゃないとダメとか、
過去５回とパスワード文字列が一致したダメとかシングルサインオンしたいとか要望が出た時に
OS任せにしておいた方が絶対に楽。

977 ：NAME IS NULL：2008/08/06(水) 00:48:40 ID:???

既に複数のサブシステムがある訳だし、>>976が完璧な答えだと思います

978 ：NAME IS NULL：2008/08/06(水) 01:14:28 ID:???

>>976
楽かどうかってのは一概には言えないと思うよ。
というか、将来出てくるかの知れない(今は分からない)要求に備えると
いうことならOS任せにはしない方が楽だと思うが。

例えば「パスワードを忘れたときに、メールでパスワードを送ってくれる
ようにしてくれ」とか、「かわりに、あらかじめ登録しておいた質問に
答えることでログインできるようにしてくれ」とか。

979 ：NAME IS NULL：2008/08/06(水) 01:28:41 ID:???

OS 任せなので、そう言う要求には応じられません。

と言う予防線なのでは？ (w

980 ：NAME IS NULL：2008/08/06(水) 01:55:09 ID:???

なるほど、そりゃ楽だw

981 ：NAME IS NULL：2008/08/06(水) 06:43:32 ID:???

>例えば「パスワードを忘れたときに、メールでパスワードを送ってくれる
>ようにしてくれ」とか、「かわりに、あらかじめ登録しておいた質問に
>答えることでログインできるようにしてくれ」とか。

必要になった部分だけ自前で設計＆実装すればいいのでは？

レンタル鯖で激しいOS制御(?)が出来ない環境ならともかく、
自前で所有する鯖だったら、自前で実装する必然性が解らん。
自前で実装すると後からボロボロとなるケース多いし。

あと、「OS 任せなので、そう言う要求には応じられません」は
ホント便利。w

最近パスワード絡みの案件で後から苦行を強いられた身としては
「将来出てくるかの知れない(今は分からない)要求に備える」と言う意味に
おいてもOS任せにしておいた方が楽なケースが多いとｵﾓ

982 ：NAME IS NULL：2008/08/06(水) 22:03:35 ID:???

>>981
>> 例えば「パスワードを忘れたときに、メールでパスワードを送ってくれる
> 必要になった部分だけ自前で設計＆実装すればいいのでは？

今時平文パスワードをほいほい取得できる OS なんて無いと思うが。

結局パスワード周り、つまりログイン関連全てに手を入れる羽目になると思うぞ。

983 ：NAME IS NULL：2008/08/06(水) 23:09:36 ID:???

>今時平文パスワードをほいほい取得できる OS なんて無いと思うが。

その考え方からしておかしいと思うが。
なんで取得する必要があるのだろう？

ユーザーがパスワードを忘れた場合はランダムなパスワード、もしくは超簡単なパスワードで
で初期化して次回ログイン時に強制的にパスワード変更させる、って運用しているのが多いだろうに。

984 ：NAME IS NULL：2008/08/07(木) 01:33:40 ID:???

>>983
いずれにしても、OS認証を採用した場合はそのような要求には応えられないわけだ。

その要求がおかしいかどうかを決めるのはユーザー(要件を決定する側)の仕事だろ。
典型的な>>974だな。

985 ：NAME IS NULL：2008/08/07(木) 03:12:30 ID:Ozd0b/vL

正規化のスレみても、
なんでも正規化すればよいわけじゃなく、
故意にしないっていうのも手っていうレスがちらほら。

やっぱり場数踏むしかないの？
設計って。

良い参考書あれば教えてほしい。

986 ：NAME IS NULL：2008/08/07(木) 06:38:32 ID:???

>いずれにしても、OS認証を採用した場合はそのような要求には応えられないわけだ。

いや、答えちゃいけない要求だろ。ソレ。
それだとパスワードをハクられまくりの仕様じゃん。ｗ
後任者に「ヴァカが設計した」と言われる典型だぞ。

事の善悪の判断も出来ないなら設計しないがいいと思うが。

987 ：NAME IS NULL：2008/08/07(木) 09:20:28 ID:???

なんか脱線しそうだな

988 ：NAME IS NULL：2008/08/07(木) 21:29:08 ID:???

頭悪いくせに突っ込まれると言い返さずにいられないいつもの奴だろ。
まともに相手すると話を逸らしまくるから議論がグダグダになるんだよな。

989 ：NAME IS NULL：2008/08/07(木) 21:30:10 ID:???

反対意見が無いと知性がない訳だからな。
しょうがない。

990 ：NAME IS NULL：2008/08/07(木) 23:06:18 ID:???

>>985
答えとしては、場数踏むしかない。

でもまずは、可能な限り正規化して設計すべき。
何個かやってると、しない方がいいケースがわかるようになるから。

でも、しない方がいいケースなんてそんなにないと思う。

>>986
> いや、答えちゃいけない要求だろ。ソレ。

わかりました、他のベンダさんをあたってみますわ。

991 ：NAME IS NULL：2008/08/07(木) 23:17:22 ID:???

正規化しすぎで困るってどうせ細いマスターが増えすぎて
結合のクエリ書くのがめんどくさいとかそんな理由だろう？

992 ：NAME IS NULL：2008/08/07(木) 23:20:01 ID:???

面倒なんじゃなくて、高速な抽出が難しくなる場合も結構あるよ。
どうやっても非正規化のほうが速いとか。

993 ：NAME IS NULL：2008/08/08(金) 01:16:36 ID:???

実績系のデータとか、業務的に必要なケースも普通にあるよね＞非正規化

994 ：NAME IS NULL：2008/08/08(金) 05:11:13 ID:???

残高はサマリ作っとかないと軽く死ねるしなー。

995 ：NAME IS NULL：2008/08/08(金) 23:13:34 ID:???

>>992
検索する側からみれば、そういうことになるかもしれない
でも、データの修正・削除などのメンテナンスのコストを考えると
正規化したほうがよろしい

996 ：NAME IS NULL：2008/08/08(金) 23:22:50 ID:???

そんなもん、メンテナンスツール作れ。

997 ：NAME IS NULL：2008/08/09(土) 09:12:39 ID:???

夏だなぁ・・・で次スレは？

998 ：NAME IS NULL：2008/08/09(土) 11:32:11 ID:???

DB設計を語るスレ 2
http://pc11.2ch.net/test/read.cgi/db/1218247432/

999 ：NAME IS NULL：2008/08/09(土) 12:07:47 ID:???

こえてゆ～く～はるか～すれ～よ

1000 ：NAME IS NULL：2008/08/09(土) 16:27:06 ID:???

DB設計を語るスレ 1000
http://pc11.2ch.net/test/read.cgi/db/1166540159/1000

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。