DBスキーマの見直し

[chihiro-adachi]

データベースのスキーマについて、仕様変更点も含め見直しを行っています。
以下の方針で進めています。

方針

• 名称、データ型の変更
  • テーブル名は、命名規則を定め、修正を行う
  • カラム名称、データ型は原則変更しない
• テーブル定義・リレーション定義の変更
  • ORMであつかいやすい形に変更する
  • 機能仕様の変更がある場合は、テーブル・リレーション定義の変更を行う
• 削除対象のテーブルの扱いについて
  • 利用していないテーブル/カラムは削除する
  • プラグイン化する機能のテーブルは本体からは削除する

命名規約

省略名称

省略名称を利用せず、正確な名称で命名する

dtb_deliv -> dtb_delivery

単数形

単数形で命名する

dtb_products -> dtb_product

スネークケース

スネークケースで命名する

dtb_classcategory -> dtb_class_category

プレフィクス

テーブルには種別によってプレフィクスをつける

マスタテーブル

mtbをプレフィクスとしてつける

mtb_pref

データテーブル

dtbをプレフィクスとしてつける

dtb_customer

フラグ

フラグとして利用しているカラムはsmallintで扱う

複合主キーの扱い

複合主キーは利用せず、サロゲートキーを利用する
※多対多の中間テーブルは除く

[ttsuru]

@chihiro-adachi
マイグレーションと関連して進めていった方がいいと思います。
できるだけ2から移行できるようなマイグレーションが必要だと思います。
それまでは今までのテーブルをそのまま使えたほうが移行もしやすいのではないでしょうか。

[chihiro-adachi]

@ttsuru
ありがとうございます。

方針としては、修正すべきものは修正するという方向性でいきたいと考えています。
2から3への移行に関しては、スキーマの変更点を明示することや、データ移行モジュールのようなアプローチで解決できればと思いますがいかがでしょうか。

3からのマイグレーションについては対応していきます。
※ちょうどマイグレーションの検証を行っており、まもなくissueにもあげられるかと思います。

[ttsuru]

@chihiro-adachi
2からのマイグレーションをマイグレーションツールもしくはSQLで提供するべきだと思います。
今もしそういったサポートがなく、ドキュメント程度にとどめてしまうと、結局移行できるユーザーはごくわずかになってしまうと思います。

3の中でのマイグレーションを実装し、問題なく動くようになってから、スキーマの変更に着手して欲しいと強く思います。

[Yangsin]

@ttsuru
2.13以前からの移行ニーズは認識しておりますが、2.13以前の設計やカスタマイズ手法は、そもそもマイグレーションを考慮せずに、その分自由で多様な多様なカスタマイズがおこなわれておりますので、
その延長線上で、3のDB構造の制約とすることは適さないと考えています。
本Issueでは、まずは、3の形を定めさせてください。

3を定めた上で、どう移行を支援するのかを決めていきましょう。
もちろん移行に向けたアイデアやプラグインの提供も大歓迎ですが、本Issueとは別ですすめさせていただければと存じます。

[seasoftjapan]

個人的には複合主キーの方が勝手が良かったですが、サロゲートキーとするなら、テーブルに紐付いたシーケンスに戻せないですかね。テーブルデータを直接書き足す時に、シーケンスの扱いが結構面倒で。

・・・と書きつつ、数日前にやったカスタマイズで、シーケンスの書き換えを漏らしていたことを思い出したり 😱

[nanasess]

フラグとして利用しているカラムはsmallintではなく、booleanにする

他の RDBMS との互換性を考えると smallint の方が良いと思いますがいかがでしょう?

[shinichi-takahashi]

@seasoftjapan
複合主キーに関しては、ORMで扱いやすくする観点で排除になります。
Doctrineでは、複合主キーを持つテーブルに対してINSERTしようとしたときに処理が大変まどろっこしくなっちゃうんです。
DB制約的に複合主キーをなくす方がよいという判断ではありません。

[seasoftjapan]

やっぱりORM嫌い。とりあえずシーケンスの件だけでも叶うと嬉しいです。

あと1点。
name ってカラム名を避けて欲しい。grep すると膨大に引っかかるし、商品・商品規格まわりと結合して取り出すとき都度別名定義必要だし。

[ttsuru]

@Yangsin

移行の仕組みやどうやって移行できるかがわからないうちに3の形式を定めてしまうと、結局のところ移行が上手くいかない可能性があるのではないでしょうか。

table(ORMと切り分けて)のネーミングやちょっとした命名を変更してもほとんどsilex上で書いているコードに変化はなく、DBに差分が生まれるだけなのかなと思ってしまいます。
逆に、大きな機能に変化がないのであれば、とりあえずは今のスキーマのまま動く方がクライアントにはメリットがあると思います。
現状のSilexであれば、EC-CUBE2.13の実際のDBを使って差分SQLを数個実行するだけでEC-CUBE3が動きます。

仕様を検討することはいいともいますが、本当に今タイミングでそれを実装する必要があるのでしょうか。
僕は2のDBでそのまま動く方が魅力を感じますし、クライアントにも話がしやすいと思います。
たとえば、3.0では変更せずに3.1で変更をすることで、2.13 -> 3.0 -> 3.1 とバージョンアップすることでスキーマの移行ができるなどの方法を確保することはできませんでしょうか。

[ttsuru]

@nanasess
DoctrineがORM側のbool定義をもとにDBごとに適切な型を選びます。
実際にはORM側がboolになっていてもDBはsmaillintで動きます。

[seasoftjapan]

移行に関しては、EC-CUBE 以外からの移行も多々やりましたが、双方のデータ構造さえ把握できれば、さほど難は無かったです。生パスワードを抜けないとか、もっと根本的な所でのネックはありましたが。

過去の傾向からすると、2.13 → 3.0 よりも、2.12 → 3.0 とか 2.13 → 3.1 の方が需要が高いと思いますので、そのあたりもどこまでカバーできるかも、移行を検討する上では課題だと思います。

[Yangsin]

みなさんご意見ありがとうございます。
やっぱり移行に結構話がフォーカスしますね（苦笑）

@ttsuruさんのお話は単純に移行の話だけでなく、機能変更がないのに、スキーマが変更することは、移行のハードルをあげるだけという、懸念だと思ってます。スキーマについては、いただいた懸念も踏まえて、機能のブラッシュアップを進めながらFixさせていければと存じます。3系の機能についても、より具体的に示せるように資料等準備させていただきますので、別途フォローお願いします。

移行については、@seasoftjapan さんのように、EC-CUBE2.13系までは、DBへの直接的なカスタマイズも多く、また移行元となるバージョンにもばらつきが激しいことが想定されます。2系以下については、標準で移行をサポートしようとしても、結局はしきれない可能性が高く、Seasoft様のおっしゃるように、データ構造の違いを明確にして、移行をフォローしていく事に重点を置きたいと思います。

また、3の機能としてのマイグレーションも行っていく予定ですので。
Seasoft様がおっしゃる、2.13→ 3.1 に関してはカスタマイズの規模によっては、 なんとか、3.0にあがってもらえれば、3系のマイグレーションをつかって、2.13→ 3.0 → 3.1 というようなステップもありえるかと存じます。

3の中でのマイグレーションは、 @chihiro-adachi が記載しているように、検証中ですが、まとまり次第もうすこし具体的に公開していきます。

[chihiro-adachi]

いただいたご意見もふまえ、スキーマ変更についての方針を再度作成しました。

変更が発生するケースは以下になります。

• 機能変更や仕様変更が発生するケース
• 複合主キーからサロゲートキーへの変更
• テーブル名のみ命名規約に沿った修正を行う

細かな変更は極力避け、開発時の負荷になるもの、機能変更が発生する場合を念頭においています。
マイグレーションについては、#214 にて検証をすすめています。

方針

• 名称、データ型の変更
  • テーブル名は、命名規則を定め、修正を行う
  • カラム名称、データ型は原則変更しない
• テーブル定義・リレーション定義の変更
  • ORMであつかいやすい形に変更する
  • 機能仕様の変更がある場合は、テーブル・リレーション定義の変更を行う
• 削除対象のテーブルの扱いについて
  • 利用していないテーブル/カラムは削除する
  • プラグイン化する機能のテーブルは本体からは削除する

命名規約

省略名称

省略名称を利用せず、正確な名称で命名する

dtb_deliv -> dtb_delivery

単数形

単数形で命名する

dtb_products -> dtb_product

スネークケース

スネークケースで命名する

dtb_classcategory -> dtb_class_category

プレフィクス

テーブルには種別によってプレフィクスをつける

マスタテーブル

mtbをプレフィクスとしてつける

mtb_pref

データテーブル

dtbをプレフィクスとしてつける

dtb_customer

フラグ

フラグとして利用しているカラムはsmallintで扱う

複合主キーの扱い

複合主キーは利用せず、サロゲートキーを利用する
※多対多の中間テーブルは除く

20145/6/16 本ISSUEへ上記内容を反映しました。

[ttsuru]

こちらもご参考までに
http://doctrine-orm.readthedocs.org/en/latest/reference/best-practices.html

[nanasess]

フラグとして利用しているカラムはsmallintではなく、booleanにする

beta2 の yml を確認すると、 まだ smallint のままになっているようですが、これから変更される予定でしょうか？

[Yangsin]

フラグとして利用しているカラムはsmallintで扱う　形で最終Fixしております。
（MySQLでのBooleanのあつかいなどの関係でBooleanにするメリットなしと判断）