DB初心者です。
会社で書類作成するシステム開発にあたり、DB設計をする事になりました。
しかし、使用するデータの量が多くどのように構築すればいいか悩んでいます。
具体的には
1:テーブル名、カラム名が長くなってしまう。
名前は略語、日本語などは使用しない方が良い、パッと名前を見てデータの意味がわかるほうが良いとの記事を読んだのですが、専門用語などを翻訳すると単語が3,4以上になる場合が多く、本当に良いのか?など不安です。
2:カラム数が500個程になってしまうテーブル or 項目毎に分けたテーブル30個。
正規化をしてテーブルを分けようと試みたのですが、繰り返し使うデータはほぼ無く、あっても「書類タイプ」などのものしかありません。
システムでは項目毎に作成したり表示したりするので、このような場合は1対1の構造になるが、項目別でテーブルを作った方が良いのか?など考えましたが、「出来るだけ単純に構築したほうが良い」との記事も読み、どうすれば良いかわからない状態です。
3:多対多の構造について。
テーブルA、テーブルBの多対多の中間テーブルZを使うにあたって、AはZを経由しないとBを保持しているかわからない。
Zを検索するなら、A自体に「has_b」というカラムをもたせた方が、保持していない場合はわざわざZを見に行く必要性が無くなり良いのでは無いか?
また、初めてAテーブルを見た人も中間テーブルの存在がわかりやすいのではないのでしょうか?
宜しくお願い致します。
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
回答6件
0
ベストアンサー
使用するデータの量が多くどのように構築すればいいか
社内システムとはいえ、初心者が大容量のDB設計をいきなりするのは、ちょっと酷な話ですね。
依頼者は「とりあえず、動けば良い」という気持ちなのかも知れませんが。。
なんとなく、1・2・3を解決して設計しても、後手後手になりそうな気がするので、
そうならないための情報を少し。
-- DB設計の前に~その1~
DB設計ではなく、システム全体の仕様を先に確定する必要があります。
要望があっても「できる」「できない」「難しい」「簡単」etc..の振分も大変かと思いますが、
初心者なので、挑戦するにしても2・3個程度に留めておいた方が良いと思う。
同じような要望も1つを挑戦して、それができてから、他の要望にも着手した方が良いかと。
・・・という感じで、開発するにもステップを踏むことをお勧めします。
-- DB設計の前に~その2~
次にやるのは画面設計(イメージ)と操作設計と帳票設計(イメージ)です。
全画面全帳票の1つ1つの項目に対して、「必須にするか・任意にするか」「何桁にするか」「どのタイミングでどうやって作成・更新・削除するか」etc..を考えます。
-- DB設計
画面設計(イメージ)と操作設計と帳票設計(イメージ)を見て、
これらのデータを抽出するためのテーブルを作ります。
テーブルの各項目を何の型にして、何桁にして・・・という設計はほとんど終わっているはず。
そのため、500項目くらいになっても、問題ありませんが、以下の点に気を付けてみてください。
-- DB設計注意点~その1~
テーブルのレコードが
「いつ登録されるのか」「いつデータが更新されるのか」「いつ削除されるのか」等を意識します。
500項目全ての登録タイミング、更新タイミング、削除タイミングが異なっていたら、
SQLもそれだけ作らなければならない。
大変ですので、分けましょう。
(画面設計の時点でも意識してください)
-- DB設計注意点~その2~
テーブルの各項目が「更新型」なのか「履歴型」なのか意識してみてください。
このタイプの項目は同じテーブルには通常含めませんので、別テーブルで管理する必要が有ります。
(画面設計の時点でも意識してください)
-- その他
遠回りかもしれませんが、頭の中でSQLを作れるようになるまで、SQLに触れた方がよいかも。
頭の中でSQLを作れれば、画面設計しながら、頭の中でSQLを動かせるので、設計も早くなります。
1人で限界を感じるのであれば、納得いく人と出会うまで外注したり教えてもらうのもアリかと。
ちなみに、『設計の部分で悩んでいます。』とあるのに、『設計』とは違うところで
悩んでるようだったので、1・2・3ではなく上記のような回答をしました。
投稿2016/08/27 20:32
総合スコア760
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2016/08/31 08:14
2016/08/31 17:03
2016/09/01 00:35
0
テーブル設計はテーブルが50以上あったらERツールを使った方が良いです。
正規化 は理解されているでしょうか?
パフォーマンスチューニングで呼ばれて調査すると、正規化がめちゃくちゃでシステムのほとんどが使い物にならず、テーブル設計からやり直さないとほとんど対応できないお客様も何度か。テーブル設計から作り直すとデータの移行も必要になり、下手すると新規にシステムを作るより費用がかさみ現行のままになったことも。
投稿2016/08/26 08:46
編集2016/08/26 11:26総合スコア16415
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2016/08/26 09:57
2016/08/28 04:57
2016/08/29 00:24
0
1:テーブル名、カラム名が長くなってしまう。
テーブル名にもカラム名にもコメントが付けられますので
わかりやすく日本語のコメントをつければ問題ないでしょう。
それに翻訳する必要はなく単にローマ字でもいいんですよ
2:カラム数が500個程になってしまうテーブル or 項目毎に分けたテーブル30個。
正規化は分けることが目的ではありません
なんでもかんでも分ければ集計がしやすくなったり高速になるわけではないのです。
どういう結果を抽出、集計したいか設計段階で検討し
それにあわせて正規化していくのがただしいでしょう。
したがってカラムが大量にあってもかまわないと思います。
逆に項目自体がほとんどNULLだらけになるようなものであれば
詳細用のテーブルに別途まとめてしまうと管理も楽になると思います
3:多対多の構造について。
なんとも言えないです。
単にリレーションで処理できるかもしれないしサブクエリが必要かもしれない、
ビューを作れば済む話かもしれない
投稿2016/08/26 07:36
総合スコア114505
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2016/08/26 08:18
0
他の回答者様と同じく、
先ずはシステム要件を詰めることかと思います。
時間に余裕があれば、
ヒアリングとかも実施すると良いかもせん。
項目数が多くなるとあるのですが、
本当にその項目をDBに保存する必要があるのか再検討した方が良いかもしれません。
実は何かの表現の言い換えに過ぎず、
本質的には1つに纏まるものであればカラムをあえて分ける必要はなくなる訳ですし、
状況を聞くと要件レベルでまた詰めきれていないのかなと思う訳です。
###テーブル名、カラム名が長くなってしまう
他の回答者様もおっしゃっている通り、ローマ字や場合によって略称で問題です。略称の方が親しみやすいケースではむしろ略称を採用する方がよいケースあるかとしれません、下記は一例です。
例:到着予定時刻
フルスペル → EstimatedTimeOfArrival
略称 → ETA
ただいずれローマ字、略称だと意味が伝わらないという心配は当然あるので、コメント付だけはしっかり行うのが望ましいかと思います。
###カラム数が500個程になってしまうテーブル or 項目毎に分けたテーブル30個
カラムが500個を超えてくると結構しんどいかなというのが僕の意見です。
今はExcelも2007以降で「xlsx」が大分主流となってますが、
「xls」だと列数上限が256個までだったはずなので、
カラム数が256を超えてExcelに貼り付けた際に切り捨てられるようになると、
テスト時にストレスがかかること間違いなしです^^;
考えような所はありますが、
意味のある項目群ごとにはテーブルを作っておいて、
検索時には各テーブルを意識せず検索できるようビューを用いるというアプローチもありかなと思います。
(上記アプローチの場合、INSERT、UPDATE、DELETE時のテーブル更新漏れは怖いので、パッケージやストアドで各種一連処理を実装することを強くお勧めしますが)
###多対多の構造について
質問者さんのいうようなリレーション自体の属性持ちですが、
要件によっては有りかと思います。
それこそAテーブルの検索のみに留まる機会が多いとかの場合だと、
毎回リレーションテーブルとくっつけるのも無駄という考えからそのテーブルに属性として導出することはありなと思います。
ただ1点気をつけないとないといけないのが、
属性として導出したということは、
つまり事実を2重で管理することに他ならないので、
整合性が取れないという自体に陥らないよう十分注意する必要は出てきます。
ただ他の人がAテーブルだけ見て、
Bテーブルの存在を一目で分かるという意味での列追加ということでしたが、
その場合はそもそもER図さえしっかり用意すればそのあたりの心配は大抵は無用になると思います。
(ドキュメントを読まない開発者は知らんけど)
###テーブル分割の考え方について
テーブルの分割を行うケースですが、正規化(多:多、1:多)以外にも共通項目の導出などでも発生するということがあることは理解すると良いかもしれません。
例えば様々な書類がある中でも、
それぞれよ書類には共通する項目もいくつか存在する時です。
この場合は以下のイメージで導出テーブルを作成することもあります。
スーパタイプ:書類共通テーブル
サブタイプ:A書類テーブル、B書類テーブル、C書類テーブル
上記のようにすると、
以下のメリットが享受できます。
- 各種書類の共通属性は書類共通テーブル内で管理可能
- 各種書類の合計レコード数の総和 = 書類共通のレコード数となるので書類全体の作成数を書類共通より把握できる
投稿2016/08/28 04:37
総合スコア1636
0
他の方もおっしゃっているように、DB設計ありきではなく
DBを含めたシステム設計をまず形にするのが先じゃないかなあ。
そして、そのためのプロトタイピングですよ、と。
試作品を作って評価するってやつですね。
まあ、それにかけられる人手も時間もないかもしれませんが、
少なくとも紙の上でシミュレーションくらいやっておけば
多少なりとも方向性は見いだせると思います。
投稿2016/08/27 22:13
総合スコア7458
0
1:テーブル名、カラム名が長くなってしまう。
いいんじゃないでしょうか。
具体的にどのようなテーブル名を付けようとされているのかにもよりますが。
「the_ticket_for_reserver_with_prize_item」とかの文節表現になっていると改善の余地がありそうですが。
具体例の提示をいただけませんか。
2:カラム数が500個程になってしまうテーブル or 項目毎に分けたテーブル30個。
抽象的すぎて何とも言えませんが、カラム数が500と言うのは設計がおかしいのではないでしょうか。
こちらも具体例の提示が欲しいところです。
3:多対多の構造について。
コレも具体例がないと状況次第の回答となります。
が、ごく一般的な状況で考える場合、個人的にはtable Aに[has_b]を付けるというのはナンセンスだと思います。
仮に[has_b]がfalseなのに、関連するtable Zが存在する事態に陥った場合、システムがどういう挙動になるか即答できますか。
正規化はすればするほどいいわけではなく、適切な粒度が存在するモノですので。
中間テーブルを使うのが必ず正解と言うわけではありません。
絶対的な正解と言うのは難しいので、結局実例がなければゴニョゴニョとしか言えませんね。。
投稿2016/08/26 07:24
総合スコア5405
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2016/08/26 08:00
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。