ピースペース

伝票の明細テーブルは必要か?

leave a comment »

売上の場合、商品をキーにして過去の売上リストをたどりたい場合がある。
この場合、RDB上に売上と売上明細を別テーブルとして作成することは有効だ。

一方、別テーブルにする必要ない情報を構造上仕方なく別テーブルにしている。ということもあるかもしれない。
例えば、履歴書の経歴みたいなもの。

履歴書の経歴は、履歴書編集画面(と表示画面)にしか登場することがない。という場合。
このとき、履歴書経歴は履歴書に完全に閉じたプロパティだ。
この履歴書経歴を別テーブルとして設計することは(普通に行われているので)さして問題はないかもしれない。
しかし、そうすると、知らず知らずコードを面倒にしてしまっている。ということがあるような気がする。

履歴書経歴をRDB上は履歴書テーブルの単なる1項目として定義することはできる。
つまり、経歴をまるごとJSON文字列として文字列型項目に格納するようにする。

経歴行の追加や削除などのUIを完全にViewの中に閉じ込めればいいのだ。
JSON文字列→配列に展開、配列→JSON文字列変換をView側で完結してしまえば、
サーバー側はそれが実はコレクションな項目であるとか意識する必要はなくなる。
要するに、サーバー側に経歴モデルは全く必要なくなる。
と設計する効果は大きいような気がする。それが可能な場合には。

ストレージがRDBな開発で、Modelを定義するときに、ふと、
存在の影の薄さに気付いたら、そのModelが本当に必要かどうかを考え直してみる。
DBにはJSON文字列で格納すれば済む!というものは他にもいろいろあるかもしれない。

Written by nasu38yen

2013年10月11日 @ 4:18 PM

カテゴリー: 未分類

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。