前回に引き続き論理設計のグレーノウハウについて。列持ちテーブルこれは下記のようなテーブルです。列持ちとはこのように子1~子3のようなテーブルを持つことですね。比較的よくやりますね。今の開発でもたまに使っています。メリットとデメリットを見ていこうと思います。見たまんまで非常にわかりやすいですね。正規化とかスカラを理解していなくてもOKです。入出力のフォーマットと合わせやすいシンプルさゆえに画面とロジック、データベースとの連携が非常に簡単です。CSVで出力するときもこのまま出力すればOKですし、SELECT文でだせばいいだけです。デメリット列の増減が難しいリレーショナルテーブルの欠点として後になってからの構成変更が難しいということです。列自体が不要になったり、増加させたい場合に変更コストが大きくなります。列持ちテーブルの欠点として、子がいない、子が少ない場合は無用のnullを使う必要が出てくるということです。nullが含まれているとSQL文の結果を混乱させるもとになります。特殊な状況でなければ別途行持ちテーブルを作るべきそのため使いどころによっては有用ですが、そうでなければなるべく下記のような行持ちテーブルにすべきです。)の人口を出したいという要件があったとします。740このときに地方コードとして新たに北海道・東北=01、関東=02、東海=03を取り入れるというような設計を見かけます。確かにこのような列を新たに追加すればSQLの集計が非常に楽になります。半面、こういったアドホック(場当たり的)な集計キーは名前の通り、短いスパンでコードが変わったり、別のコード体系が必要になったりします。このようなことを繰り返すとますますテーブルが巨大になり、パフォーマンスが落ちる原因になります。このようなアドホックな列を作る代わりの対策としては下記のようなものがあげられます。都道府県コードと地方コードだけをもったテーブルを別に作ることで、通常のテーブルよりも工数は小さくなります。結合処理が必要になるのでパフォーマンス問題の解決にはあまり寄与しません。ビューを作成これはオリジナルのテーブルには手を加えず、地方コードを追加したビューを用意して、そのビューへのアクセスによって簡単にSQLが記述できます。後述するような多段ビューという問題が発生します。BY句の中でアドホックキーを作ってしまう方法です。具体的には下記のようにSQLを書きます。END;多段ビュービューには抽出したい列のみを取り出せる、複雑なSQLの一部を定義することでSQLをすっきり表現できるなど数々のメリットがあります。当然ながらすべての技術にはメリットとデメリットがあり、ビューを作りすぎてしまうことのデメリットも当然発生します。以下のようなことがデメリットになります。デメリット実テーブルとの差分これは先輩からよく聞かされました。元のテーブルとの差分ができてしまうということで作っても変更や維持コストがそれなりにかかるということなんですね。パフォーマンスの劣化ビューは物理的にテーブルを所持しているのではなく、ただのクエリです。そのため何段にもわたるようなviewを作成していれば依存関係が複雑になり、わかりにくくなりますし、パフォーマンス自体も劣化します。自体は一段にとどめておくようにしましょう。システムの世界には過度に複雑なつくりはシステムをダメにするという思想があるようです。コメントをキャンセルメールアドレスが公開されることはありません。*ウェブサイト関連記事herokuでMySQL昨日に続き、heroku+MySQLのメモです。herokuはディフォルトではPostgreSQLですが、アドオンを使うとMySQLも使えるようになります。メモリとHDDデータベースについてまたまた学習中。覚えておきたいポイントなど。...MariaDBインストールCentOS7からはyumでmysqlをインストールするとMariaDBがディフォルトになるようです。これを機にMariaDBを使ってみました。応用編2引き続き結合についてです。...persistence.xmlのプロパティについてJavaEEではデータベースとの設定情報はpersistence.xmlに記述します。