最後の、、、EC-CUBE、、、からの「逸脱」として。。。

引用：

SQL86, SQL89, SQL92, SQL:1999, SQL:2003, SQL:2006, SQL:2008, SQL:2011
以降でも「関数」が「担保」されるのであれば、それは「良い」かもしれません。

引用：

この辺りは「M」の作り込みに際して「思慮」が如何に深くなされているかではないでしょうか？
この辺りを、少しづつ掘り下げで行きたい思っています。

引用：

プログラム言語は、それを提唱した「人」の「その時点での信念でしかない」のですから、
javaもその「信念」を継承出来ない時期に来ており、、、プログラム言語は

引用：

において、その都度、生まれ、変化する。。。

「php」や「java」、、、「他」、、、を駆逐する「概念」が出て来てきていない今、、、
「何をどうして良いのか」、、、「頭の中」で「ホワイトペーパー」が駆動されていな状態では何も提言出来ないのですが、、、

「はやぶさ」を帰還させた JAXAの「知」も持ってすれば、雑作もないことだとは思うだが。。。

> SQL86, SQL89, SQL92, SQL:1999, SQL:2003, SQL:2006, SQL:2008, SQL:2011
> 以降でも「関数」が「担保」されるのであれば、それは「良い」かもしれません。

個人的には、「現状使えて、(実装レベルで)廃止の方向でない」ならば、そこは「良し」かなと思います。

非対応な実装に対しては、リアルな DBMS の関数でなく、DBMS で処理させる為の仕組みでも代替可能でしょうし。


とはいえ、この処理を DB 関数で行うは、今のところ些か否定的な気分ですけど・・・

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

書き方が悪かったですね、SQLの関数を使うではなく、PHPの関数化するです
SC_DB_DBFactoryを使うイメージです

SQLも部品化して再利用しやすいようにしてやるほうがメンテも、使い回しもしやすいかなと。プラグイン化もしやすいですし

----------------
EC-CUBEのカスタマイズ、トラブル解決承ります
お気軽にお問い合わせ下さい
https://www.ec-cube.net/integrate/partner/partner.php?partner_id=690

> このデータ作るためにforeachが多すぎる気がしちゃいます。。

全てのエンティティクラスで同様に記述するなら、確かに多いような気はしますね。

ただ、ざっと見た印象では、ある程度は基底クラス化できそうなので、相対的な記述数は削減できるのかも。

あと、SC_Entity_OrderDetail#getCategoryIds の foreach あたりは、冗長に書いてしまったポカミスかなとも。


> update分も逆に冗長になってるような

確かにサンプルだけ見ると、そんな印象はありますね。

現実的に重要なのは、もっと実際の実装のように、込み入った時にどうなるかでしょうか。


> updateしたい値以外不要な情報ですよね

最近は、DB の処理が最適化される方向なので、この辺りの心配は軽視できそうです。

そうでなくても、エンティティクラスサイドで、差異のあるカラムのみ出力するとかは簡単にできそうな気もします。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

> # Java 嫌いな方には顰蹙を買いそうです(汗)

変数で駆逐を目指したはずの「ラクダ」が、メソッドでやたら蘇っている！

これは地味に嫌だ。


【追記】
・・・って、おい！ 脳内 PHP コンパイラが Notice 発報。


やっぱり、(Java でありがちな) 画一的な setter getter を PHP に持ち込むのは勘弁・・・

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

引用：

「setter getter」に関しては、小生も「わけわかめ」。。。

いづれにせよ、題名から、趣旨が外れて来ましたので、
「Yellow Book for EC-CUBE」なスレッドを起こします。