2009-03-10 4 views
1

私は、 "bread'n'butter"アプリケーションの開発を簡単にするための別のフレームワークを書くことを考えていますN個のフィールドを持つクラス、空き領域とDB永続性のためのエディタを取得します)。一般的なキーとタイプを持つキーと値のペアのセットとしてデータを保持するためのオプション

すべてのデータモデルはEntity-Attribute-Value形式に変換することができます:私は、BLOBテーブルのエントリへのVALUE列内の参照を保持したいので、本当に大規模なフィールドの多分第二のテーブルで

TYPE VARCHAR(32) 
ID LONG INT 
NAME VARCHAR(32) 
VALUE VARCHAR(64000) 

。私が気分があれば、値型ごとに1つのテーブルを作成することができました(INTEGERはINTEGERですべての変換問題を回避します)。テーブルを使用して有効なTYPEなどを定義することができます。

これにより、そこにDBデザインがないので心配する必要があります。データベースは、簡単な更新を使用して、モデルの変更に対応することができます。私は、追加のフィールドを持つ同じクラスのインスタンスを持つことさえできます。

欠点は、オブジェクトごとにN行を読み込む必要があることです。または、N個のサブクエリを含む複雑なクエリを作成する必要があります。

誰もこの経験がありますか?誰もこのように大きなシステムを実装したことがありますか?通常のSQLのほかにデータを保持するための他のオプションはありますか?特に、モデルの変更を簡単に取り入れたり、モデルに「パッチを当てる」ことができるアジャイルシステムについて聞いてみたいと思います(通常、インスタンスには名前がありますが、一部の場合はコメントを追加したい) 。または、誰かがpost-SQLに何か遭遇しましたか?次の素晴らしいことは?

答えて

0

XMLデータベース(eXistなど)を見てください。 xmlスキーマを変更することで、簡単に "データモデル"を変更できます。また、XPathやXQueryなどの強力なクエリ言語を使用できます。

1

私はそれを使用していませんが、CouchDBのような種類の音をしようとしています。ホイールを改革する前に見てみたいです。

0

私はこの原則に基づいているわけではありませんが、ほとんどすべてのアプリケーションで、私はキーと値のペアのコレクションを使用します。他のエンティティには必要ないいくつかの追加プロパティが必要です。

私は基本的に辞書をシリアル化し、そのように私のエンティティデータを持つデータベースに格納します。これは、モデル全体の変更を保証するにはあまりにもあいまいなものに対処しなければならない時に、私がポストプロダクションのパッチを当てるために使用するものです。

キーと値のペアデータでは、型も保存するので、適切なHTMLコントロールを自動的にレンダリングできます。私はちょうど基本的な種類があります:テキスト、複数行、RTF、チェックボックス、番号と日付。

1

このアプローチは、Amazon SimpleDBによって使用されます。 ドメインを定義し、各ドメインには複数のキーと値のペアが含まれる行があります。このデータは「半構造化」と呼ばれます。

このアプローチにはいくつかの利点があります。あなたのアイデアのように、データベーススキーマを定義する必要はありません。新しいテーブルを導入したり、行単位で新しい列を作成したり、余分なテーブルとhas_many関係を作成する代わりに、複数の値を持つ列を作成することもできます。スキーマが変更された場合は、強制的に移行するのではなく、移行時にこれらの変更を導入することができます。

一方、リレーショナルモデルでは何十年もの開発を捨ててしまいます。あなたの索引付けがあまりにも一般的であるか存在しないので、出血速度になります。集約操作(グループ、結合)は非常に遅くなります。クエリの最適化は難しくなります。

Amazon SimpleDBとApache CouchDBは、データベースを高度に分散することでこの問題に対処しています。これにより、信頼性と冗長性が確保されますが、競合解消や古いデータなどの独自の問題があります。

あなたの質問から、あなたは「アジャイル」の方法で死んでしまっているようですので、私はそれらの2つのDBエンジンの1つをお勧めします。両方とも、完全に動的なデータベーススキーマが可能です。落とし穴に気をつけてください。

関連する問題