リレーショナルデータベース管理システムのドキュメント指向データベースモデル
スコープ:ディレクトリに基づいて構築された(必ずしもそうではないが)静的な構造化データ配列
ツールのタイプ:Webアプリケーション用のデータ管理システム(CMS)。
実装:PHP、MySQL。
エンドユーザーの観点からは、考えられるすべての技術的な実装オプションは、複雑なまたは単純なGUIであるように見えます。GUIは、このデータセットを入力できます。 GUIが何であろうと、適用されるデータ入力要素(コントロール)によって制限されます:入力、選択、ファイル、テキストなど。 このデータセットはドキュメント(レコード)を記述し、そのプロパティのセットです。 有効な制御オプションに基づいて、プロパティは別の要素(ディレクトリ)の数値id値を持つか、テキストで記述することができます。
ドキュメント指向のデータベースの実装はCMSの観点から考慮されるため、いくつかの追加要件があります。迅速で簡単な検索と最も頻繁な並べ替えを実行するには、データ部分への迅速で簡単なアクセスが必要です。さらに、ドキュメントプロパティの単純な管理メカニズムが必要ですおよびデータ入力。
理論化は終わりました、行きましょう。
最初のメインテーブルは、オブジェクト自体(ドキュメント、レコード)のストレージです。
データベースにドキュメントを保存するのが最も簡単です。新しいドキュメントにはそれぞれ、id、親要素のid、プロパティを保存するためのテキストフィールド、および後で追加される多くの追加フィールドが割り当てられます。
idプロパティ名parent additional_field
1 Record_1 xml_property 0 additional_fields
2 Record_2 xml_property 0 additional_fields
3 Record_3 xml_property 2 additional_fields
4 Record_4 xml_property 2 additional_fields
プロパティは任意の方法で保存できます。一般的なセパレーターから。 と| jsonとxmlへ。
xmlを選択した理由は、PHPで作業するためのシンプルなメカニズムと、MySQLでのxPathの実装です。
各ドキュメントは、特定のテンプレート(コンテンツテンプレート(CS))で指定された一連のプロパティによって記述されると想定しています。
次の表は、ドキュメント(CS)のプロパティセットを説明する表です。 この表には、テンプレートの説明と、それに従属する任意の数のタブがあり、任意の数のフィールドに従属させることができます。
KSh_Name
Tab_1
field_1テキスト
field_2リスト
field_3日付
メインテーブル内の各レコードには、データを持つ特定の学校がそれを参照します。
当然、データに加えて、このデータをサイト上のユーザーに提示する必要があります(CMSに立っていることを忘れないでください)。
次の表は、コンテンツテンプレートのデータのデザインテンプレート(LH)プレゼンテーションを説明する表です。 LHは、任意のテンプレートエンジンに基づいて構築できます。 PHPとHTMLのプリミティブな混合を使用します。
ここで、課した制限を思い出して、追加フィールドに戻りましょう。
まず、最初に、KSおよびLHレコードに関連するIDが追加フィールドに入ります。 さらに、KSでは、xmlではなく、データベーステーブル(link1、link2、link3など)に直接格納するフィールドの一部を指定できます。 MySQLの有効なデータ型には、テキスト、数値、日付など、これらのフィールドがいくつかあります。
追加のフィールドには、キーワードとドキュメントの説明、およびさまざまなユーザーのアクセス権に関する情報が含まれます。
このアプローチの利点は何ですか:
熟練していないオペレーターのデータを入力するためのシンプルで柔軟なテンプレート設定メカニズム。
データベースから1つのクエリでidによってレコードを受信すると、そのプロパティの最大数が取得されます。
xPathメカニズムを使用してMySQLでXMLを操作する機能。
欠点は何ですか:
MySQLに保存されている場合、XMLのデータでネイティブにソートできない
LIKE '%'コンストラクトによる遅い設計
原理が説明されていますが、多数のプロジェクトが機能しているCMSが完全に実装されています。
All Articles