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万件とかでも平気だろ
リアルタイムにやれとか言われたらかなり悩むけど
163:NAME IS NULL
07/11/20 20:08:46
各システムは必ず2000件の配送先を持つのか。
2000件の配送先は増えたり減ったりする可能性は考えられないのか。
1万システム全体での配送件数が1日平均何件なのか。
例えばこれが全体で配送件数が5000件であれば、
配送件数として1日に増加するレコード数は最大5000にしかならない。
さらにもし1配送先に平均10件と仮定すれば
記録すべき配送先は500先なので1日で500レコード増加するに過ぎない。
(横持ちせずに(列で持たずに)、縦に持つようにした場合の話です。)
と、思うがどうか。
164:NAME IS NULL
07/11/20 20:38:55 wWhiZNbu
パソコンショップならここ！！
URLﾘﾝｸ(want-pc.com)
165:あぼーん
あぼーん
あぼーん
166:NAME IS NULL
07/11/21 01:04:15 ejwf2SGm
横持ちしない場合ってこんなんだと思うけど、集計とかやりやすいのかな？素人なんだけど俺
ID 配送先 値
： ： ：
167:bomtNmsCJ
07/11/24 04:00:24
URLﾘﾝｸ(cqiycu.cn) legal mp3 download
168:AANOlxiodCsz
07/11/24 12:07:43
URLﾘﾝｸ(bdzwbn.cn) happy mp3
169:dqGHtpsdsnzLW
07/11/27 18:49:28
qdcfAp <a href="URLﾘﾝｸ(ztphhovihfnd.com) [url=URLﾘﾝｸ(aapgkojubcll.com) [link=URLﾘﾝｸ(osatiejwhmbj.com) URLﾘﾝｸ(wigfjztncgof.com)
170:NAME IS NULL
07/11/28 16:44:05 yMQT4KPq
なんかの本だかサイトで主キーのないテーブルはいかん！
って見た気がするんですけど、
今、設計してて
WEBのアクセスログを取るテーブルに主キーがいらない気がするんですよね。
削除はこの日付より前のものって感じでcronで削除するのでいらないし
selectもgroup byとcountで集計しかしないので（index使われないですよね？たぶん・・・）
どうなんでしょう？
そういう設計はまずいのでしょうか？
171:NAME IS NULL
07/11/28 16:55:14 +hnShCQ+
別にいいんじゃね？
172:NAME IS NULL
07/11/28 17:15:29
困ってなきゃいいんじゃない？
173:NAME IS NULL
07/11/28 19:33:39
それならいらねーんじゃね？
一日に１回くらいしか集計しないんだったらインデックスやらキーを
つけるほどの事でもないし。
ただまあ、最近はフレームワークとかで主キーがあると
ﾗｸﾁﾝになるのもあるので、Webの画面に表示してどうこうする
テーブルとかは普通に主キーを設定しておく方が無難ではあるな。
174:NAME IS NULL
07/11/29 01:36:40 DGmlyzPU
大量のデータの場合、検索が遅い。
結局、DBMS側も一意のキーが特定できないと辛いのです。
経験則からなら○百万件以下のDBなら何も問題ないっす
175:NAME IS NULL
07/11/29 02:02:10
ログなんだからそのうち○百万件超えるだろ
176:NAME IS NULL
07/11/29 03:16:51
>>170
つーか、集計しておしまい程度のログを、
わざわざDBにログ突っ込む必要ないのでは？
177:NAME IS NULL
07/11/29 13:40:04
これなんかいいよ
URLﾘﾝｸ(www.forest.impress.co.jp)
178:huvOJjLyYD
07/11/29 20:15:08
URLﾘﾝｸ(zerozeroone.at.tut.by) ⅱ肛� 璞瑣� 砒�瑣濵
URLﾘﾝｸ(zerozeroone.at.tut.by) 砒�瑣燾� ⅱ肛�
URLﾘﾝｸ(zerozeroone.at.tut.by) �ⅱ濵 ⅱ肛� 砒��瑣濵
URLﾘﾝｸ(zerozeroone.at.tut.by) �礪��鮱 胙�魵魲� �
URLﾘﾝｸ(zerozeroone.at.tut.by) 胙�魵鮱 �ⅱ濵 粨蒟�
179:iTrTZQkcEuofEmTr
07/11/29 21:10:04
URLﾘﾝｸ(zerozeroone.at.tut.by) 砒�瑣燾� ⅱ肛�
URLﾘﾝｸ(zerozeroone.at.tut.by) �ⅱ濵 ⅱ肛� 砒�瑣濵
URLﾘﾝｸ(zerozeroone.at.tut.by) ⅱ肛� 粨蒟� 砒�瑣濵
URLﾘﾝｸ(zerozeroone.at.tut.by) 砒�瑣濵� �ⅱ濵 ⅱ肛�
URLﾘﾝｸ(zerozeroone.at.tut.by) 蒻�韃 ⅱ肛�
180:ORYqhlickQwwoRu
07/11/30 00:22:20
URLﾘﾝｸ(zerozeroone.at.tut.by) 胙魵� �ⅱ濵
URLﾘﾝｸ(zerozeroone.at.tut.by) �� 胙魵�
URLﾘﾝｸ(zerozeroone.at.tut.by) 璞瑣� 胙魵�
URLﾘﾝｸ(zerozeroone.at.tut.by) 蒡�璧湜� � 胙魵�
URLﾘﾝｸ(zerozeroone.at.tut.by) 胙魵� 粨蒟�
181:NAME IS NULL
07/12/17 00:26:40
５年分のログを記録とかだと、DBに突っ込んでおかないと軽く死ねるよ。
あと膨大な規模／台数を対象にログをとるとかさ。
おまいのところのちっぽけなサーバのログ取り程度じゃない世界もあるよ。
182:NAME IS NULL
07/12/17 07:27:05
ＤＢにつっこまないと死ねるｱﾌｫな職場環境の方が死ねると思うが。
ｱﾌｫ構成を自慢されてもな。
183:NAME IS NULL
07/12/18 07:06:27
ログをテキストで持ってて全文検索してる職場環境がゴミ。
オラクル動かしてる鯖のログなんて見てないのか(w
184:NAME IS NULL
07/12/18 19:27:37
質問があります。
類似の項目が可変＆多数ある場合どう設計すればいいでしょうか？
例えばイベント情報DB（一覧表示がメイン）で、
時間： 必須は開始と終了時間のみ。他に開場時間や最終入場時間などが追加の可能性。
料金： 当日・前売、席、男女、年齢などで異なり、且つ最低どれか１つが必須。
名称(イベントや会場)： 正式名・一般名称・略称 があり、詳細表示は全て、一覧表示は後者2つのどちらかを使用、など。
今は下記で考えています。
■基本テーブル
主ID/日付/開始時間/終了時間/他の時間リスト/会場ID/正式名/一般名称/略称/料金リスト/…
■会場テーブル
会場ID/正式名/一般名称/略称/住所/地図/…
●一覧表示時
主ID/日付/開始時間/終了時間/会場名(一般名称か略称)/イベント名(一般名称か略称)/料金(一部)/他の時間(一部）/…
●イベント詳細表示時
主ID/日付/開始時間/終了時間/他の時間(全て)/会場名３種類/イベント名３種類/料金(全て)/…
名称の重複は仕方ないとしても、時間・料金・割引をどうするか悩んでます。
各項目をすべてフィールドで用意すると空項目が多く無駄になるので、
可変部分は１つのフィールドにまとめて(○○リスト)、プログラム側での展開・処理を考えています。
（「開場#9:00 最終入場#16:00 △△時間#20:00 …」としてスペースと#で分割とか。）
ただ検索が大変そうで…。
よくあるケースと思いますが何か定番の方法あるのでしょうか？
185:184
07/12/18 19:28:38 prFbnylX
すみません。sageてしまいました
186:NAME IS NULL
07/12/18 23:19:51
>>184
頭んなかでアプリとDBがごちゃまぜになってないか？
名称の重複とかDB側では見当たらんし・・・
時間：
素直に開場時間や最終入場時間など用意しておいた方がいい
料金：
ちょっとメンドクサイね。
ホントにその条件なのか？当日・前売とその他が同列っておかしいくない？
名称(イベントや会場)：
何を悩んでるのかわからない上に仕様不明確。DB設計よりもアプリ側の話
ところでリストってArray型？差し支えなければDB教えてくれんか？
187:NAME IS NULL
07/12/20 16:54:20 F1yzUOQD
>>184
RDBで可変は限界がある。
無駄になると思いつつ空ばかりのレコードを作るか、
もしそれがいやならカンマ区切り等のセパレータで
区切られた文字列をつっこんでアプリで処理するのが一般的。
アプリ側の処理をある程度許容するのであれば、
まとめたい部分をテキストファイルにして、DBにはファイルパス
を入れておく。こうすると検索については全文検索に任せればいい。
SQLのLIKE文とどっちが速いかは分らん。
おすすめはデータベースを設計してみて容量見積もりをする。
その容量が許容できないほど大きいのであれば、どこかに
制約をつけるしかない。
Object Databaseっていう手もあるが、技術情報・技術者が
少ないのと速度見積もりが難しいので商業戦略としては
使いづらい。
188:NAME IS NULL
07/12/21 00:12:35
そんな糞設計が一般的なわけがない
189:NAME IS NULL
07/12/21 12:00:45 9gvFSqQa
カンマ区切り等のセパレータで
区切られた文字列をつっこんでアプリで処理するのが一般的。
これにはたまげたｗｗ
190:NAME IS NULL
07/12/22 14:25:55
>空項目が多く、無駄になるので
空項目が多く、無駄になるのが一般的です
191:NAME IS NULL
07/12/23 01:46:00
このスレってほんと投げられっぱなしだなｗｗｗ
192:23453030
07/12/23 02:39:57
こんな感じでどうだ。
■基本テーブル
イベントID/日付/会場ID/正式名/一般名称/略称/料金リスト/…
■スケジュールテーブル
イベントID/スケジュール名（開始・開場・最終入場・...・終了）/時間/一覧フラグ
※一覧フラグは、一覧表示画面に表示するかどうかをあらわす
▼開始時間ビュー（select イベントID, 時間 from スケジュール where スケジュール名 = '開始'）
▼終了時間ビュー（select イベントID, 時間 from スケジュール where スケジュール名 = '終了'）
■料金テーブル
イベントID/料金名（当日・前売、席、男女、年齢）/料金/一覧フラグ
※一覧フラグは、一覧表示画面に表示するかどうかをあらわす
■会場テーブル
会場ID/正式名/一般名称/略称/住所/地図/…
193:NAME IS NULL
07/12/23 04:37:05
可変カラムがあったらどうやるの？
カラムが増えたらALTERするの？
194:NAME IS NULL
07/12/23 06:54:17
>>193=187
無知なだけかも知れんが可変カラムって聞いた事無いんだけど・・・
アプリ要求とTableを対にするって発想でも無さそうだし、理解が出来ない。
COL1=A,B,Cとして持たせるって
AをSQL条件とする検索とかの仕様変更来た場合はどうするつもり？
このやり方でカラム増やしたってシステム上改修は必須で、逆にCOL1のデータへのアクセス部分の調査が必要になるでしょ？
COL1で対応できない要求された場合はALTERなりで拡張するんでしょ？
わざわざ難しくしてるようにしか見えない
195:NAME IS NULL
07/12/23 08:41:31
>>193
最初の要件で可変であることがわかっている属性があるならそのように設計する。
後から出てきたものなら設計変更。
196:NAME IS NULL
07/12/23 12:12:04
>>187
>>193
リレーショナルモデルにおいて、属性が可変なんてありえん。
197:184
07/12/24 16:26:34
遅くなってすみません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
07/12/25 00:14:17
正規化は知ってたのか。
だと、実務経験があまりないのかな。
正規化するとパフォーマンスが心配というなら、
「外部テーブル」が何件くらいになりそうか
見積もってみれば。
MySQLも含めていまどきのデータベースなら、
数万件から数十万件のテーブルから数件のデータを
とってくるのは一瞬のはず
（DBの先人は、そういうデータ取得を
高速化するためにまっさきに工夫してきたので）。
データがそれより大きい場合、いろいろ
考えなきゃいけないかも。でもその場合でも、
正規化したデータを前提にしたDBの
パフォーマンスチューニングが正道。
天才プログラマなら、ユニークな
方法で大成功するかもしれないけど、
そうでないなら教科書通りにやるのが吉。
199:NAME IS NULL
07/12/25 00:29:12
>>197
おまえ様は、RDBでの設計知識は全然ないだろ。アプリ屋だね。
RDBなんだよね？SQLって知ってる？結合(JOIN)ってわかる？
ごく普通にJOINすれば良いだけだろ？
なんで、一覧表示するのに、イベント１行検索して、その後、会場名検索するの？
SQL一発で、イベントも会場も時間も全部入で１００行でも１億行でも拾えるだろ。
それとも、そのレン鯖はJOINのコストが気になる様なマシンスペック&
データ量なのか？
200:NAME IS NULL
08/01/07 19:35:26 ivk9xsoC
マスタって例えばどんなデータが対象になるんでしょうか。
定型的なパターンとかありますか？
201:NAME IS NULL
08/01/08 03:53:42
なんと難しい質問。
人間って何？って言われてるみたいだ。
202:NAME IS NULL
08/01/08 03:57:59
とかいうのもなんなので、定説みたいなのは、
～名ってつくものはリソース、つまりマスタとみなす、
なんてよくいいます。
顧客名、ユーザー名、などなど。必ずしもそうではないんだけど。
まあ考え方の目安として。
逆に、マスタじゃないのはトラン系とかイベント系とかいって
～日ってつくもの。
受注日、出荷日とか。
てな答えでいいのかなあ・・・。すげー難しい質問だ。
203:NAME IS NULL
08/01/08 04:02:31
すんません、>>202はちょっと言葉たらずだった。
顧客名、ユーザー名、って～名がついてもおかしくないので
「顧客」や「ユーザー」はマスタ系テーブルと見なしてもいいかもしんない。
受注日、出荷日、って～日がついてもおかしくないので
「受注」や「出荷」はイベント系テーブルうんぬん。
って事です。
上のだと、「顧客名」って属性だけがマスタと呼ぶ、みたく思われ可燃。
要は「もの」と「こと」って事かと。
204:NAME IS NULL
08/01/09 00:57:55
業務的に帳票化して管理しているようなデータ集合をマスタって読んでることが多いな。
個人的にはマスタって言葉に違和感を感じるが、業務を遣ってる現場の連中がマスタって呼んでるので合わせてる。
正規化ってあんまり気にしなくても実害は少ないと思う。
コボラーとか旧世代の作った業務システムのデータなんて何万列も一つのテーブルで存在して正規化以前の状態で業務で使われてたりするし、
設計、開発当初はきっちり正規化してみたけど、現場の声でこのデータも欲しいと列をどんどん追加していったら、あんまり正規化されなくなってしまったなんて状況もあったりするし。
定期的にシステム更新して、正規化した構成に改善していくのが理想とは認識していても、現実は遣れてなかったりする。
正規化したからって売り上げに直接響くような資料を作って決済もらうのって、なかなか難しいし。
それより、パフォーマンス改善策として、より性能の高いハードウェアに更新しますって理由の方が予算／契約は取りやすい。
205:NAME IS NULL
08/01/09 10:07:22
>>204
俺もトラン、マスタって嫌い。
イベント、リソースだとわかりやすい。
正規化しなくても実害が少なく思えるのはね、
DBのクソ設計をアプリで一生懸命カバーしてるからで
そのアプリを残業しながらメンテしたりしてる人達がいるって事だよ。
転職前の俺がそうだったもん。
206:NAME IS NULL
08/01/09 11:06:48
その非正規化を否定することって、自分を否定してるようなもんだね。
それで飯食ってたんだから・・・。
207:NAME IS NULL
08/01/09 13:14:05
自分を否定する事なんかしょっちゅうだよ・・・。
つか、否定しようとしないから色々と大変なんだろう？
今までネットワークDBでやってきた自分のやり方とか、
そのままRDBに適用したり。
208:NAME IS NULL
08/01/10 06:59:11
コボラーなんて古い設計を否定せずに使い続けるしなあ。
コボラーの進化って止まってる(w
209:NAME IS NULL
08/01/11 17:00:48 7xR6a2PU
しかし、コボラーの設計思想というのは、
スタイリッシュではないが、何が起きても大丈夫なような安心感がある。
あれこれ頭を痛めるよりは、淡々と進めた方がいい場合もある。
210:NAME IS NULL
08/01/11 17:36:39
>>209
違うよ。何が起きてもどうにかする人が居るんだよ。
設計自体は、わざわざ何かが起こり得るようになっている。
最初に頭痛めれば起こり得なくなる何かが。
211:NAME IS NULL
08/01/11 22:19:23
＞スタイリッシュではないが、何が起きても大丈夫なような安心感がある。
安心感と言うか、感覚がズレてる感があるな。
ホストからの電文が一部ロストしたら、その後のキューにたまった電文が
全てズレで帳票印刷されて、壮絶な障害が発生した事があるんだが、
「 そ れ は 仕 方 な い な」
と力強いコメントいただいた事がある。
ｱﾌｫかと
212:NAME IS NULL
08/01/11 22:49:25
証券システムの日米比較で、「スペースシャトルと乳母車」に例えられるくらい、日本の汎用機コボラーはショボイ。
殿様抱え込み商法の超ぬるま湯団塊親父の吹き溜まり。
213:NAME IS NULL
08/01/12 05:43:07
安心感は全くないな。
列が何万行もあって、明らかに遅くなるテーブルを、何の疑問すら持たずに使い続けてるだけだよ。
コボラーの空気読めなさは異常。
テーブルの正規化でパフォーマンス改善できるのに、ひたすらハードウェアの性能でパフォーマンス改善しようとする。
そこそこ早い鯖なのに、遅いからしょうが無いとか言い出すし。コボルで組んだお舞らのバッチが遅いだけです(w
214:NAME IS NULL
08/01/12 06:32:28
重くてもしっかり動けばいいんだけど、やつらは付け焼き刃のバベルの塔を築くからなあ。
自分しか分からない（自分でも？）ようになっちゃって、既得権益を守ってきた。
215:NAME IS NULL
08/01/12 18:12:29
その方が高い鯖売り逃げることが出来るからな
ベンダとしてはコーダーを文盲統治したいところ
216:NAME IS NULL
08/01/12 23:02:12
技術的に正しいことが必ずしも商売として正しいとは限らないという事か
217:NAME IS NULL
08/01/13 00:07:35
>>211
>「 そ れ は 仕 方 な い な」
これで済むのか！無茶苦茶安心だ！
218:NAME IS NULL
08/01/13 00:09:06
>>216
短期的にはそうだねぇ。
でも長期的にはいつかツケが回ると思ってる。
特に中小は。
219:NAME IS NULL
08/01/13 06:22:29
>>218
そのツケが大きいところまで回ってきたのが、東証全面ストップ。
これも付け焼き刃で対応している筈なので、遅かれ早かれまた大規模な障害が出る。
そして東京市場が見捨てられている。
220:NAME IS NULL
08/01/13 22:45:20
長期的な視点があってもそれまで生きていなければ意味は無いから絶妙なバランスが必要だな。
つい読んでしまったけどこれマ板ネタじゃね。
221:NAME IS NULL
08/01/13 23:57:38
>>220
短期を乗り越えられるだけの現金は持っておけ、とか。
理想論かな・・・。
222:NAME IS NULL
08/01/14 01:46:46
東証のダウソや誤発注が通ってたのってコボラーの仕業なのか。
仕方ないねって平気で言いそうだ(w
223:NAME IS NULL
08/01/14 13:00:27
凍傷は不治に損害賠償求めたんだっけ
224:NAME IS NULL
08/01/17 17:10:23
すみません売掛金計算方法について助けてください。
販売管理のDB設計をしています。
日々、販売するごとに価格、売上数を売上テーブルに入力していっています。
また、売上の入金があるたびに、入金額を入金テーブルに入力していっています。
このとき、販売先別の売掛金や請求額、またその繰越残高を算出するために、
皆さんはどうやっていますか？
1日から月末までの計算ならいいのですが、請求額などは販売先ごとに締日が違っていて、
単純に計算するのは難しく悩んでいます。
自分の考えでは、
１）過去の売上テーブルの売上額の総合計－過去の入金テーブルの入金額の総合計＝売掛残高として計算する。
２）売掛テーブルを作成し、月イチや毎日のバッチ処理で、その月の売上合計と入金合計を売掛テーブルに保存する。
そして売掛テーブルの売上げの総合計－売掛テーブルの入金の総合計＝売掛残高として計算する。
３）売掛テーブルを作成し、月イチや毎日のバッチ処理で、その月の売上合計と入金合計を売掛テーブルに保存し、
さらに前月繰越額も計算して同じレコードに保存する。
の３つが考えられそうな気がしています。
ただ、１）だと締日が異なる販売先を一覧で表示する場合には、union等を使った複雑なクエリになりそうですし、
３）だと過去のデータを変更されると、それ以降の繰越額が全部ズレてくるので、それをすべて
修正しなければならず、２）が妥当なやり方のように考えているのですが、皆さんはどうしておられますか？
225:NAME IS NULL
08/01/17 17:28:25
>>224
俺なら、同時更新(リアルタイム) と日バッチ(チェック＋補正)で作るかなぁ。。。
DBだけでなんとかしようとしないと思う。
アプリでなんとかするｗ
アプリの話は、すれ違いになりそうなのでやめとくね。
226:NAME IS NULL
08/01/17 18:06:24
締月属性用フィールド追加
227:NAME IS NULL
08/01/17 18:13:03
あまり深く考えないで答えると、売掛金って勘定なんだから
そこには締めの概念が社内にかならずあるはず。
なので２。
請求先の締め日は、いつお客さんに請求書を送るかに関わるところだから、
債権管理には関係ないんじゃない？
社内の管理会計は当然その社の締めに基づいてされるはずだし。
どういう帳票を出したいのかがどうもイメージできない・・・・。
228:NAME IS NULL
08/01/17 19:46:21
>>225
ありがとう。自分もソフト側での更新も考えてます。
ただ、その時のDB設計はどうなのかと思いまして。
詳しくは下記の>>227さんへのレスを参照してください。
>>227
ありがとう。自分も2が適当なのかなと思っていたのですが、不安で・・。
ちょっと質問の仕方が適当でなかったかもしれません。
つまり、売上テーブルに販売数×販売価格を保存し、入金テーブルに入金額を保存していくとき、
売掛金を計算する場合に、皆さんはどのようにされているか、そしてそれを選択した理由が
何かをお訊きしたいということです。
１）売上テーブル、入金テーブルから、ある販売先のレコードを全て抽出し合計値から計算する
２）１）だと膨大な数になりそうなので、集計テーブルを用意し、そこに月ごとの売上金額と
入金金額をまとめた数値をバッチなり、同時更新なりで計算し保存していく。
イメージ的には「集計ID, 売上年月, 販売先ID, 今月の売上金額, 今月の入金金額」となる感じで、
これをsumすることで１）と同じ要領で売掛金を計算する。
３）やり方は２）と同じですが、フィールドを
「集計ID, 売上年月, 販売先ID, 今月の売上金額, 今月の入金金額, 前月の繰越金」とし、
やはりバッチなりリアルタイム更新で保存していく。
ただし、この場合は、前月繰越金＋今月の売上金額－今月の入金金額を計算すればｏｋ。
ですが、問題もあって、
１）データ件数が多くなると計算が遅くなりそう
２）１）ほどではないが、1ヶ月ごとに販売先の数だけレコードが作られるとやはり遅くなる？
３）計算は速そうだけど、過去のデータを修正すると、それ以降の繰越金がすべて再計算になる。
ということになりそうなので、果たしてどれがいいのかと、お知恵を貸していただきたかったわけです。
>>226
すいません。締月属性用フィールドという意味がよくわからないので、
よければ詳しく教えてください。
229:NAME IS NULL
08/01/18 10:27:58
2のバッチでのサマリーテーブル生成を選択した
最大の理由は、パフォーマンス対策です。
そのためにあえてone fact in one placeの原則をやぶるわけです。
債権残ってのは過去全ての取引の蓄積であって
そんなもん都度サマってたら、何年かして死んじゃう。
ついでに前月繰越残（要するに前月データ）も並べてもっておくと帳票出す時に楽。
うーん、これは異論ありそうだなあw
でも管理会計帳票って重くなりがちなんでこれくらいは許して欲しい。
230:NAME IS NULL
08/01/18 11:00:55
>>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
08/01/18 13:47:58
>>230
締めた後の過去の編集なんて、そもそも業務としてまずい。
普通は赤黒処理して当月側で処理します。
会計締めってそれだけタイトな業務なはず。
本来なら、ですけど。
そこまでの要望がない軽いシステムってのもあるだろうから
そうならどういう作りしてもどうとでもなりそう。
あとは好みなんじゃない？
232:NAME IS NULL
08/01/18 13:53:53
連投すまんですが、
まずはお客さんに過去売上の修正について
管理会計上どう処理してるか聞くのがいいと思うよ。
俺のお客さんでやっぱり適当に過去の売上いじってて
会計は会計事務所まかせになってて
いじった過去の売上をそのまま事務所に伝えてるだけってのがあった。
会計事務所側では恐らくちゃんと当月側で打ち消し仕訳起こしてるはずで
そうなると、月次の会計データと社内の売掛金データに食い違いが
出来てるはずなんだけど、それで仕事は回ってんだからいいんだ、って話になった。
しかも法律事務所。
233:NAME IS NULL
08/01/18 14:51:24
データベース設計ツール探してるんだけど、何かないだろうか？
dbwrenchとか
SI Object Browser ER 4
みたいなソフトで、フリーなのがないかなあと。
できれば日本語ドキュメントの生成も対応していて。
234:NAME IS NULL
08/01/18 17:37:03
TOADは？
フリーのはみんな記法がいまいちでなー。
235:NAME IS NULL
08/01/18 20:15:02
>>233
dbdesignerは？
236:NAME IS NULL
08/01/25 19:31:34 yAWOBhhy
今、渡辺幸三さんの「業務別データベース設計のためのデータモデリング入門」という本を読んでいるのですが、
作出属性というのがよくわかりません。他の列の値を使って計算した結果がはいる列のようなもののようですが…
OracleやSQLserverなどでテーブルを作るときには固有属性の列などと同じように作るのでしょうか？
計算した値はどうやって入れるのでしょうか？
237:NAME IS NULL
08/01/26 00:12:43
「作出属性」はその人の造語じゃないの？
たぶん、SQL-Server の計算列みたいなものかと。
> OracleやSQLserverなどでテーブルを作るときには固有属性の列などと
> 同じように作るのでしょうか？
Oracle は知らんけど、SQL-Server なら Yes.
> 計算した値はどうやって入れるのでしょうか？
列を定義する時に、式を定義しておくと計算結果が自動的に入る。
と言うか、実体はなくて select した時に計算して列を作る。
とりあえず、SQL-Server 計算列 でぐぐれ
238:NAME IS NULL
08/01/26 01:32:14 uG1o+X6G
>>237
有難うございました。計算列（仮想的な列）を 列名 AS 計算式 で定義しておけばselect時に計算してくれるのですね。
これは親テーブルなどの列の値を計算式に使ったりもできるのでしょうか？
239:NAME IS NULL
08/01/28 10:24:24
渡辺さん、本人に聞けば教えてくれるよきっと。
240:NAME IS NULL
08/02/10 06:01:35 tRxMhI5F
今やってる仕事なんだが、せっかくデータベース使っているのに、
一部のデータをテキストファイルで持っているんだが、こういうのってよくある話なんですか？
具体的にいうと、商品テーブルというのがあって以下のカラムを持っている。
・商品コード
・商品の種類
商品名が無いので、どこにあるかと思ったらテキストファイルに以下のように格納されてた。
1,コカコーラ350ml
2,みかん
3,餃子
担当者に何でテキストファイルにもっているのか聞いたら、
「作ったのは俺じゃないから知らないけど、優秀な技術者が作ったので何かしら意味はあると思う」
と言われました。
テキストファイルにデータを持つというのはよくあることなんでしょうか？
メリットがあるとしたら何でしょうか？
241:NAME IS NULL
08/02/10 06:18:56
>>240
ありがちなのはそのシステムがさらに古いシステムからのリプレースで、
仕様書がなくよくわからないところはそのままにしとこうなど安易な理由で、
旧プログラムやロジックをそのまま使うためにそういうのを残すことがある。
CHAR(80)なフィールドにCOBOLの固定長レコードをぶち込んだだけのテーブル
がごろごろしてたのを見たときは逃げたくなった。まさに底辺。
242:NAME IS NULL
08/02/10 10:17:15
Oracleだと、漢字の読みでソートというのができたと思うけど、
例えば、
安部（あべ）
木村（きむら）
斉藤（さいとう）
のように。
MySQLでこういうのはできる？
243:NAME IS NULL
08/02/10 11:04:38
社会保険庁じゃないんだから
読みのフィールドを持てば済む話
244:NAME IS NULL
08/02/10 11:19:57
>>242
Oracle、そんなことできんのか？
245:NAME IS NULL
08/02/10 12:11:11
萩原さんと荻原さんの区別はどうするんだろうか
246:NAME IS NULL
08/02/10 12:39:05
て言うか、エスパーじゃないんだから振り仮名なしで
| 神戸 (こうべ、兵庫県)
| 神戸 (ごうど、埼玉県 川口市)
| (他にも がうど、かうど、かど、かのと、かみど、かんど、かんべ、ごうと、
| こうど、ごうどう、ごおど、ごおと、じんご とかがあるらしい)
とかをどうやってソートしろと言うんだ？
247:NAME IS NULL
08/02/10 13:23:12
その辺は気合いで．
とか言う設計者が多摩にいるから困る．
248:NAME IS NULL
08/02/10 14:08:15
渋谷にもいるぜ
249:NAME IS NULL
08/02/10 14:29:14
>>240
工数と条件の間で苦心した結果の可能性は捨てきれないけど
>「作ったのは俺じゃないから知らないけど、優秀な技術者が作ったので何かしら意味はあると思う」
こんな事言う奴の「優秀」を信じないに1票
250:NAME IS NULL
08/02/10 15:13:38
組織によっては「何もしない」ことが優秀である件
251:NAME IS NULL
08/02/10 16:00:35
組織によらず、同じ結果がでるなら「何もしない」方が優秀である件
252:NAME IS NULL
08/02/10 16:23:05
ただの文字データから前後関係で
読みを的確に推測するとは
Oracleってすごいんだね。高いのもわかるわー。
253:NAME IS NULL
08/02/10 18:53:08
>>251
あれじゃ改修が発生した場合ネックになって複雑仕様を余儀なくされるようになる。
作り投げ屋や派遣なら関係ないけどね
254:NAME IS NULL
08/02/10 20:05:18
>>253
改修が発生してもネックにならないのであれば
「同じ結果がでるなら」に該当しないので
>>251 の言っていることは正しいと思う
255:NAME IS NULL
08/02/10 20:15:49
て言うか、状況もよくわからんのにネックになるなんて断言できる奴って
多分エンジニアより営業の方が向いてると思う。
256:NAME IS NULL
08/02/10 22:21:45
>>241
ていうか、今俺の仕事まさにそんな感じなんだけど、
コボラーに負けそうです・・・。負けたらそうなるんだろうなあ・・・。
257:>>240
08/02/11 00:49:42 PqAiPtIR
みなさん、ありがとうございます。
確かに、そのシステムは以前コボルで作られていたそうです（今はC）が、
以下の理由でリプレースになったんだとか。。
・団塊世代の退職で、システムを保守できる人がいなくなる。
・引継ぎすべき団塊世代の担当者が優秀なのだが、昔かたぎの職人で、質問に罵声で返答する。
・ドキュメントは誤字脱字、嘘ばっかり書いてある。
・で、引継ぎの先陣隊長が「こんなシステム引き継ぐぐらいなら会社やめてやる！」ぶち切れた。
となって、
結局リプレースになったんだとか。。
258:NAME IS NULL
08/02/11 01:59:52
>>257
そういうオヤジのことは「優秀」とは言わない。
259:NAME IS NULL
08/02/11 07:31:13
（今はC）
ここに突っ込んでもいいですか？
260:NAME IS NULL
08/02/11 15:01:13
>>257
リプレースで>>240なの・・・か？
261:NAME IS NULL
08/02/11 15:29:29
きっとうわべだけリプレース
262:NAME IS NULL
08/02/11 15:40:13
置き場所移動しただけ
263:NAME IS NULL
08/02/11 15:41:13
それじゃリロケート
264:NAME IS NULL
08/02/11 17:45:54
>>257
それってＣのを書いた「優秀な技術者」＝引き継ぎの先陣隊長なの？
結局その人辞めちゃったの？
265:>>257
08/02/12 01:49:03
>>264
＞それってＣのを書いた「優秀な技術者」＝引き継ぎの先陣隊長なの？
違います。
「優秀な技術者」の上司＝引き継ぎの先陣隊長
ですね。
「優秀な技術者」は別のプロジェクトにいったそうです。
＞結局その人辞めちゃったの？
辞めてはいないです。
ちなみに、そのぶちきれた先陣隊長は30代の人なんですが、
なんかこの業界って団塊の世代と、30代の人ってやたらすぐに切れる人多くありませんか？
この世代って人数が多いから闘争心なんかも異常に強いのかもしれませんね。
どこかの大学の実験で、ねずみを多く入れた箱と、少数のねずみを入れた箱を比べたところ、
多く入れた方の箱は少ないほうの箱より攻撃的になったと聞いたことがあります。
JRで以前、年齢別の車内暴力事件や飛び込み自殺を調べたところ、
団塊の世代と30代の男性が一番多かったとか。。
266:NAME IS NULL
08/02/12 04:59:01
30代はむしろ少ないだろ。
バブル世代は39以上だし、それより下は氷河期で。
267:NAME IS NULL
08/02/12 12:11:54
>どこかの大学の実験で、ねずみを多く入れた箱と、少数のねずみを入れた箱を比べたところ、
>多く入れた方の箱は少ないほうの箱より攻撃的になったと聞いたことがあります。
狭い場所に多くいるんだからストレス溜まって当然だろう
>JRで以前、年齢別の車内暴力事件や飛び込み自殺を調べたところ、
>団塊の世代と30代の男性が一番多かったとか。。
人数ベースで比較したら団塊と団塊Jr.が多いのは当たり前
ソースは？
268:NAME IS NULL
08/02/12 16:44:52
しかしアレだな。
なんでもかんでもカゴテライズしないと安心できないヤツ
ってのはいるもんだな。
漏れは業務ではそれを適切に行うのが仕事だけども
根拠のない思い込みで団塊がどーとか語るエンジニアいたら
ソイツはこういう仕事に向いていないと思うぞ。
269:NAME IS NULL
08/02/12 22:40:47
あれ？レスをよく読むと・・・
270:NAME IS NULL
08/02/21 07:51:39 MnpsKLDC
共通テーブルの扱いについて質問させてください。
あるプロジェクトAで使っているデータベースhogeに社員テーブルがあります。
今度、新しいプロジェクトBが立ち上がりましてデータベースfooを作りました。
プロジェクトAと同じように社員テーブルが必要なのですが、
共通テーブルとして社員テーブルを持たせるようにするか、
各プロジェクトの各データベースの中に社員テーブルを持たせるようにするか悩んでおります。
共通テーブルとして社員テーブルを作れば、メンテナンスが楽だなとは思うのですが、
テーブルのjoinができなくなるので大変かなと思ってます。
各プロジェクトの各データベースに社員テーブルを作った場合、
データベースhogeで更新した社員テーブルをデータベースfooの社員テーブルに
どのように反映するかが課題となります。（こういうのにトリガつかっていいんでしょうか？）
このように、複数のプロジェクトで共通に必要とするテーブルがある場合、
皆さんなら共通テーブルにしますか？各データベースの中に社員テーブルつくりますか？
271:NAME IS NULL
08/02/21 07:54:43
>>270
DBサーバーが別ということならレプリケーション。
一方向のレプリケーションなら運用も楽。
272:>>270
08/02/21 23:36:26 J1OJ+3YP
>>271
DBサーバは同じです。
273:NAME IS NULL
08/02/22 07:00:01
>このように、複数のプロジェクトで共通に必要とするテーブルがある場合、
DBを分けない
274:>>270
08/02/22 07:20:10 jGuXLD6i
>>273
たとえば、勤怠管理システムと給与計算システムがあったとします。
この場合、それぞれのシステム毎にDBもつのが自然ですよね？
275:NAME IS NULL
08/02/22 09:37:34
オマエは一度MS Accessでもいいので簡単なアプリ作ってみろ
276:NAME IS NULL
08/02/22 10:24:29
>>274
要件による。
特に要件がなければ分けない。
277:NAME IS NULL
08/02/22 14:10:39
>>274
システム毎にDBをもつと
１．データの共有が面倒
データの不整合が生じる場合がある。
２．サーバーに負荷がかかる
メモリーやセマフォなどのサーバー資源をDBごとに持つから
DBを２つにすると、サーバー資源は２倍になる。
結果として、パフォーマンスの低下を招く恐れがある。
欠点ばかりで、よいところはひとつもない。
どうしても分けたいなら、DB単位でなくスキーマでわけるとか。
278:NAME IS NULL
08/02/22 22:18:01
>>270
>共通テーブルとして社員テーブルを作れば、メンテナンスが楽だなとは思うのですが、
>テーブルのjoinができなくなるので大変かなと思ってます。
なんでJOINできないの？
DBなにつかってんの？
279:>>270
08/02/23 11:02:16 plV93xd4
>>278
DBはMySQLを使っています。
異なるデータベースのテーブルをjoinすることができるDBってあるんですか？？
280:278
08/02/23 12:20:45
>>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
08/02/23 12:50:25
>>280
MySQLだからって部分じゃなくね？つか出来ないのってあるの？
両方の参照権限あるユーザであれば select * from db1.table1, db2.table2 出来て当然。
282:NAME IS NULL
08/02/23 20:34:46
＞異なるデータベースのテーブルをjoinすることができるDBってあるんですか？？
そりゃまあ、商用RDBのDB2なんかは
select * from Oracle.table1, MySQL.table2
みたいな結合もできるが、あんまやらん罠。
つか、相手が嫌がるケースが多いし、「勤怠管理システムと給与計算システム」
とかなら社員が何万人いるか知らんがMySQLだけで十分だろ。
283:NAME IS NULL
08/02/26 04:46:20
シェンロンも作ってんのか?
すっげぇな、おめぇら
284:NAME IS NULL
08/02/27 00:23:24
＞システム毎にDBをもつと
＞１．データの共有が面倒
＞データの不整合が生じる場合がある。
＞欠点ばかりで、よいところはひとつもない。
＞どうしても分けたいなら、DB単位でなくスキーマでわけるとか。
システムが別なら、DBも別にするべきだろ？
たとえば、あるサーバに勤怠管理システムと給与計算システムが動いてたとするだろ？
それで、一つのDBに二つのシステムで使われているテーブルが全部入っているとする。
ある日、なんらかの理由で給与計算システムだけ別のサーバに引っ越すことになった場合、
そのDBで使っている給与計算システムのテーブルがどれなのか調べるのが面倒じゃん。
だから、１DB＝1システムで使用するDBであるべき。だと俺は思う。
285:NAME IS NULL
08/02/27 01:10:11
どのシステムがどのデータベースの中のどのテーブル
使ってるかぐらいは把握しとこうよ。
286:>>284
08/02/27 01:47:11
>>285
業務で使うテーブルなんて１システムで１００テーブルはザラ。
そんなのを把握しようとするのが間違い。
人間は間違いを犯すという前提で、考えるべきだと思う。
287:NAME IS NULL
08/02/27 01:51:44
284の人気がどこまで上がるか。
288:NAME IS NULL
08/02/27 03:16:41
>>274
ネタなのか釣りなのか。とりあえずマジレスしてみよう。
少なくとも業務システムだと、サブシステム一式をサーバ単位で分けるなんて
設計はあり得ない。(「3層クライアントサーバ」でぐぐれ)
Web系のシステムだと、
Webブラウザ ⇔ ロードバランサ×2 ⇔ Webサーバ×4 ⇔ アプリケーション(AP)サーバ×4 ⇔ DBサーバ×2
とかになってるのがふつー。(「⇔」の部分はネットワーク接続な) 規模が小さ
くてサーバが共存してるケースはあるけど、論理的な構成はあまり変わらない。
(他に、NASやSANやバックアップ装置なども付随してたりはする)
勤怠管理システムや給与計算システムみたいなやつは、サブシステムとして
全部APサーバにぶらさがってる。APサーバ間のセッション共有は、クラスタ化
するとか、セッション情報を全部DBやメモリキャッシュサーバに持たせる。
DBの分割はあくまで業務を基準に分けられる。サブシステム単位ではない。
例えば上記の勤怠管理と給与計算だと、社員マスタあくまで共通。
289:288
08/02/27 03:17:47
うぎゃ、レス先間違えた。>>274→>>284 でした。
290:288
08/02/27 03:30:08
288の下2行、微妙に話がずれてるような気がするので補足。
サブシステム間で共通する情報を持っている場合(前述の社員マスタとか)、
DBのインスタンスは共通で、各サブシステム固有の情報は同一インスタンス内
の別テーブルに格納するのが普通だと思う。
291:NAME IS NULL
08/02/27 05:13:37
ファウラーの分散オブジェクト設計の第一法則。
「分散させるな」
URLﾘﾝｸ(martinfowler.com)
292:NAME IS NULL
08/02/27 05:16:18
>>286
見れば見るほど味わい深いな。
293:NAME IS NULL
08/02/27 22:05:40
「人間は」なんて言ってるけど、ホントは284が犯しちゃったとか？
294:NAME IS NULL
08/02/28 00:25:37
>>288
＞DBの分割はあくまで業務を基準に分けられる。サブシステム単位ではない。
おれは>>274じゃないですが、業務とサブシステムって何が違うんでしょうか？
業務＝業界？（たとえば、医療システム、建築システムみたいな単位？）
サブシステム＝（たとえば、医療システムの中の、電子カルテシステムみたいな単位？）
であってますか？
295:NAME IS NULL
08/02/28 01:00:43
>>294
業務全体は複数の業務から成る。
システム全体は複数のサブシステムから成る。
一連の業務は複数のサブシステム+人間系を組み合わせる形で実現され、
それらの業務がさらに互いに関連し合う、というイメージ。
例えば「受発注」という業務だと、
見積依頼→見積回答→発注→納品→検収
みたいな流れがあって、これが複数のサブシステムから構成される。
(例えば受注側と発注側とか、見積系と発注～検収系、みたいな感じ。
どう構成するかは設計者次第かなぁ)
で、これはこれだけで成立するとは限らなくて、予算管理や工数管理
などの業務と連携し、業務／システム全体を構成したりするわけだ。
296:NAME IS NULL
08/02/28 12:55:25
こうしている間にも284は何らかのシステム開発に関わっているのだろうと思うと、世の中怖くなる
297:NAME IS NULL
08/02/28 21:30:19
テーブルの正規化
298:NAME IS NULL
08/03/05 00:29:20 D2n410NJ
このたび、社内で日報システムを作ることになりまして、
みなさんのご意見をお聞かせいただきたい事があります。
以下の情報をテーブルで管理しようと思っています。
・日報ID（主キー）
・日報を書いた日付
・社員ID
・社員が書く日報（二バイト１０００文字）
これらの項目を一つの社員テーブルとして管理したほうがいいのか、
それとも経歴に関しては容量が大きいので、経歴テーブルというものを
別に作ったほうがいいのか迷ったのです。
性能を考えた場合はこうするべきだとか、保守性を考えた場合はこうするべきだとか
いろいろ考え方があると思うのですが、みなさんのご意見をよろしくお願いいたします。
299:NAME IS NULL
08/03/05 00:47:22
>>298
用語の統一って大事だよな。
なんにせよ社内システムでしょ？
俺なら拡張ありきと考えて、ある程度予測立ててTABLE分ける。
300:NAME IS NULL
08/03/05 00:47:23
社員マスタ
- 社員ID
- 氏名
日報
- 日報ID
- 社員ID
- 内容
- 日付
ていうか経歴テーブルってイ可？
301:>>298
08/03/05 01:11:15 D2n410NJ
すいません。。。かきなおします。
（自分のメモ帳で、全件置き換えしてそのままはりつけちゃいました。。）
このたび、社内で日報システムを作ることになりまして、
みなさんのご意見をお聞かせいただきたい事があります。
以下の情報をテーブルで管理しようと思っています。
・日報ID（主キー）
・日報を書いた日付
・社員ID
・社員が書く日報（二バイト１０００文字）
これらの項目を一つの社員テーブルとして管理したほうがいいのか、
それとも社員が書く日報に関しては容量が大きいので、
日報テーブルというものを 別に作ったほうがいいのか迷ったのです。
性能を考えた場合はこうするべきだとか、保守性を考えた場合はこうするべきだとか
いろいろ考え方があると思うのですが、みなさんのご意見をよろしくお願いいたします。
302:NAME IS NULL
08/03/05 08:27:46
しね
303:NAME IS NULL
08/03/05 20:24:17
>>301
自分が一生そのシステムの面倒見るなら好きに作れ。
他人にメンテさせてくなら、外部のSIerに作ってもらえ。
正直、その程度の事を他人に聞かないと判断できない人間が
やるべきではないと思うが。
304:NAME IS NULL
08/03/05 23:11:04
>>303
>正直、その程度の事を他人に聞かないと判断できない人間が
>やるべきではないと思うが。
同意
305:NAME IS NULL
08/03/06 23:23:04
社内でって言うんだから練習なんだろ
外で失敗するよりいいじゃまいか
306:NAME IS NULL
08/03/06 23:46:11
あまりに初歩的すぎるからな。
ここで答えを書いてしまうのはよくない。
307:NAME IS NULL
08/03/07 01:42:03
>>301
テーブル分けないほうがいいと思う。
ＳＱＬ作るのめんどくさいし、性能の面からいっても、たぶんテーブル分けないほうが、
ＤＢの中でテーブルとテーブルを接続する処理がいらないので早いと思う。
308:NAME IS NULL
08/03/07 01:57:07
>>301
> これらの項目を一つの社員テーブルとして管理したほうがいいのか
社員テーブルという名前でなくて日葡テーブルという名前にすればよいと思います。
309:NAME IS NULL
08/03/07 02:05:20
>>307
「思う」じゃなくて計測すべし。
310:NAME IS NULL
08/03/07 12:50:16
>>307
おぃおぃこのスレはいつの間にこういう輩を呼び込むようになったんだよ・・・
311:NAME IS NULL
08/03/07 19:32:43
過疎板の過疎スレの分際で態度だけはデカイな。ここの住民どもは。
312:NAME IS NULL
08/03/07 21:08:00 uMhc0dqS
来月の情報処理試験のデーターベーススペシャリスト試験を目指しているものですが、
モデリングの理解が難しくて四苦八苦しています。
業務の実例からモデリングするようなことを解説している本とかないでしょうか？
プログラマーとしてずっとやってきたのですが、
データーベースの概念設計からやったことは一度もないので、
その辺の知識を補いえたらと思います。
このスレは、色々探していたらヒットしたのですが、
データーベーススペシャリスト試験にも出ている内容が多くて非常に参考になります。
このスレがもっと延びていたら、よかったのにと思います。
313:NAME IS NULL
08/03/08 02:43:39
booch