質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
データベース

データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

Q&A

解決済

4回答

1365閲覧

[DB設計]会社名、ユーザーごとか、ユーザー共通か

kou0179

総合スコア304

データベース

データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

0グッド

0クリップ

投稿2019/03/16 11:34

編集2019/03/16 12:25

ご挨拶・経緯

閲覧ありがとうございます。
現在、社内ではなく公開サービスとして、自身の営業履歴を残せるシステム(ではないですが近い物)を開発しております。
まだDB設計の段階ですが、悩む点があり、また私は経験がとても浅いので、ご経験等踏まえご回答頂けると幸いです。

検討事項

ユーザーの行った営業について、会社名を入力する項目を作りたいのですが、

会社テーブルを全ユーザー共通(例A)にするか、ユーザーごと(例B)にするかで悩んでおります。
尚、例Aと例Bは、意味としてはまったく同じデータベースです。

要求定義

設計にあたって必要そうな要求定義は下記です。

  • ユーザーは営業履歴をフォームに入力する際に会社名を一覧から検索,選択し、該当が無ければ自身で会社名(営業先)を新規登録をします
  • 1つの営業先について営業に行った事のユーザーを一覧する機能は無く、将来的にもあり得ません

(i.e. ある1つの営業先について、ユーザーが異なれば表記が異なっても問題無い)

  • 1人のユーザーについて、1つ営業先から過去の営業一覧を取得する機能は必要です

(i.e. 1人のユーザーにおいては、ある1つの営業先について常に同じ名前を設定しなければならない)

例A

users

idname
1山田
2斎藤
3鈴木

sales
|id|user_id|company_id|comment|
|:--|:--:|--:|
|1|1 (山田)|1 (株式会社あいうえお)|絶好調でした|
|2|3 (鈴木)|1 (株式会社あいうえお)|断られました もう一回行ってきます|
|3|2 (斎藤)|2 (ほげぴよ株式会社)|後日連絡が来るそうです|
|4|3 (鈴木)|1 (株式会社あいうえお)|OKでした!!|

company

idname
1株式会社あいうえお
2ほげぴよ株式会社

例Aは会社表記が統一されますが、全ての会社の表記を一定にする措置が必要です。ユーザーが退会時にデータを削除する必要が無く、その会社レコードを将来的に再利用できます。

例B

users

idname
1山田
2斎藤
3鈴木

sales
|id|user_id|company_id|comment|
|:--|:--:|--:|
|1|1 (山田)|1 (株式会社あいうえお)|絶好調でした|
|2|3 (鈴木)|2 ((株)あいうえお)|断られました もう一回行ってきます|
|3|2 (斎藤)|3 (ほげぴよ株式会社)|後日連絡が来るそうです|
|4|3 (鈴木)|2 ((株)あいうえお)|OKでした!!|

company

iduser_idname
11株式会社あいうえお
23(株)あいうえお
32ほげぴよ株式会社

例Bは、ユーザーごとに表記のぶれがあっても問題なく(自分さえわかれば問題ない)、また検索も自身が実際に行った事のある会社(営業先)しか出てこないので簡単です。

最後に

自身で考えているサービスなので、そもそも要求仕様、ここが変だよ、とか様々な角度からの突っ込み、アドバイス、ご教授をよろしくお願いいたします。

追記

ご回答ありがとうございます。少し質問文が分かりにくかったようで申し訳ございません。
サービスは営業管理システムというよりかは、会社としての営業活動に関係ない、個人個人の営業日記のようなものを想定しています。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答4

0

ベストアンサー

会社テーブルを全ユーザー共通(例A)にするか、ユーザーごと(例B)にするかで悩んでおります。

サービスの内容が、ユーザーが営業行為の情報を記録するというなら、ユーザー毎でしょうね。
ただ、さらに引用できるような共通の情報があれば利便性は高まります。

共通の情報として、法人番号情報を活用しては如何ですか?
法人番号は法人にとってのマイナンバーであり、国税庁が管理しています。
データのダウンロードも可能です。
国税庁法人番号公表サイト

小規模な会社は登録されていなかったりしますが、結構な数のデータです。

また、ユーザーの管理ついては、Kosuke_Shibuyaさんも回答されているように、
営業情報を活用したいグループでの申し込みなども考慮されていた方が良いと思います。

投稿2019/03/16 12:17

sazi

総合スコア25138

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kou0179

2019/03/16 12:28

ご回答ありがとうございます。 ユーザーが営業行為の情報を記録する>> その通りです。 また、お恥ずかしながら、国税庁よりこのようなものが公開されているのは知りませんでした。 そもそも >> ユーザーは営業履歴をフォームに入力する際に会社名を一覧から検索,選択し、該当が無ければ自身で会社名(営業先)を新規登録をします ではなく事前に全ての会社をインポートしておくのも無しでは無いかもしれません。(件数次第ですが。) ご回答ありがとうございました
sazi

2019/03/17 15:32 編集

国税庁のサイトでは検索も可能なので、インポートではなくてリンクしておき、検索結果の情報を取得するみたいな事でもいいんじゃないでしょうか。
guest

0

company テーブルなら、会社についてだけの情報を持つべきです。
つまり A 案です。

もし、B 案のようにするなら、次のような構造になると思います。

  • user: user_id, name
  • campany: company_id, campany_name
  • sale: sale_id, user_id, company_id, comment

実は列の構造は A 案と同じです。
違いは、 campany テーブルの制約です。

A 案では company_name は 全体でユニークにすることが必要です。

B 案では、その制限をしないようにします。
ユーザーが営業記録を登録する際は、
ユーザーのセール一覧から company_id, company_name の一覧を取り出してそれを一覧表示します。そのなかから会社を選択して営業記録を登録するようにします。

一覧に該当する会社がでてこない(初めてその会社へ営業した) 場合は、company テーブルに新規登録してから、その会社を選択して営業記録を登録するようにします。

投稿2019/03/17 02:22

katoy

総合スコア22324

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kou0179

2019/03/17 02:53

B案での実装を考えると最も無駄が無い設計ですね! 確かに言われてみればcompanyテーブルでuser_idを保持する理由は無かったです。 user_idで絞ったsalesにcompanyをJOINしてDISTINCTするのと、companyをuser_idで絞るのでは、結果は等価という事ですね。 パフォーマンス等検討した上で、参考にさせて頂きます!クローズ後なのにも関わらず、ご回答頂きありがとうございました!
katoy

2019/03/17 03:03

user_idで絞ったsalesにcompanyをJOINするのを view にしておくとよいかもしれません。
kou0179

2019/03/17 03:07

なるほど・・・複雑になりがちですがそれなら抽象的に扱えて便利ですね。勉強になります。ありがとうございます。
katoy

2019/03/17 07:41

DB 設計 (項目名だけでなく、制約 (null を許すとか、uniq 性とか) や index の張り方、テーブル間の関係 (一対一、一対多, 多対多)をきちんと行うことが必要です。(質問文の DB 構造説明ではその辺が明確でないです。したがって回答者はそれを想像していく必要があります。
guest

0

実体が同じものには同じIDを振るべきです。この点で案Bはダメだと思います。自分が分かればといいますが、たとえば後で同じ会社にアタックした全社員のリストがほしいとなったときにどうやって検索しますか?
私なら案Aを基本として、companyデータベースにはname_attributeのような項目を追加して正式名称・通称の区別を持たせるようにするかな。

投稿2019/03/16 12:01

KojiDoi

総合スコア13669

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kou0179

2019/03/16 12:21

>>たとえば後で同じ会社にアタックした全社員のリストがほしいとなったときにどうやって検索しますか? その可能性があればAが最良の選択になるのは間違いありません。ただ、要求仕様にあるように >> 1つの営業先について営業に行った事のユーザーを一覧する機能は無く、将来的にもあり得ません です。 サービスは営業管理システムというよりかは、会社としての営業活動に関係ない、個人個人の営業日記のようなものを想定しています。
guest

0

Aというう会社に所属している営業担当者間で営業対象会社のリストを共有する必要がないのでしょうか?
サンプルデータ(例えば「断られました もう一回行ってきます」)を見る限り、その視点が反映されていない気がする。

公開サービスにするのであれば、「対象リスト」としての会社ではなく、「営業担当者」に「所属会社ID」を持たせ、「所属会社」テーブルも必要でしょう。

投稿2019/03/16 11:40

編集2019/03/16 11:42
退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kou0179

2019/03/16 12:19

質問が分かりにくくて申し訳ございません。 サービスは営業管理システムというよりかは、会社としての営業活動に関係ない、個人個人の営業日記のようなものを想定しています。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問