1

サービステーブルがあります。各サービスは、1 つのメイン カテゴリと 1 つのサブ カテゴリによって定義されます。

例えば、

Service = Joe's Web Company、MainCategory = 情報技術、SubCategory = Web 開発

提供される各サービスには、共通のプロパティ セット (コスト、場所など) があります。

各サービスには、SubCategory に固有の一連の属性もあります。

したがって、上記の例では、Joe's Web Company は次の属性を持つ可能性があります: PHP(BOOL):1、MySql(BOOL):0、Javasctipt(BOOL):1 など

または、アクターの場合、次の属性を持つ場合があります: EyeColour(ENUM): Blue、Height(float): 5.11

したがって、スーパータイプ/サブタイプの関係が最もうまく機能すると考えていますが、500 を超えるテーブルについて話している可能性があります。

また、メイン カテゴリ全体でサービスを検索できるようにする必要もあります。このために、マスター サービス テーブルにキーワード列を作成することを考えていたので、各サブタイプのテーブルを検索する必要はありません (一部のカテゴリには 50 のサブタイプ/テーブルがある場合があります)。私は毎晩スクリプトを実行して、各サービスのサブタイプの属性を説明するテキストをこの列に入力します (たとえば、Joe のキーワード列には「PHP Javascript」が含まれます)。

このアプローチは問題ないように見えますか?それとも、テーブルの数を考慮すると、EAV ソリューションの方が適しているでしょうか?

4

3 に答える 3

0

ドキュメント指向のdbmsは良い提案だと思います。CouchDB/ PHPまたはMongoDb / PHPを参照してください。RDFが頭に浮かぶグラフデータベースの方がいいと思います。PHPで2つの実装を見つけましたが、自分で試したことはありません。EasyRDFとRAPです。

于 2009-10-14T09:41:06.877 に答える
0

500以上のテーブルを作成するのは道だとは思いません。あなたの構造は純粋にリレーショナルではなく、「スキーマレス」であるように見えます。専用のドキュメント指向の dbms (Mongodb、Tokyo Cabinet) を検討するか、低レベルのデータ ストレージとして mysql を使用して独自の dbms を展開します ( http://bret.appspot.com/entry/how-friendfeed-uses-を参照)。 mysqlが優れた例です)。

于 2009-10-13T23:30:21.770 に答える
0

ある種の2番目の質問..

ドキュメント指向の dbms ソリューションが開発/維持するにはトリッキーすぎることが判明した場合、これはどのように代替ソリューションを探しますか?

サブカテゴリに属性バンドルがあると、デザインのスキーマがなくなります。属性バンドルをメイン カテゴリ レベルに移動するとどうなるでしょうか。いずれにせよ、各サブカテゴリ内の多くの属性は、他のサブカテゴリと共有されます。これの欠点は、完全に一意のサブカテゴリがメインの猫の他のすべてのサブカテゴリにその属性を課すことですが、一意のサブカテゴリでのこれらの属性の使用を制限することができます. アプリケーションロジックを使用して、サブカテゴリが使用できる属性などを決定できます..

基本的に、この代替アプローチは従来のリレーショナル スーパータイプ/サブタイプ モデルを使用しますが、かなり幅広いサブタイプを使用します。

ps: 十分なクレジットを獲得したら、あなたの回答に投票します! あと2つ必要です(笑)

于 2009-10-14T11:03:10.423 に答える