回答編集履歴
3
nullについて追記
test
CHANGED
|
@@ -113,3 +113,73 @@
|
|
|
113
113
|
ざっと見た感じですが、自分の好みに合わせるとしたらとりあえずこんな感じでしょうか？
|
|
114
114
|
|
|
115
115
|
もちろんこれは「今ある情報から見える自分が好きなやり方」なので環境上、また運用上そうは出来ないこともあると思いますし、他の方が見れば他にも多々案があると思います。
|
|
116
|
+
|
|
117
|
+
|
|
118
|
+
|
|
119
|
+
|
|
120
|
+
|
|
121
|
+
|
|
122
|
+
|
|
123
|
+
（追記 null許容云々について）
|
|
124
|
+
|
|
125
|
+
|
|
126
|
+
|
|
127
|
+
nullはいろいろと複雑さをDBに持ち込みます。
|
|
128
|
+
|
|
129
|
+
有名なのは3値論理問題ですが SQLの真偽値はtrue、falseの他にunknownという値が存在します。
|
|
130
|
+
|
|
131
|
+
これはnullが絡んだときに出てきます。
|
|
132
|
+
|
|
133
|
+
例えば見積書詳細テーブルの商品名がそれぞれ「カレー」「ハヤシ」「null」の3データがあったとして
|
|
134
|
+
|
|
135
|
+
商品名 <> 'カレー'
|
|
136
|
+
|
|
137
|
+
とWHERE句に指定すると結果は「ハヤシ」の1行しか返ってきません。
|
|
138
|
+
|
|
139
|
+
これはnullとの比較結果がunknownになっていてtrueではないためです
|
|
140
|
+
|
|
141
|
+
このようにまず考えることが増えます。
|
|
142
|
+
|
|
143
|
+
|
|
144
|
+
|
|
145
|
+
またnullと算術計算した結果はnullになってしまいます（nullは伝染する）
|
|
146
|
+
|
|
147
|
+
|
|
148
|
+
|
|
149
|
+
ソートにも問題があり、nullが最小値と判断されるか最大値と判断されるかはDBソフトにより異なります
|
|
150
|
+
|
|
151
|
+
DBソフトのリプレースをするときに発火するかもしれないです
|
|
152
|
+
|
|
153
|
+
|
|
154
|
+
|
|
155
|
+
プログラム側にも影響があります
|
|
156
|
+
|
|
157
|
+
null許容型の列から出てきた値は常にnullかもしれないと考えて処理しなければいけませんし、
|
|
158
|
+
|
|
159
|
+
INSERT時にバグで値が渡されていない列があった場合を考えるとnull許容でなければ少なくともSQLエラーでミスは発覚しますがnull許容だとそのまま動き続けてしまいます
|
|
160
|
+
|
|
161
|
+
（しっかりテストすればいい説もありますが現実にはいろいろと…）
|
|
162
|
+
|
|
163
|
+
|
|
164
|
+
|
|
165
|
+
等々、いろいろな理由でnullが入るのは忌避される傾向があります（のはずです）
|
|
166
|
+
|
|
167
|
+
なので私は備考などもなかったとしてもnullではなく空白文字を入れておくようにしていますし、マスタからの選択の場合も「0:未定」のようなものを入れておくようにしています。
|
|
168
|
+
|
|
169
|
+
|
|
170
|
+
|
|
171
|
+
ネット上にもいろいろな文献があるので
|
|
172
|
+
|
|
173
|
+
「RDBMS null」「3値論理」などで検索してみるといろいろ出てくると思います。
|
|
174
|
+
|
|
175
|
+
|
|
176
|
+
|
|
177
|
+
もちろんnullは完全になくせ！ とは主張しません。
|
|
178
|
+
|
|
179
|
+
必要な場合もあります。 「完了日」などを作るなら完了するまではそれはnullだと思います。
|
|
180
|
+
|
|
181
|
+
これは「未知」のnullです。
|
|
182
|
+
|
|
183
|
+
調べてみると出てくると思いますがnullには「未知」と「適用不能」の２種があり、「適用不能」のnullが多いテーブルは1つのテーブルにまとめるべきでないものをまとめていないか？
|
|
184
|
+
|
|
185
|
+
と考えますね。
|
2
正規の回答を記入
test
CHANGED
|
@@ -1,9 +1,115 @@
|
|
|
1
|
+
誤操作でバタバタしてしまい申し訳ございません、あらためて回答をさせていただきます
|
|
2
|
+
|
|
3
|
+
|
|
4
|
+
|
|
1
5
|
ExcelをDB化するのは柔軟な検索、集計がやりやすいというメリットがあります
|
|
2
6
|
|
|
3
|
-
（Excelを「DB化」とは言わない）
|
|
7
|
+
（そもそもExcelを「DB化」とは言わない）
|
|
4
8
|
|
|
5
9
|
社内ローカルのWeb業務システムは無数に稼働してますし普通だと思いますよ。
|
|
6
10
|
|
|
11
|
+
他にもマスタとデータを分けたりリレーションで情報を取ってくることにより情報の重複を防げたりするのでその辺も踏まえて自分なりにざっと見てみました
|
|
7
12
|
|
|
8
13
|
|
|
14
|
+
|
|
15
|
+
ただし、要件を全て把握してるわけではないのと、
|
|
16
|
+
|
|
17
|
+
自分だったらこうするというだけで宗教的思想も大いに混じっていますのでいろいろな意見を取り入れるのがいいと思います
|
|
18
|
+
|
|
19
|
+
|
|
20
|
+
|
|
21
|
+
**カラム名について**
|
|
22
|
+
|
|
23
|
+
質問本文にもあるテーブル名が含まれている件
|
|
24
|
+
|
|
25
|
+
これについては例えば備考なら「remark」だけでいいと思います
|
|
26
|
+
|
|
27
|
+
clientsテーブルにあるremarkカラムなら顧客についての備考と明白なためです
|
|
28
|
+
|
|
29
|
+
同様に「client_id」「client_name」なども「id」「name」でいいのではないでしょうか
|
|
30
|
+
|
|
31
|
+
一方「qty」「attn」などはわかりにくいので略さない方がいいと思います。
|
|
32
|
+
|
|
33
|
+
また、日付系が「～_at」という名前にされていますが文章じみた名称になってるのが気になるので、自分なら「～_date」（日付までの場合）、「～_datetime」（時分秒まである場合）にします。
|
|
34
|
+
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+
**見積書テーブルの「バージョン情報」**
|
|
38
|
+
|
|
39
|
+
↑の質問回答に「項目としてある以上は」となっているということは、元となるExcelにあった情報ということでしょうか？
|
|
40
|
+
|
|
41
|
+
個人的には（これだけの情報なら）不要かなと思いました。
|
|
42
|
+
|
|
43
|
+
検索時に「最新のモノを選ぶ」というひと手間が余計にかかりますし
|
|
44
|
+
|
|
45
|
+
契約文書等なら過去バージョンを残していくのもいいですが、自分がこのシステムを作るなら、更新時にいつだれがどこを変えた、というのを残すログテーブルを追加すると思います
|
|
46
|
+
|
|
47
|
+
|
|
48
|
+
|
|
49
|
+
**見積書テーブルの「更新日時」**
|
|
50
|
+
|
|
51
|
+
自分であればここは最初は登録日時と同じ値を入れておきます。
|
|
52
|
+
|
|
53
|
+
個人的にnull許容の列はできるだけ作りたくないというのがあるので……
|
|
54
|
+
|
|
55
|
+
|
|
56
|
+
|
|
57
|
+
**見積書詳細テーブルの「商品名」「商品詳細」**
|
|
58
|
+
|
|
59
|
+
これは商品マスターテーブルを作成してそこへの外部キーで対応した方がいいのではないでしょうか？
|
|
60
|
+
|
|
61
|
+
|
|
62
|
+
|
|
63
|
+
**見積書詳細テーブルの「納期」**
|
|
64
|
+
|
|
65
|
+
テキストによるこの持ち方だと、例えば「納期が迫ってるけど未納状態のモノ」などの検索機能を作るときにやりづらいので、日付型にして明記しておいた方がいいのかな？ と考えます
|
|
66
|
+
|
|
67
|
+
|
|
68
|
+
|
|
69
|
+
**見積書テーブルの「小計金額」**
|
|
70
|
+
|
|
71
|
+
これは仕様によって悩むところではあるんですが……
|
|
72
|
+
|
|
73
|
+
ここにこの情報があると、見積書詳細テーブル側にある売上単価が変わった時にこちらも再計算して更新しなければなりません。何かのミスで片方が更新されなかった場合などにトラブルを生みます。ので、可能であればこのテーブルから情報は無くし、見積書詳細テーブルから計算して出力した方がいいと思います。
|
|
74
|
+
|
|
75
|
+
|
|
76
|
+
|
|
77
|
+
**見積書テーブルの画像データなど**
|
|
78
|
+
|
|
79
|
+
没案の方に書かれていますが、これは別テーブルにして保持すれば見積書テーブルそのものは重くならずに、また複数のファイルを添付情報にすることも可能になります。
|
|
80
|
+
|
|
81
|
+
|
|
82
|
+
|
|
83
|
+
**ユーザーテーブル**
|
|
84
|
+
|
|
85
|
+
他の方も言われていますが、ActiveDirectory環境があるならユーザ情報はそちらとの連携を検討するのもいいと思います。
|
|
86
|
+
|
|
87
|
+
またそういった環境がなくとも社員番号のような一意の情報が各ユーザにあるならそれをIDにするのがいいと思います（苗字をIDにすると苗字被り、イニシャル被りでどんどんグダっていく）
|
|
88
|
+
|
|
89
|
+
|
|
90
|
+
|
|
91
|
+
**見積書テーブルの主キー**
|
|
92
|
+
|
|
93
|
+
文字列で定義されていますが、これは運用に従い増えていくものなので、自分であればオートインクリメントの数値型にするかなといったところです。
|
|
94
|
+
|
|
95
|
+
|
|
96
|
+
|
|
97
|
+
**見積書詳細テーブルの主キー**
|
|
98
|
+
|
|
99
|
+
これも同様にオートインクリメントの数値型カラムを作ってそれを主キーにし、見積書IDを外部キーとして使用します。
|
|
100
|
+
|
|
101
|
+
|
|
102
|
+
|
|
103
|
+
**ユーザーテーブル、顧客テーブルに「有効フラグ」列**
|
|
104
|
+
|
|
105
|
+
ユーザーが退社したためそのIDではログインさせたくない、ある顧客との付き合いがなくなったため選択肢に出したくない、などの時に、ユーザーテーブルや顧客テーブルなどのマスタテーブルから情報を消してしまうと、見積書テーブルなどのデータテーブルの外部キーから情報を引っ張ってこれなくなくなってしまいます。
|
|
106
|
+
|
|
107
|
+
なのでマスタ系のテーブルには「有効」「無効」を表すカラムを追加してtrueかfalseかで切り分けるようにするのがいいと思います。（いわゆる論理削除。商品マスタを作成するのであればそれにも）
|
|
108
|
+
|
|
109
|
+
|
|
110
|
+
|
|
111
|
+
|
|
112
|
+
|
|
9
|
-
|
|
113
|
+
ざっと見た感じですが、自分の好みに合わせるとしたらとりあえずこんな感じでしょうか？
|
|
114
|
+
|
|
115
|
+
もちろんこれは「今ある情報から見える自分が好きなやり方」なので環境上、また運用上そうは出来ないこともあると思いますし、他の方が見れば他にも多々案があると思います。
|
1
追記予定
test
CHANGED
|
@@ -3,3 +3,7 @@
|
|
|
3
3
|
（Excelを「DB化」とは言わない）
|
|
4
4
|
|
|
5
5
|
社内ローカルのWeb業務システムは無数に稼働してますし普通だと思いますよ。
|
|
6
|
+
|
|
7
|
+
|
|
8
|
+
|
|
9
|
+
※下書きしておくつもりが間違えて書き込みタッチしてしまったので後でこれに追記します すいません
|