4D v164Dと4D SQLエンジン統合の原則 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4D v16
4Dと4D SQLエンジン統合の原則
4Dと4D SQLエンジン統合の原則
原則として、4D SQLエンジンはSQL-92互換です。つまり使用するコマンドや関数、演算子、シンタックスの詳細な説明が必要な場合、SQL-92リファレンスを参照できます。これらは例えばインターネットで見つけることができます。 しかし、4D SQLエンジンはSQL-92の機能を100%サポートしているわけではありません。また特定の追加の機能をサポートしています。 この節では、4D SQLエンジンの主たる実装と制限について説明しています。 4DのSQLエンジンは4Dデータベースの深い部分に統合されているため、テーブルやカラム (フィールド) 、レコードの最大数や、テーブルやカラムの命名規則に関する制限は、標準の内部的な4Dエンジン (DB4D) と同じです。以下にこれらをリストします。
異なるユーザにより作成されたとしても、同じテーブル名は許可されません。標準の4Dコントロールが適用されます。 以下の表では、4D SQLでサポートされるデータタイプと、それに対応する4Dのタイプを説明しています:
数値タイプ間の自動変換が実装されています。
NULL値は4D SQLランゲージおよび4Dデータベースエンジンに実装されています。しかし4Dランゲージではサポートされていません。にもかかわらず、Is field value NullとSET FIELD VALUE NULLコマンドを使用して、4DフィールドのNULL値を読み書きできます。 4Dでの互換性のため、4Dデータベーステーブルに格納されたNULL値は、4Dランゲージを使用して操作する際、自動でデフォルト値に変換されます。例えば以下の文において: myAlphavar:=[mytable]MyAlphafield MyAlphafieldフィールドにNULL値が含まれる場合、myAlphavar変数には"" (空の文字列) が代入されます。 デフォルト値はデータ型により異なります:
他方、このメカニズムは原則として、クエリのような4Dデータベースエンジンレベルでは適用されません。実際、空の値の検索 (例えばmyvalue=0) はNULL値が格納されたレコードを見つけませんし、逆の場合も同様です。両方のタイプの値 (デフォルト値とNULL) がレコードの同じフィールドに存在する場合、処理が変更されたり、あるいは追加のコードが必要となることがあります。 NULL値を空値にマッププロパティはデータベースエンジンの低レベルで考慮されます。特にIs field value Nullコマンドに影響します。 NULL値の入力を拒否フィールドプロパティは、NULL値が格納されることを防ぐ目的で使用されます: フィールドのこの属性にチェックが入れられていると、そのフィールドにNULL値を格納できなくなります。この低レベルのプロパティはSQLのNOT NULL属性に対応します。 注: 4Dでは、フィールドに"必須入力"属性を設定することもできます。2つの設定のコンセプトは似ていますが、スコープが異なります。"必須入力"属性はデータ入力コントロールであり、“NULL値の入力を拒否”属性はデータベースエンジンレベルで動作します。 4D の統合 SQL サーバーは、ODBC API に沿った日付と時間の定数をサポートします。ODBC 日付・時間定数のシークエンスのシンタックスは以下の通りです: {constant_type 'value'}
注: fff はミリ秒を意味しています。 例えば、以下の様な定数を使用することが出来ます: { d '2013-10-02' } SQL においては、月または日に "0" を指定している日付は拒否されてしまいます。例えば、次のような式はエラーを生成します: {d'0000-00-00'}、CAST('0000-00-00' AS TIMESTAMP) など。空日付 (Null日付ではないことに注意) に対して SQL クエリを行うには、次の例のように4D式を利用します: C_LONGINT($count) プロジェクトメソッドにおいて設定可能な"SQL利用可"プロパティは、SQL経由の4Dプロジェクトメソッドの実行を管理します: このオプションがチェックされていると、このプロジェクトメソッドを4D SQLエンジンから実行できます。デフォルトではチェックされておらず、4Dプロジェクトメソッドは保護されていて、4D SQLエンジンから呼び出すことはできません。メソッドを4D SQLエンジンから実行可能にするには、このオプションにチェックしてそれを認可しなければなりません。このプロパティはODBC Driver経由、あるいはBegin SQL/End SQLタグの間に挿入されたSQLコード、またはQUERY BY SQLコマンドによる実行など、内部外部問わずすべてのSQLクエリに適用されま す。 Notes:
4Dはスキーマのコンセプトを実装しています。スキーマはデータベースのテーブルを含む仮想的なオブジェクトです。SQLにおいてスキーマの目的は、異な るデータベースオブジェクトのセットに特定のアクセス権を割り当てることです。スキーマはデータベースを、そのデータベース全体を形成する個々の独立する エンティティに分割します。つまりあるテーブルはいつもただ1つのスキーマに属します。
Note: スキーマによるアクセスコントロールは、外部からの接続のみに適用されます。Begin SQL/End SQLタグ、SQL EXECUTE、QUERY BY SQL等によって4D内で実行されるSQLコードは、常に完全なアクセスを持ちます。 4D SQLサーバのレベルでは、マルチデータベースのアーキテクチャが実装されています。4Dでは以下のことが可能です:
SQLランゲージでは主キー(プライマリーキー)を使用して、テーブル中のレコード (行) を指定するテーブルカラム (フィールド) 決定します。主キーの設定は、特に4Dテーブルのレコード複製機能(SQLを使用した複製参照)および4Dテーブルのログ機能を使用するためには4D v14以降では必要となります。 4Dでは2つの方法を使用して主キーを管理できます:
注:
テーブルを作成するとき (CREATE TABLEコマンドを使用) またはカラムを追加や変更するとき (ALTER TABLEコマンドを使用)、主キーを設定できます。主キーはPRIMARY KEY句とそれに続くカラム名またはカラムリストで指定されます。 詳細はを参照してください。 4Dではストラクチャーエディターのコンテキストメニューを通じて、主キーを直接作成・削除することができます。 この点についてのより詳細な情報については、4D デザインリファレンス マニュアルの主キーを設定、削除するを参照して下さい。 4D の統合SQLエンジンは、標準のSQL viewsをサポートしています。ビューとは複数の異なるデータベースのテーブルからのデータを受け取れる仮想テーブルです。ビューは定義されると SELECT 宣言の中で実際のテーブルと同じように使用することができます。 ビュー の中のデータは SELECT コマンドに基づいた定義クエリによって定義されます。定義クエリの中で使用される実際のテーブルは「ソーステーブル」と呼ばれます。SQLビューには標準 のテーブルと同じように列と行がありますが、実際に存在しているわけではなく、セッションの間メモリーに格納された処理結果を表示しているにすぎません。 実際に一時保存されているのはビューの定義だけです。
参照
|
プロパティ
プロダクト: 4D
履歴
ARTICLE USAGE
SQLリファレンス ( 4D v16) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||