Q&A
家に帰ったら（書くことが残っていたら）なにかしら書きますが、この手のは要件によっても変わりますし宗教レベルの話もあるので「これ」といった答えは難しいですね。
見積書テーブルの「バージョン情報」は更新時に第何版かを書き換えるだけで、過去バージョンを保持していくわけではないという仕様でいいでしょうか？
コンセプト：
・見積作業を簡潔に
・見積内容のDB化
見積書システム機能：
Python,Djangoを使った見積書登録Webアプリ
・ユーザーの登録
・ログイン
・ログインユーザーでの見積書の登録、参照（一覧と詳細）、更新、削除
→見積書には載せない項目も含めています
・顧客情報の登録、参照、更新、削除
・見積書をexcelとして出力
・DBバックアップ機能
（のちの発展では・・・）
・見積機能に付随して仕入見積依頼、受注、売上処理など 受発注システムの統合、一元化
・画像ファイルなどのバイナリファイルアップロード機能
・ログインユーザーによる承認機能
RDBMS：PostgreSQL
現状の不明点：
・備考の項目が見積書テーブルと顧客テーブルにそれぞれ用意しており、それぞれ異なる備考項目を設定している。
カラム名にテーブル名が含まれているのはよくないとの見解もあるが、それぞれのカラムの役割を明確にするため必要なのでは？
テーブル設計を始めて行ってみましたが、経験豊富な方の意見を頂きたく存じます。
・正規化ほか設計のなんたるかがわかっていない！
・命名がなっていない!
・ER図すら書けていない!
・保守性、発展性、わかりやすさ、パフォーマンス の向上のために設計はこうしたほうがいい！
などご指摘を頂けますと幸いです。
ありがとうございます！
まずはユーザーによって機能のカスタムしやすい基本的な機能を と考えていました。
〇見積書テーブルの「バージョン情報」は更新時に第何版かを書き換えるだけで、過去バージョンを保持していくわけではないという仕様でいいでしょうか？
→そこまで頭が回っていませんでしたが、項目としてある以上は、見積書テーブルの「バージョン情報」は、ほかの項目も過去バージョンと一緒に保持していったほうが良いですね（見積書のどこをどう変更しているかが解る）
その場合はバージョン情報も複合主キーとする必要がありそうですね。
初期には実装しなくても、後々には実装しやすい状態が望ましいです。
回答3件
0
＃長文過ぎて他の回答は確認せずに回答してますので、重複するような部分があると思いますのでご容赦
ぱっと見で、質問にあるテーブルはまだまだこなれていない印象です。
例えば、
見積書テーブル：
顧客とユーザーの組み合わせが一意キーになっているが、それでは、同じ組み合わせでの別な見積もりが登録できない。
見積詳細テーブル：
納期は見積書テーブルにあるべきだと思う。
なので、もっと精度を上げるべきです。
方法としては、実際に使用された見積書のサンプルを入手して、そのデータを設計したテーブルに落とし込み精査する事を繰り返すと良いと思います。
サンプルからイレギュラーなケースを見つけ出す事が出来る程度に数をこなした方がいいでしょうね。
投稿2020/07/15 01:17
総合スコア25327
貴重なご意見いただき、ありがとうございます!
「サンプルからイレギュラーなケースを見つけ出す」とのご意見は大変参考になりました。
想定しにくい使われ方に ユーザーに則した設計の醍醐味があるように思います。
要件に必要な設計を改めて精査してみます!
0
ベストアンサー
誤操作でバタバタしてしまい申し訳ございません、あらためて回答をさせていただきます
ExcelをDB化するのは柔軟な検索、集計がやりやすいというメリットがあります
（そもそもExcelを「DB化」とは言わない）
社内ローカルのWeb業務システムは無数に稼働してますし普通だと思いますよ。
他にもマスタとデータを分けたりリレーションで情報を取ってくることにより情報の重複を防げたりするのでその辺も踏まえて自分なりにざっと見てみました
ただし、要件を全て把握してるわけではないのと、
自分だったらこうするというだけで宗教的思想も大いに混じっていますのでいろいろな意見を取り入れるのがいいと思います
カラム名について
質問本文にもあるテーブル名が含まれている件
これについては例えば備考なら「remark」だけでいいと思います
clientsテーブルにあるremarkカラムなら顧客についての備考と明白なためです
同様に「client_id」「client_name」なども「id」「name」でいいのではないでしょうか
一方「qty」「attn」などはわかりにくいので略さない方がいいと思います。
また、日付系が「～_at」という名前にされていますが文章じみた名称になってるのが気になるので、自分なら「～_date」（日付までの場合）、「～_datetime」（時分秒まである場合）にします。
見積書テーブルの「バージョン情報」
↑の質問回答に「項目としてある以上は」となっているということは、元となるExcelにあった情報ということでしょうか？
個人的には（これだけの情報なら）不要かなと思いました。
検索時に「最新のモノを選ぶ」というひと手間が余計にかかりますし
契約文書等なら過去バージョンを残していくのもいいですが、自分がこのシステムを作るなら、更新時にいつだれがどこを変えた、というのを残すログテーブルを追加すると思います
見積書テーブルの「更新日時」
自分であればここは最初は登録日時と同じ値を入れておきます。
個人的にnull許容の列はできるだけ作りたくないというのがあるので……
見積書詳細テーブルの「商品名」「商品詳細」
これは商品マスターテーブルを作成してそこへの外部キーで対応した方がいいのではないでしょうか？
見積書詳細テーブルの「納期」
テキストによるこの持ち方だと、例えば「納期が迫ってるけど未納状態のモノ」などの検索機能を作るときにやりづらいので、日付型にして明記しておいた方がいいのかな？ と考えます
見積書テーブルの「小計金額」
これは仕様によって悩むところではあるんですが……
ここにこの情報があると、見積書詳細テーブル側にある売上単価が変わった時にこちらも再計算して更新しなければなりません。何かのミスで片方が更新されなかった場合などにトラブルを生みます。ので、可能であればこのテーブルから情報は無くし、見積書詳細テーブルから計算して出力した方がいいと思います。
見積書テーブルの画像データなど
没案の方に書かれていますが、これは別テーブルにして保持すれば見積書テーブルそのものは重くならずに、また複数のファイルを添付情報にすることも可能になります。
ユーザーテーブル
他の方も言われていますが、ActiveDirectory環境があるならユーザ情報はそちらとの連携を検討するのもいいと思います。
またそういった環境がなくとも社員番号のような一意の情報が各ユーザにあるならそれをIDにするのがいいと思います（苗字をIDにすると苗字被り、イニシャル被りでどんどんグダっていく）
見積書テーブルの主キー
文字列で定義されていますが、これは運用に従い増えていくものなので、自分であればオートインクリメントの数値型にするかなといったところです。
見積書詳細テーブルの主キー
これも同様にオートインクリメントの数値型カラムを作ってそれを主キーにし、見積書IDを外部キーとして使用します。
ユーザーテーブル、顧客テーブルに「有効フラグ」列
ユーザーが退社したためそのIDではログインさせたくない、ある顧客との付き合いがなくなったため選択肢に出したくない、などの時に、ユーザーテーブルや顧客テーブルなどのマスタテーブルから情報を消してしまうと、見積書テーブルなどのデータテーブルの外部キーから情報を引っ張ってこれなくなくなってしまいます。
なのでマスタ系のテーブルには「有効」「無効」を表すカラムを追加してtrueかfalseかで切り分けるようにするのがいいと思います。（いわゆる論理削除。商品マスタを作成するのであればそれにも）
ざっと見た感じですが、自分の好みに合わせるとしたらとりあえずこんな感じでしょうか？
もちろんこれは「今ある情報から見える自分が好きなやり方」なので環境上、また運用上そうは出来ないこともあると思いますし、他の方が見れば他にも多々案があると思います。
（追記 null許容云々について）
nullはいろいろと複雑さをDBに持ち込みます。
有名なのは3値論理問題ですが SQLの真偽値はtrue、falseの他にunknownという値が存在します。
これはnullが絡んだときに出てきます。
例えば見積書詳細テーブルの商品名がそれぞれ「カレー」「ハヤシ」「null」の3データがあったとして
商品名 <> 'カレー'
とWHERE句に指定すると結果は「ハヤシ」の1行しか返ってきません。
これはnullとの比較結果がunknownになっていてtrueではないためです
このようにまず考えることが増えます。
またnullと算術計算した結果はnullになってしまいます（nullは伝染する）
ソートにも問題があり、nullが最小値と判断されるか最大値と判断されるかはDBソフトにより異なります
DBソフトのリプレースをするときに発火するかもしれないです
プログラム側にも影響があります
null許容型の列から出てきた値は常にnullかもしれないと考えて処理しなければいけませんし、
INSERT時にバグで値が渡されていない列があった場合を考えるとnull許容でなければ少なくともSQLエラーでミスは発覚しますがnull許容だとそのまま動き続けてしまいます
（しっかりテストすればいい説もありますが現実にはいろいろと…）
等々、いろいろな理由でnullが入るのは忌避される傾向があります（のはずです）
なので私は備考などもなかったとしてもnullではなく空白文字を入れておくようにしていますし、マスタからの選択の場合も「0:未定」のようなものを入れておくようにしています。
ネット上にもいろいろな文献があるので
「RDBMS null」「3値論理」などで検索してみるといろいろ出てくると思います。
もちろんnullは完全になくせ！ とは主張しません。
必要な場合もあります。 「完了日」などを作るなら完了するまではそれはnullだと思います。
これは「未知」のnullです。
調べてみると出てくると思いますがnullには「未知」と「適用不能」の２種があり、「適用不能」のnullが多いテーブルは1つのテーブルにまとめるべきでないものをまとめていないか？
と考えますね。
投稿2020/07/14 04:41
編集2020/07/15 00:05総合スコア610
とても丁寧にご意見を頂き、ありがとうございます!
ご意見を頂いて"「有効フラグ」"のご意見など 「確かにその通りだ！」 と思うところが殆どで、大変参考になります。
お手数ですが、どうしても一点だけ頂いたご意見の中で質問させていただきたく、よろしいでしょうか。
見積書テーブルの「更新日時」のご意見のなかで『null許容の列はできるだけ作りたくない』とのご意見を頂いた内容に関しまして、
提示させていただいた設計では『この項目はまだ未定なんだよな・・後で更新するから！』 のようなユーザー意向もあるのかな？と思い
主キーを除き、項目に関してはnullを許容する内容にしようかと思っていました。（NOT NULL 制約をつけない）
頂いたご意見の中で『なにかデータ活用する際に、肝心の項目の大半がnullではダメじゃないか』など理由や意図をご教示お願いします！
nullまわりについての自分の考えを追記しました。
nullのご説明もとても丁寧にお答えいただき、ありがとうございました！
nullの問題は調べれば調べるほど難しい問題ですね・・・
特に算術計算の際にnullが伝染する件は、本システムにおいて重大な問題でした。
（最低限、計算にかかわる数値型の部分はNot nullで、デフォルト値を0にすべきかなと思います。）
参考とさせていただくなるほど！な内容が多く、新たな知見を得ることができたと思います。
ありがとうございました！
0
非推奨の質問に見えますが、アドバイスをとのことなのでアドバイスだけ。
user_idが主キーですが、もしログインIDとして使ったり、自動発番されないのなら、システムが自動的に割り当てる値を主キーにした方が拡張性が高いと思います。
また、E-R図を作る前に業務フロー図を作った方が良いと思うのですが、どうやってこのシステムを運用するか決まっていますか？
決まっていないなら前提が変わるのでE-R図云々の前にそちらを作成した方が良いです。
・見積作業を簡潔に
・見積内容のDB化
とあますが、どちらが優先ですか？
DB化ならExcelとかSpreadSheetで作っても良さそうです。
簡潔にならこれもExcelやSpreadSheetで作っても達成できそうです。
なぜWebアプリなのですか？
業務利用PC上で動くアプリを作った方がユーザの操作が簡単なのでは？
・ユーザーの登録
・ログイン
「見積もり」という話なので、勝手に会社だと思って書きますが、すでにAD等で管理されていませんか？
二重管理になると、整合性を担保したりするのが難しそうですが、誰がメンテナンスするのでしょうか？
とりあえず要求をまとめた方がよろしいかと思います。
投稿2020/07/14 02:11
総合スコア2424
ご意見いただき、ありがとうございます！
ご質問内容に関して、回答、補足説明します。
基本的にはローカルネットワークでの運用を想定しています。
本システムは、知人が会社を経営しており、Excelにて見積台帳、個別の見積書を作成したりと運用コストの高い業務方法でしたので、それに代わるシステムを作りたいと思っています。
過去の自分の営業経験をもとに、見積業務はこういったモノだろうとの想定をもとにしています。
使ってもらえるようであれば、システム導入までは私のほうで行い、問題発生や機能の拡充依頼が発生した場合に別途個別対応するつもりです。
〇
・見積作業を簡潔に
・見積内容のDB化
とあますが、どちらが優先ですか？
→どちらかというと「見積作業を簡潔に」がメインになります。
活用として、DBに貯まったデータを活用できるようになればいいな と考えています。
〇なぜWebアプリなのですか？
→Webアプリの利点として、下記を想定しています
・運用ではサーバー側の管理だけで済む
・UIで操作性、業務理解をコントロールしやすい （Excelなどの運用では事務業務が「細かいルールを覚えて、やってね」になりやすい。初めての人でも直観的に操作できるように）
・複数人の運用でもブラウザさえあれば、システムを利用できる（新規ユーザーの導入コストを抑えることができる）
（別の理由にはなりますが・・）
・Webアプリであれば、多少の理解が自分にある
・うまくできたら転職活動の際のポートフォリオとしたい
といった意図もあります。
〇「見積もり」という話なので、勝手に会社だと思って書きますが、すでにAD等で管理されていませんか？
→すでに管理されている内容はありますが、
既存の管理内容との二重管理はメリットがないものと思いますので、実際には既存の運用から移行してもらう前提です。
コメントを確認いたしましたが、ローカルネットワークでの運用であるならば、なおのことWebアプリである必要性がないですね。
元がExcelなら出力を「元のExcelに合わせて」と言った要件が発生する可能性があるので、Excelで作った方が要件にマッチする可能性があります。
(元がExcelならExcelは持っている->今後も継続して購入する)
VBAあたりで作った方がいいのではないでしょうか？
また、業務アプリなら使う環境を限定できるので、Windowsアプリ等を作成した方が運用が楽かもしれません。
> →Webアプリの利点として、下記を想定しています
欠点として以下が挙げられるのではないでしょうか？
> ・運用ではサーバー側の管理だけで済む
・Webサーバが必要(ローカル運用ならH/W購入が必要です)
・DBサーバが必要(ローカル運用ならH/W購入が必要です)
・サーバを管理/運用しなければならない
> ・UIで操作性、業務理解をコントロールしやすい （Excelなどの運用では事務業務が「細かいルールを覚えて、やってね」になりやすい。初めての人でも直観的に操作できるように）
・Webの場合、ブラウザによって表示が異なる可能性があるため混乱させる可能性があります。
・Webの運用にした場合も、「Webに合わせた運用方法の構築」が必要になります。
・初めての人でも直感的かどうかは、人によりますので結局のところ「操作マニュアル」は必須と考えられます。
> ・複数人の運用でもブラウザさえあれば、システムを利用できる（新規ユーザーの導入コストを抑えることができる）
・ブラウザによって動作が異なる可能性があります。
Edge/Chrome/Firefox全てに対応するのは面倒です。
・Webの場合は、セッション管理がやっかいな問題になるかもしれません。
> ・Webアプリであれば、多少の理解が自分にある
> ・うまくできたら転職活動の際のポートフォリオとしたい
この理由は理解できますが、これのせいで「Webありき」になっていませんか？
> →すでに管理されている内容はありますが、
> 既存の管理内容との二重管理はメリットがないものと思いますので、実際には既存の運用から移行してもらう前提です。
使ってもらうなら、元の管理のまま合わせ込めるようなものを作った方が簡単なのではないでしょうか？
すでに管理されているのに、新しいアプリの方で管理してねっていうのは乱暴なような？
ここまでネガティブなことしか書いていませんが、Webで作る場合は以下の利点もあります。
・どこからでもアクセスできる(普通のWebサイトと同じように公開すれば)
・Web側の処理をAPIのような形で実装した場合、GUI側は好きに作ってもらえる。(RESTを呼ぶ感じ)
・クラウドサービスのサーバが使える(サーバレスにできるかもしれません。)
・APIならAndroidやISOアプリに組み込みやすい
外に公開した場合はセキュリティが大問題ですが、結局のところ要件によるという話になります。
新たなご意見いただき、ありがとうございます!
確かにユーザーファーストの心構えが不足していたかもしれませんね
Web以外の別の選択肢も再考したいと思います。
あなたの回答
tips
プレビュー
