関数の本体をデータベーステーブルに格納する
Webアプリケーションの場合、アプリのソースコード内にcalculateAmountという関数を作成したとします。 Webアプリ内で、その関数を呼び出す必要があります。
しかし、何らかの理由で、「自動化」が必要なため、アプリ自体に「自分自身で考える」ことを求めます。プログラムのどの段階で、どの関数を実行する必要があるかを考えます。
たとえば、アプリのユーザーが「アクションA」を実行している場合、関数calculateAmountが呼び出されます。アプリのユーザーが「アクションB」を実行すると、別の関数calculateTaxが呼び出されます。
最初のアイデア：「自動化」の効果については、関数名calculateAmount、calculateTaxをデータベーステーブル内に単純に格納できると教えられました。次に、Webアプリが実行されているとき、実行のさまざまな段階で、Webアプリはデータベースを呼び出し、データベーステーブルから取得した結果に基づいて、呼び出す必要のある関数を特定します。
2番目のアイデア：例として言うと、calculateAmountは以下のようなJavaScript関数です。
_function calculateAmount(paramA,paramB){
return paramA + (5/100) + paramB;
}
_繰り返しますが、「自動化」のために、関数の本体return paramA + (5/100) + paramB;をデータベーステーブル内に単純に格納できると教えられました。次に、Webアプリは単に「自分自身で考える」ことができ、calculateAmount関数を呼び出す必要がある場合、Webアプリはデータベースを呼び出し、データベーステーブルから関数本体を取得して、任意の関数を実行できます。正しい状況が発生したときはいつでも。
私の質問は、上記の2つのアイデアが非常に一般的に実践されているかどうかです。上記の実践がデータベースまたはWebアプリのパフォーマンスに悪影響を及ぼす可能性がある状況はありますか？
編集：そして誰かが私に宣伝しようとしていた全体像は、データベース内に多くのものを保存できるということです。ソフトウェア開発者がこれを十分に行うことができれば、開発者がソースコードを書くことに依存することが少なくなります。これは、構成、関数名、関数本体をデータベースに保存できるためです。多くの開発者にソースコードの記述を任せる代わりに、ソフトウェアに頼って、どの時点でどのソースコードを実行する必要があるかを考え、それに応じてデータベースから取得することができます。
ソフトウェア製品全体がこの方法で設計できる場合。私にこの哲学を教えようとした人は、開発とテストが完了すると信じています。ソフトウェア製品自体は、保守やカスタマイズがそれほど難しくありません。それは、ソフトウェアの「たくさんの」本質的な「ブロック」が「データベース内に存在」し、ソフトウェアを変更または維持するためです。データベース内のデータを編集するだけです。
誰かがあなたが本当に理解していない説明をあなたに与えたようです、そして今あなたはインターネットで見知らぬ人にあなたがより良いものを与えることができるかどうか尋ねますか？ええと、その会社や製品はわかりませんが、あなたが書いたものから、このアーキテクチャの背後にある真の動機が何であるかを知識に基づいて推測させてください。
ソフトウェア開発者がこれを十分に行うことができれば、開発者がソースコードを書くことへの依存が少なくなります。
率直に言って、ナンセンスです。このようなコードは、開発、テスト、展開する必要があります。DBに保存されているか、他の場所に保存されているかは問題ではありません。
多くの開発者に依存してソースコードを作成する代わりに、ソフトウェアに頼って自分自身で考えることができます。
データベースにコードを格納すると、システムの顧客はless開発者ではなく、通常のソースコードを保守する開発者よりもother開発者に依存することができます。これはcustomizationの形式であり、ソフトウェアを「自分で考える」ことはできません。その図は適合しません。
開発とテストが完了すると、ソフトウェア製品自体の保守とカスタマイズはそれほど難しくありません
ソフトウェアは、特定のメンテナンスタスクの責任を顧客に移しているため、ベンダーの観点からは「メンテナンスが簡単」になるだけです。シナリオで
ベンダーがソースコードファイルの責任を負っている（おそらく契約による）
顧客はデータベース内の自分のデータに責任がありますが、ソースコードファイルには責任がありません
顧客が特定のカスタマイズを自分で実装してDBに格納する方が簡単で労力が少ない場合があります。このアプローチを使用して、ベンダーが提供する（および欠陥の場合に維持する）ものと、顧客が提供する（および欠陥の場合に自分で維持する）ものの境界を明確にすることができます。
しかし、全体的な労力は開発とテストの側で保存されず、単に誰かにシフトされます。
上記のプラクティスがデータベースまたはWebアプリのパフォーマンスに悪影響を及ぼす可能性がある状況はありますか？
カスタマイズされたコードを非常に頻繁に実行する必要があるシナリオがあり、バッファリングなしで、プログラムのその部分が常に必要なときに常にコードを何度もdbからプルする場合、これはパフォーマンスに悪影響を与える可能性があります。理論的には。しかし、それが実際に重要であり、それがそれ以上問題にならない程度まで最適化できるかどうかは、一般に答えることができない完全に異なる質問です。いつものように、パフォーマンスに関しては、実際のシステムを見て測定する必要があります。
ここでもっと心配する必要があると思いますセキュリティの問題：コードの特定の部分をベンダーから顧客に書き込む責任を変更することにより、システムの動作を操作できる人の数が増えます。それらの一部に悪意がある場合、システムに任意のコードを配置することを許可するとどうなるか想像できます。
ここで注目するもう1つのことは、テストとバージョン管理の戦略です。DB内のコードが、DBの外のコードと同じテストとバージョン管理の手順に従っていない場合、シナリオにつながる可能性があります。
誰かがDBの1つの機能を変更する可能性があります。
誤ってバグを導入する
本番システムに直接計算エラーを導入する（事前のテストなし）
その後、バグを修正します（ただし、計算結果は間違っていません）
そして、その履歴はソース管理のどこにも文書化されていません。
したがって、この形式のカスタマイズを導入する機能については非常に注意します。それ以外の場合は、簡単に見つけるのが難しいエラーの新しい原因になる可能性があります。
最初のアプローチ：すべてのコードはリポジトリに均一に属し、合理的に均一な方法でデプロイされます。また、デプロイ時に誤って変更することも困難です。これにより、信頼性が向上し、柔軟性が低下します。
2番目のアプローチ：最も重要なコードのいくつかはさまざまな方法でデプロイする必要があり、DBを更新することで実行時に変更できます。これにより、複雑さが増し、予測可能性が低下しますが、柔軟性が高まります。
目標に最も一致するものを選択してください。