私が管理するシステムには、プログラム、プロジェクト、ステージ、部署などの多くのエンティティがあります。 会社の多くのユーザーは、さまざまなエンティティの独自のビューを希望します。今まで私は自分でカスタムビューを作成していましたが、私の上司がクエリメーカーを作って各従業員がいつでも自分の作成したクエリを作成、保存、表示できるようにしています。表示したい主データを選択し、条件を追加するだけでなく、データの表示方法を選択することができます。質問ビルダーの作成についてのアドバイス
これは私がデータベーステーブルの面で、これまで持っているものです。
だから、たとえば、のは、マークという名前の誰かを言わせ
id
name
desc
isglobal (1 or 0 value, whether the query can be seen by everyone else)
creator (id of user in system)
created (datetime)
entity (this would be the table name or a key which maps to the table name)
template (a template of tags that will be parsed to generate the HTML for that query page)
query_conditions
id
queries_id
field
value
を問い合わせます彼がマネージメントとして持っているすべての "プロジェクト"を表示するクエリ/ビューを作成しますエル。
クエリ:あり、このようになり、両方のテーブルの行になり
1
All projects managed by Mark
Shows all projects in the system currently managed by Mark
1
6
2012-04-23 00:00:00
project
そして、これはtext型のあるテンプレートフィールドに格納されるものである
<!-- BEGIN: ROW -->
<tr>
<td>{PROJECT_NAME}</td>
<td>{PROJECT_DESCRIPTION}</td>
</tr>
<!-- END: ROW -->
query_conditions:
1
1 (this corresponds to the query id above)
manager
6 (this corresponds to Mark's user id in the system)
私が持っているデータベース設計は、単純な条件では非常に簡単で簡単に管理できます。私はすでに、より高度な状況を想像しています。そこでは、どの2人のマネージャーからのプロジェクトの一覧を見たいかもしれません。私は最初の3つの列の同じ値と "値"列の別の値を持つ余分な行があるところで、2番目のテーブルの現在のデザインがまだ動作すると思います。私は最初にSQLチェックを行い、SQLでORを使用しなければならない1コンディションまたはn条件を扱っているかどうかを調べることができます。
2つの問題があります。どのようにアプローチするのがベストかわかりません。
「値」フィールドはどのタイプにする必要がありますか。私は時間の99%、値は整数になると思っていますが、明らかに日付や文字列の可能性もあります。どのデータ型をお勧めしますか?おそらく最善ではありませんが、私はBLOBを考えていました。そこでは、シリアライズとシリアル化を行うことができます。 BLOBを使用して、私はいくつかの行を述べたように複数の行を格納する必要から私を節約する配列をそのフィールドに格納することができました。
他のものは範囲です。特定の日付の間にプロジェクトを作成したい場合はどうでしょうか。または、列の値が5〜10の場合などです。私はこれが "max_value"と呼ばれる追加の列で処理できるのだろうかと思います。この列がNULLでない場合は、その列が範囲とみなされ、「値」がmin_valueになります。
テンプレートフィールドに関するアドバイス。私は、そのカスタムクエリで返されるデータの行ごとに解析されるTEXTフィールドを作成します。
私が使用しているXMLファイルを表示すると便利だと思いました。私の上司は、これらのカスタムクエリを作成するためにテーブルのすべてのフィールドを表示したくないので、次のXMLデータを使用してどのフィールドを「許可」するかをフィルタします。
<?xml version="1.0"?>
<entities>
<entity>
<key>program</key>
<table>program</table>
<label>Programs</label>
<allowed>1</allowed>
<fields>
<field>
<key>name</key>
<column>prg_name</column>
<label>Name</label>
<tag>{PROGRAM_NAME}</tag>
<method>getName</method>
<allowed>0</allowed>
</field>
<field>
<key>description</key>
<column>prg_desc</column>
<label>Description</label>
<tag>{PROGRAM_DESCRIPTION}</tag>
<method>getDesc</method>
<allowed>0</allowed>
</field>
</fields>
</entity>
<entity>
<key>project</key>
<table>product</table>
<label>Projects</label>
<allowed>1</allowed>
<fields>
<field>
<key>name</key>
<column>prd_name</column>
<label>Name</label>
<tag>{PROJECT_NAME}</tag>
<method>getName</method>
<allowed>0</allowed>
</field>
<field>
<key>description</key>
<column>prd_desc</column>
<label>Description</label>
<tag>{PROJECT_DESCRIPTION}</tag>
<method>getDesc</method>
<allowed>0</allowed>
</field>
<field>
<key>manager</key>
<column>prd_manager</column>
<label>Manager</label>
<tag>{PROJECT_MANAGER}</tag>
<method>getManager</method>
<allowed>1</allowed>
</field>
<field>
<key>activity</key>
<column>prd_activity</column>
<label>Activity</label>
<tag>{PROJECT_ACTIVITY}</tag>
<method>getActivity</method>
<allowed>1</allowed>
</field>
</fields>
</entity>
</entities>
これは実際には、それはSQLが発明された主な理由です - 技術者以外の人々が平易な英語の単語を使用してデータベースを照会できるようにする。 'SELECT'クエリ(出力としてきれいにフォーマットされたテーブルを持つ)だけを許可し、それらを(非常に単純なものからより複雑なものに)使用する際のガイドに従うことを容易にするWebインターフェイスを持つことは、 – rid
私はそれについても考えました。しかし、私の上司は従業員がこれらのクエリを作成して、将来の使用のために保存できるようにするインターフェイスを求めています。基本的には、すべてのクエリの名前をリストするページになり、人々は各1を1ずつ素早く表示することができます。 クエリビルダのUIは、ソートのウィザードを経由するとほぼ完了します。ステップバイステップで、クエリを定義し、条件を設定し、表示するものを選択して保存します。基本的な条件はこの時点でかなりうまくいく。データベースの設定についてはわかりません。特にどのように範囲を扱う。 – Justin