後で実行するためにSQLステートメントをテーブルに保存するのは悪い考えですか？

後で実行するためにSQLステートメントをMySQLテーブルに保存するのは悪い考えですか？SQLステートメントの実行準備が整います。つまり、スワップするパラメーターなどはありませんDELETE FROM users WHERE id=1。

私は怠けていると思いますが、SQLステートメントを定期的に実行するかなりの数のcronジョブを必要とするプロジェクトに取り組んでいるので、このアイデアを考えました。

それがあなたが求めているものなら、それは安全です。データのセキュリティと同様にセキュリティに注意している限り。

ただし、車輪を再発明しないでください。ストアドプロシージャはテーブルに格納されたSQLの一部です。そして、彼らは、パラメータ化をサポートします。

また、cronの代わりにMySql Event Schedulerを使用することにより、セキュリティをよりシンプルにし、障害ポイントの数を減らし、ネットワーク通信を減らすことができます。

他のデータベースには、これらと同等の理由があります。この機能が最初に必要なわけではありません。

後で実行するためにデータベースにSQLステートメントを保存する場合は、テーブルに置くよりも優れたオプションがあります。この特定の目的のために提供されている組み込み機能を使用します。ストアドプロシージャに入れます。

いいえ、私はそれは良い考えではないと言うでしょう。

つまり、すべての「実際の」クエリ/更新には、データベースで2回のヒットが必要です。1回は「実際の」クエリ/更新を取得し、もう1回は実行する必要があります。

これは小規模なシステムでは大きな問題ではないかもしれませんが、システムが取得するユーザー/トランザクションが多いほど、規模は小さくなります。

これは、コードにSQLを埋め込む代わりの方法を探しているからだと思いますか？

Mason Wheelerが示唆したように、SQLをストアドプロシージャにカプセル化することは、このアイデアよりもはるかに優れた1つの方法です。

申し訳ありませんが、それは良い考えではありません。

問題のテーブルが変更される場合を考えます。あなたの言うのid列が名前に変更されますNEW_ID。

変更自体だけでなく、古いヴィンテージのデータベース用に記述されたバージョンのコードがあり、実行できなくなる可能性があります。確かに、コード表をチェックインすることを知っているかもしれませんが、他の誰かにとってはすぐにはわかりません。

私が説明したような変更については、通常、スタンドアロンSQLファイル、ストアドプロシージャ、トリガー、クライアントコード（VB、C＃、C ++など）のインラインSQLを調べますが、最後に見てみたいと思いますデータベーステーブルにあります。多分私は今！:)

SQLをテーブルに保存する正当な理由があります。職場で作業するソフトウェアには、ドキュメントを生成するシステムが含まれており、ドキュメントにはデータベース内のデータを使用したかなり複雑な計算を含める必要があります。ドキュメントは頻繁に更新され、多くの場合、必要なデータと実行する必要のある計算の点で大きく異なります。基本的に、SQLはこれらの計算を実行するためのスクリプト言語として使用されており、そのSQLはこれらのドキュメントの他の情報も格納するテーブルに格納されています。これらのドキュメントを管理している人々はプログラマやDBAではありませんが、データベーススキーマに精通しており、SQLに精通しています。そのSQLコードをストアドプロシージャの形式で維持することは、彼らにとって大きなオーバーヘッドになります。

あなたが説明したことについて-「... SQLステートメントを定期的に実行する非常に多くのcronジョブを必要とするプロジェクト」-他の答えは、DBMSに対してストアプロシージャまたは同等のものを使用したことを示唆するのにおそらく正しいでしょう。再使用。

SQLをテーブルに格納するのがストアドプロシージャに格納するのが賢明かどうかを判断するための適切な基準は、そのSQLを誰が管理するかを決定することです。ユーザーがそのSQLを維持する場合、つまり、必要なときにいつでもそれを記述して変更する場合、そのSQLをテーブルに格納することは完全に適切であり、実際に最適です。開発者がそのSQLを維持する場合、（希望する場合は自動化された）ビルドおよびデプロイメント手順によって更新できる形式で保存する必要があります。たとえば、データベース自体のストアドプロシージャのようなオブジェクトとして保存します。

簡単な方法は、クエリを保持するために.iniまたは他の構成フレーバーファイルを使用することです。この方法で、1か所でクエリを保持し、データベースにアクセスせずに何回でも変更できます。また、ある時点でパラメータを使用したり、クエリに条件を追加したりする必要がある場合があります（コード内の特定のケースに合わせて、より複雑なものを追加します）。

もちろん、データベースレベル（テーブル内、またはストアドプロシージャとして）で保持することもできますが、私と同じくらい怠けている場合は、-）パフォーマンス、.iniファイル、およびPHP それを読むためのparse_iniメソッドが大好きです（別のプログラミング言語を使用する場合は、同様のアプローチを自分で考えます）！通常、アプリケーションのブートローダーでこのファイルを読み取り、静的オブジェクト（キャッシュ層が最上位にある可能性があります）に保存して、非常に多くの個別のクエリについて話している場合に速度を上げます。

たとえば、営業時間外に実行する一連の操作をキューに入れている場合など、SQLステートメントが1回だけ必要な場合は、はい、それらをテーブルに入れると問題なく機能します。

指定した間隔で同じSQLステートメントを実行する必要がある場合は、他の人が言及したストアドプロシージャルートの方が適している可能性があります。

とは言うものの、あなたが尋ねているのはかなり珍しいことであり、他の問題の兆候かもしれません。たとえば、データベースからユーザーを削除するのを待っている場合、実際のSQLステートメントを記録するよりも、アプリケーションコードを介して操作を実行するスケジュールされたスクリプトを呼び出す方が適切な場合があります。これにより、SQLとコードが同期しなくなることはありません。