2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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
3つのマスタテーブルがある場合に、それらをまとめて一つにした
テーブルって作る意味ある?

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:???
まずマスタテーブルが3つもある理由から聞こうか。

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

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



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作成で商品評価データベースを作りたいと考えています。

流れ
1webでユーザー登録(未登録はゲスト)
2ユーザーは商品に評価・感想を書ける
3それら評価などから商品をランキング表示可能

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

39 :NAME IS NULL:2007/02/04(日) 16:56:08 ID:???
設計の基本
1. エンティティを決める
2. 1:1, 1:n, m:nの関係を整理してリレーションを決める。

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

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

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

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

複合キーを受け入れられない人っているんだね〜(w

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と記述する私は昔の人だと感じました

21 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)