DB設計を語るスレ - 暇つぶし2ch

DB設計を語るスレ at DB

1:NAME IS NULL
06/12/19 23:55:59 hprRM4qH
語れ！！

2:NAME IS NULL
06/12/20 00:57:33 4iqFdJvf
正規化って何で必要なの？特に必要ないように思うんだけど。

3:NAME IS NULL
06/12/20 07:01:38
なんとなく、思うのは、
データの重複をさけたいからではないかと。

4:NAME IS NULL
06/12/20 07:02:59
PKのないテーブルを設計する理由をおしえてほしい。
どんなときPKがいらないのか？

5:NAME IS NULL
06/12/20 13:54:06
データの重複を避けると、データの管理が簡単になるだろ

6:NAME IS NULL
06/12/21 00:20:12
>>4
めったに検索しないテーブルとか。

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

7:NAME IS NULL
06/12/21 10:22:50
システムで使う定数を入れておく
1レコードだけのテーブルとか。

8:NAME IS NULL
06/12/21 14:58:42 WlnR0fcq
ここの住人に質問です。

このやりとり、どう思う？
URLﾘﾝｸ(www2.moug.net)

9:NAME IS NULL
06/12/21 16:00:19
あほくさい

10:NAME IS NULL
06/12/22 01:00:52
>>8
どっちでもいいよ。どちらかが妥協すりゃすむし。
そんなんで工数伸ばすなよ。

11:NAME IS NULL
06/12/26 10:52:24
コード化なんてDB設計の概念であるの？
どの書籍読んでも出てこないんだけど？

12:NAME IS NULL
06/12/26 10:57:14
それ以前の問題化と

13:NAME IS NULL
06/12/26 11:44:47
>12
kwsk

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

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

15:NAME IS NULL
07/01/02 08:56:42
その手の仕事したことないの？

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

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

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

16:NAME IS NULL
07/01/02 11:22:59
標準データベース設計ってどこにあるの？
パッケージ製品ってぼったくられるじゃん。

17:NAME IS NULL
07/01/02 12:03:01
> 標準データベース設計ってどこにあるの？

日本語大丈夫か？

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

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

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

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

18:NAME IS NULL
07/01/02 18:07:11
業務別のパターン、結構本が出てるじゃん。
それ読みなよ。

19:NAME IS NULL
07/01/02 19:14:04
ISBNくれ。

20:NAME IS NULL
07/01/02 21:13:44
ISBN:457571075X

21:NAME IS NULL
07/01/02 22:48:45
うまい

22:NAME IS NULL
07/01/04 12:09:55
おまいら、DB設計で業務知識ってどのくらい意識してる？

23:NAME IS NULL
07/01/05 11:38:09
DB設計というか、設計そのもので意識しないとだめくね？

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

25:NAME IS NULL
07/01/05 23:21:22
システム化された風呂屋...。

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

26:NAME IS NULL
07/01/05 23:48:28
>>25
女湯にセキュリティホールがあるので安心です。

27:NAME IS NULL
07/01/06 13:48:48
番台に上がる老人が居なくなるから、存亡の危機とかでしょ。

28:NAME IS NULL
07/01/10 16:17:02
おまいら、しっかり嫁よ↓

NULL撲滅委員会
URLﾘﾝｸ(www.geocities.jp)

29:NAME IS NULL
07/01/20 10:27:38 30yvgBBL
Firebirdで会社の作業日報を管理するものを作ろうとしてるんですが
平日と休日の作業時間を別々に集計したいのですが、
平日か休日かのデータをどのように管理するのがいいのでしょうか？

30:NAME IS NULL
07/01/23 18:35:21
休日マスタ

31:NAME IS NULL
07/01/29 13:00:05
休日しますた

32:NAME IS NULL
07/02/02 01:32:36 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
07/02/03 01:14:10
まずマスタテーブルが３つもある理由から聞こうか。

34:32
07/02/03 13:49:09
顧客マスタ、商品マスタ、配送業者マスタと３つあって
この３つセットが複数のテーブルで外部キーとなっている。

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

35:32
07/02/03 15:21:16
もうちょい具体的に書く。

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

運用しだいだね

37:32
07/02/03 22:05:19
>>36
運用では流通IDでのみ受注入力なので問題がないようです。

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

38:NAME IS NULL
07/02/04 16:43:35
初DB作成で商品評価データベースを作りたいと考えています。

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

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

39:NAME IS NULL
07/02/04 16:56:08
設計の基本
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
07/02/17 18:52:52 JVcoRVj9

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

41:NAME IS NULL
07/02/17 20:46:55
必要なら作れ

42:NAME IS NULL
07/02/17 21:20:37 JVcoRVj9
>>41
あなたはどう管理していますか？
プログラム、それともテーブルで管理していますか？
私は、テーブルや、項目を管理するテーブルを作って、
下のような区分管理テーブルを作っています。

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

43:NAME IS NULL
07/02/18 03:11:58
汎用性持たせとくか、決め打ちかってだけじゃないの？

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

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

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

45:NAME IS NULL
07/02/23 23:45:03
>>44
その話題、この板のそこここに散らばってるなあ。
永遠のテーマなのか・・・。

制約っていらなくね？
ｽﾚﾘﾝｸ(db板)l50

他のスレで、インポート時は制約削除しちゃえという意見があって
なんでその手に気が付かなかったのかと思った。
ここらへんだ↓
ｽﾚﾘﾝｸ(db板:782-792番)

46:NAME IS NULL
07/02/24 00:32:27 7O++I76A
>>44
伝票ヘッダーと明細の関係の時に使うよ。
伝票消すときはヘッダーだけ消せばいいから

47:NAME IS NULL
07/02/24 14:09:22 +wKoEvab
くだらない質問かもしれないんですけど
カラムの命名でちょっと迷ってます。

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

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

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

48:NAME IS NULL
07/02/24 18:27:10
>>47
nameだと迷うかもしれないが
主キーとかはuser_idとかshop_idにしないと
両方とも他のテーブルのFKになった時に
結局名前付けなきゃならなくなるのでそうしてる。

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

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

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

49:NAME IS NULL
07/02/24 19:30:30 7O++I76A
主キーは普通IDじゃないとORマッパー使うとき不便だぞ

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

51:NAME IS NULL
07/02/24 21:43:37
と学歴しかとりえの無い>>50が逝っています。

52:NAME IS NULL
07/02/24 21:50:30
>>50
名前を表すといっても店名と人名は違うだろ？
って当然のようにいってるけどさ、
店名・人名の違いって何？

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

53:NAME IS NULL
07/02/24 21:52:41
>>50
面倒だからいっそ同じ名前(cd,name,telとか)にしてasで別名付ければ良くない？
使い回しするのはview作るんだろうし。

54:NAME IS NULL
07/02/24 22:26:37 7O++I76A
>>52
売上先マスタって・・・
後気持ちは分かるけど
ちょっとずれてるぞ
普通、得意先名と店名は意味合いが違うだろ

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

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

57:NAME IS NULL
07/02/24 22:36:49 7O++I76A
なら仕入先マスタはいらないじゃん

58:47
07/02/25 01:07:30 Zz8YGbzC
>>48
>>50
他、関連レスしてくれた人サンクス

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

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

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

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

59:NAME IS NULL
07/02/25 11:19:54
結局お客さんによりけりじゃないの？
もう理屈こねたって宗教論争ぽいよ。

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

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

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

60:NAME IS NULL
07/02/25 11:30:30 k357gTV0

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

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

62:NAME IS NULL
07/02/25 14:29:53
>>59
その例じゃ・・・

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

63:NAME IS NULL
07/02/25 15:24:38
>>61
テーブル設計ってより名前付けのポリシーだからなあ
どうしても悩んじゃうんじゃないかな。

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

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

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

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

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

65:NAME IS NULL
07/02/25 15:46:27 6/IGUhkO
そういうレベルの低い設計方法を話し合うスレなの？
IDEFとかの勉強をしたら？

66:NAME IS NULL
07/02/25 16:42:54
>>65
まずスレの流れを読む勉強したら？

67:NAME IS NULL
07/02/25 17:08:58
>>64
そうか、ドメインだ、その言葉ですっきりした。

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

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

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

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

68:67
07/02/25 17:10:21
ごめん。

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

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

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

70:NAME IS NULL
07/02/25 21:48:25
>>69
たぶんドメイン違い。

71:NAME IS NULL
07/02/25 21:57:49
>>56
> ユーザー自動作成の日別スケジュール表

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

72:NAME IS NULL
07/02/26 05:00:31
SHOP.SHOP_IDと記述する私は昔の人だと感じました

73:NAME IS NULL
07/03/03 23:50:38
OOのドメインモデルとRDBのドメインの区別ついてるか？

74:NAME IS NULL
07/03/07 01:20:30
通りすがりで酔ってるので、スーパー亀レス

>>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
07/03/23 10:18:56
業務知識もうろ覚え、データベース設計もろくにやったことが無い素人に基幹の
DBを設計させんなよ('A`

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

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

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

76:NAME IS NULL
07/03/23 11:38:15 HPT+SY9e
> ところでERWinって半額くらいで買えるキャンペーンとかないん？

Visio じゃ駄目なの？

77:NAME IS NULL
07/03/23 12:04:45
> ところでERWinって半額くらいで買えるキャンペーンとかないん？

紙と鉛筆じゃ駄目なの？

78:NAME IS NULL
07/03/23 12:35:08
>>76
ERWinの快適さに慣れると、VisioやObjectBrowserには戻れンすよ。
んでも、DBDesigner4を試してみたら思ったよりイケテる感じがしたんで
しばらく試してみようと思う。

>>77
m9（＾Д＾）

79:NAME IS NULL
07/03/23 13:05:54
ERWinは保守ツールだな。設計の後半から保守フェーズ向き。
設計の前半は紙と鉛筆、客向けの資料はVisioも使うぞ。

80:NAME IS NULL
07/03/23 13:43:38
>>75
URLﾘﾝｸ(www.sparxsystems.jp)
テーブル生成のSQL出力とかあったと思う。

81:NAME IS NULL
07/03/23 16:46:53
>>78
DBD4って辞書登録出来るん？
なんかどうやって項目を辞書登録していいんかわからへんかったやねんけど。

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

83:NAME IS NULL
07/06/10 22:18:03
余計なことして、仕事 (した気になってる) or (してる振りしたい) 奴がいるんじゃないか？

84:NAME IS NULL
07/06/10 23:30:51
テーブル生成SQLなんて、Excelでええやん。

85:NAME IS NULL
07/06/13 18:07:38 i/W8/Jf6
お前が管理者になって自分の部署がシゴトナシになった場合のやばさを考えるんだ

86:NAME IS NULL
07/06/13 23:24:01
いくらでもFreeでいいツール出てきてんのにEXCELって、酷いよね・・・

87:NAME IS NULL
07/06/14 00:42:01
>>82
その設計はおかしいんじゃない。
コボラーとかVB厨房の設計じゃないのかな。

88:NAME IS NULL
07/06/15 16:24:15
>>82
たしかに新機種が発売されるとテーブルが増えるという
設計はおかしいな。

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

89:NAME IS NULL
07/06/16 17:20:56
>>88
むしろ新機種の新機能部分は新規テーブルで作ってリンクという思想自体はアリでは?

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

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

90:NAME IS NULL
07/06/25 10:17:22 NcBbc/LF
それならいっそ

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

機能ID 機能名

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

91:NAME IS NULL
07/07/05 19:32:01 iUW9TYQf
質問です。

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

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

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

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

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

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

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

92:NAME IS NULL
07/07/05 19:36:36
>>86
社内規定でフリーソフト使用禁止なんだ……。

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

94:NAME IS NULL
07/07/06 00:03:10 7xm44r2b
>>91
情報のライフサイクルで分けるといいと思う。
測定が複数回行われたり、行われない場合もある（NULLが発生する）のであれば

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

のようにする方がよい。

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

95:NAME IS NULL
07/07/06 00:29:03
>>91
分ける意味も必要もないと思う。

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

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

96:NAME IS NULL
07/07/06 01:17:44
>>91

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

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

97:NAME IS NULL
07/07/06 13:57:11
>>93-96
ありがとう御座います。

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

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

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

がありました。

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

98:NAME IS NULL
07/07/06 14:14:35
>>97

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

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

99:NAME IS NULL
07/07/13 23:39:52
ちょうど今のＤＢ設計でそんな状態があったから書き込んでみる。

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

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

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

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

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

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

DOAじゃなくてｽﾏｿ

100:NAME IS NULL
07/07/14 00:06:04
100げっと

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

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

101:NAME IS NULL
07/07/14 09:27:40
> １テーブルにしてしまうと1回目はInsert、2回目はUpdateになるから、設計が面倒になるし。

意味わからん。

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

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

102:NAME IS NULL
07/07/16 23:28:22
>>99
>クラス設計だとその2つは「人」と「身体測定結果」の2クラスに分けるから

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

103:NAME IS NULL
07/08/07 19:12:21
初心者です。質問させてください。

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

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

104:NAME IS NULL
07/08/07 19:19:22
int

105:NAME IS NULL
07/08/07 19:21:00
tinyint～int で良いんじゃないか。

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

106:NAME IS NULL
07/08/07 23:04:45
>>103
nvarcharなら１時間でも一時間でも壱時間でも丑三時でもオッケーだぜ。

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

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

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

108:NAME IS NULL
07/08/08 09:10:20 aWfaidbN
「時刻（位置）」と「時間（距離）」は別物。
そして分単位が必要となるなら、分単位で保持しておくこと。

109:103
07/08/08 10:12:46
>>108
別物ですよね。ならばTime型はやめた方がいいということですよね？

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

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

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

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

113:NAME IS NULL
07/08/08 11:15:00
>>112
x:回答者も
o:質問者も

114:103
07/08/08 12:10:20
みなさんご親切にいろいろありがとうございます！

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

115:NAME IS NULL
07/08/08 13:58:43 aWfaidbN
interval型とか、ホスト言語から扱いにくかったりもするから注意。

116:103
07/08/08 16:43:16
>>115
javaを扱ってますがたしかにそのような感じですね。

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

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

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

119:NAME IS NULL
07/08/12 15:12:05 SxglpIS4
■ユーザー
ユーザーID/名前/etc...
■食べ物
食べ物ID/名前/etc...
■ユーザーの好きな食べ物
ユーザーの好きな食べ物ID/ユーザーID(FK)/食べ物ID(FK)

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

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

121:NAME IS NULL
07/08/12 23:51:52
>>120
「ユーザーの好きな食べ物ID」は
実装を考えた場合あった方がいい。

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

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

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

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

125:119
07/08/14 13:11:37 fI74lPjs
私はまさに、実装に便利なのと、いちいち考えるくらいなら主キーは全部IDにしてしまえと思っています。
デメリットもないですし。

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

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

128:126
07/08/14 14:15:19 vLfyd2Go
>>127

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

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

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

129:NAME IS NULL
07/08/14 14:35:20
>>126
そん時に入手可能なそこそこの金額のHDDにしておくので考えた事ない。

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

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

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

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

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

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

131:NAME IS NULL
07/08/20 06:03:01
リレーションシップがないからって別DBにしてたら別DBだらけになっちゃうよ。

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

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

133:NAME IS NULL
07/08/20 13:35:20
いや1インスタンスで複数DB作れたよ。

134:NAME IS NULL
07/08/20 15:07:30
それは勘違い。

135:NAME IS NULL
07/08/20 15:12:54
あらそうなの？

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

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

136:NAME IS NULL
07/08/20 15:57:59
Oraclerは大概インスタンスとデータベースをごっちゃにするよね（藁

137:NAME IS NULL
07/08/20 16:01:51
Oraclerは大概データベースとスキーマをもごっちゃごちゃにするよね（藁々

138:135
07/08/20 17:15:56
>>137
つまりそれが俺なわけだな。
つかオラクラーじゃないから勘違いしてるわけでして・・・。
あやまるからもういじめないで～

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

139:130
07/08/20 23:19:53
たくさんのレスありがとうございます。m(_ _)m

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

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

140:NAME IS NULL
07/08/26 01:27:07
>>135
オラクルのデータベースリンクは、分散システムの位置透過性を実現する機能。
なので、データベース同士のリンクって意味であってる。

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

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

141:135
07/08/26 01:43:26
>>140
わかりました。

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

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

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

143:NAME IS NULL
07/08/26 12:53:26
Oracleがそこまで便利になったらDB2の立つ瀬はないだろう。

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

144:NAME IS NULL
07/09/06 01:37:58
所詮コボラー専用箱だしな。
別途有料オプション購入で御賦せしないと他の鯖からSQLでアクセスできない囲い込み仕様。

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

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

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

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

147:NAME IS NULL
07/11/18 22:35:52
>>146
125=119
べつに「ID」って名前にするなんて話誰もしてないよ。

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

148:NAME IS NULL
07/11/19 01:40:31
スレ違いのところに投稿してしまってレス付かなかったので教えてください。

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

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

149:NAME IS NULL
07/11/19 02:33:20
どうもこうもねぇな

150:NAME IS NULL
07/11/19 02:40:17 bf1DMNXI
わけわかんねｗｗｗ
取りあえず縦にもってるからそれでいいんじゃねぇの？
一体何を聞きたいかわからない

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

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

151:NAME IS NULL
07/11/19 03:01:56
じゃがいもと肉ってわかってれば
カレーどう？とか肉じゃがどう？っていえる。

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

152:NAME IS NULL
07/11/19 23:10:41
これ縦にもってるんじゃなくて
列が2000あるって言ってるんだろ？

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

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

153:NAME IS NULL
07/11/19 23:20:11
つかそんないっぱい列って作れるの？

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

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

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

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

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

156:148
07/11/20 00:13:43
>>155
登録されるデータです。
↓これですと、一度の登録で2000行も追加されるのですよね？
10000回登録すると･･･行が増えすぎて不安です。

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

157:NAME IS NULL
07/11/20 00:43:47 fOu30nsb
可能性として10000X2000　ほどはデータ登録の可能性があるってこと？
一体何のデータか抽象的すぎてわからないけど・・・
10000X2000ほど新規登録が発生するとしたら結構な量だなぁ…

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

158:NAME IS NULL
07/11/20 01:25:28
XXX300位までは見た事あるけどなぁｗ
どんなデータなんだろう

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

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

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

このような感じです。

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

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

161:NAME IS NULL
07/11/20 12:17:36 AlZxTldT
テーブル数2000*7*n工場ってマジで言ってんの

162:NAME IS NULL
07/11/20 15:56:36 fOu30nsb
そのDBへの挿入や更新はリアルタイムじゃなくて夜間バッチとかでやるような処理じゃないのか？
それだったら別に1000万件とかでも平気だろ

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

次ページ