MySQL動的に変化が多すぎるスキーマの管理方法を考える。

最近小規模な独自の物流システムを設計しているところなのですが、商品のスキーマがいろいろ変化が多いのでどのように設計していくかを考えています。

作りたいのはこのようなテーブル

基本的な情報以外は’メタ情報’として外部へ分ける。

先程のテーブルAを次の図のテーブルB,Cように別に分ける。(WordPressの postsとposts_metaのような感じ縦持ちと呼ぶのは知らなかった。><)

テーブルBは基本的な情報のみ

テーブルCはメタ情報を記録

また情報が増えた場合は以下の用に増えても問題がない。

スキーマの管理をどうするか問題

もう一つの問題は、スキーマの変更をどうやって管理していくか。
勝手にデータを追加していっても良いのですが、データの正規化のためのバリデーションルールなどを管理画面から操作していくために。

productsテーブルにはどのようなメタデータがあるかを何処かで定義しないといけません。
幾つか思いつく方法としては、

• A.Jsonなどでテキストで保存する。
• B.モデルのプログラムに記載する。
• C.scheme用の別テーブルに保存する。

などが思いつきましたが、Aの方法はバックアップなど、管理も大変なのでNG。
Bのモデルのプログラムに記載するは、隠蔽するということで良い面もありそうだけど今回は、運営の担当者レベルで、管理画面から動的に変更をしたいのでNG。
ということでCのスキーマ用のテーブルに保存する方法を考えて行きたいと思います。

スキーマ定義テーブルの設計

まずは最少な感じだとこんな感じ。(愛称:nicknameと説明:descriptionと追加)

もう少し考えるとお昼は提供可(day_menu)、夜はNG(night_menu)などの1 or 0 みたいな選択肢の場合はどうしよう。

と言った感じで表現できそう。なにか動的フォームの設計のようです。あとはセットメニューに配達範囲(プルダウンのような)の項目を追加をイメージして見ます。

関連するテーブル追加も考えたのですが、READで負荷がかかるところでないので(管理画面からの操作のみを想定)JSON文字列を突っ込んでます。
(DB正規化を尊重する場合は、scheme_select_optionsなどのテーブル追加なのかどうか?とかも)

今回の実装は以下の方向性で進めてみる。

まずはデータの全体のイメージはこれ

で、実際のテーブルは以下の通りに定義

とりあえず問題は無いと思うのですが、細かい部分をDBに定義するかプログラム部分に持ってくるかが今後ちょっと検討課題になってきそうです。