質問
1) Web アプリケーション、具体的にはデータベース スキーマを設計する適切な方法を探しています。これにより、特定のサービスのすべてのコア フィールドを含むベース テーブルを作成できるようになり、サービスの種類に応じて、サービスに関連付ける追加のフィールド セットが必要になります。
検索の実行が簡単で、妥当なパフォーマンスが得られるような方法でこれを行う必要があります。私はおそらくある種の全文検索を検討していますが、アプリケーションの同時ユーザーはせいぜい 5 人しかいないでしょう。
このアプリケーションの最終的な目標は、データベース全体で任意のキーワードを検索し、関連するすべてのレコードを返すことです。最初は、サービスの種類ごとに設定されたフィールドを、独自の列を持つ個別のテーブルに分割することを検討していましたが、そうすることで、より複雑な検索クエリ (多くの JOIN) や、より多くのクエリが実行される可能性があると考えています。検索ごと。
提案された解決策について、これが適していると考える理由を教えてください。
2) 私のもう 1 つの問題 (うまくいけば以下で明らかになるように) は、私の設計が現在、各製品のコア タイプを定義する「サービス タイプ」テーブルで構成されており、各サービスが特定の製品の「インスタンス」であることです。 .
ここでの問題は、製品とサービスの種類のテーブルの両方がある場合、ほとんどの重複が発生する可能性があるということです。したがって、この重複を避けることは、私が設計で達成しようとしているもう 1 つの主なことです。
詳細
私は現在、請求 (請求サイクル、開始日/終了日、価格) だけでなく、それらのサービスの文書化 (関連するユーザー アカウント、IP住所、物的資産など）。
各サービスは、基本製品の名前、価格、請求期間、説明などを定義する「製品」テーブルに基づいています。タイプ）。たとえば、次の製品があります。
- 共有 Web ホスティング プラン 1
- 共有 Web ホスティング プラン 2
- 共有 Web ホスティング プラン 3
- 専用サーバープラン
- 仮想専用サーバー プラン1
- 仮想専用サーバー プラン 2
現在、私が抱えている問題は、特定のサービスに共通するフィールドがいくつかありますが、追跡されるサービスの「タイプ」に応じて変化するフィールドもいくつかあるということです。サービスの種類に応じて、すべてのサービスの基本フォームを表示しますが、追加/編集などに適したフォームも表示します...
たとえば、次のサービス タイプがあり、各製品 (上記のように) はこれらのコア サービス タイプのいずれかに関連付けられます。
- 共有ウェブホスティング
- 専用ホスティング
- 仮想専用ホスティング
- ADSL
- ...
私の可能な解決策
現在のソリューション - 複数のテーブル
現在、私のデータベースには次のものがあります。
サービスの種類
- ServiceTypeID INT PK
- タイプ VARCHAR(40)
製品
- 製品 ID INT PK
- 名前 VARCHAR(40)
- 説明 テキスト
- 価格小数
- BillingDuration INT
- TypeID INT (FK ServiceTypes.ServiceTypeID)
サービス
- ServiceID INT PK
- ProductID INT (FK: Product.ProductID)
- 名前 VARCHAR(40)
- 説明 テキスト
- 価格小数
- BillingDuration INT
- アクティブビット
- 開始日DATETIME
- 終了日DATETIME
これらはすべてのサービスのメイン テーブルであり、拡張プロパティ用の追加テーブルがあります。
サービスADSL情報
- ServiceADSLInfoID INT PK
- ServiceID INT (FK: Service.ServiceID)
- FNN VARCHAR(10)
- ユーザー名 VARCHAR(20)
- パスワード VARCHAR(20)
- LocationID INT (FK: Locations.LocationID)
- ModemAssetID INT (FK: Assets.AssetID)
ServiceVirtualServerInfo
- ServiceVirtualServerInfo INT PK
- ServiceID INT (FK: Service.ServiceID)
- サーバー名 VARCHAR(20)
- IPAddress INT (FK: IPAddresses.AddressID)
- HostServer INT (FK: Assets.AssetID)
- ユーザー名 VARCHAR(20)
- パスワード VARCHAR(20)
ServiceSharedHostingInfo
- ServiceSharedHostingInfoID INT PK
- ServiceID INT (FK: Service.ServiceID)
- ホスト名 VARCHAR(50)
- HostServer INT (FK: Assets.AssetID)
- DiskSpaceQuotaINT
- 帯域幅クォータ INT
その他の解決策 - 単一のテーブル
サービスの種類に関係なく、すべてのサービス関連情報を単一のテーブルに格納し、その特定のサービスに必要ない場合は値を NULL にすることを考えています。
- ServiceID INT PK
- ProductID INT (FK: Product.ProductID)
- 名前 VARCHAR(40)
- 説明 テキスト
- 価格小数
- BillingDuration INT
- アクティブビット
- 開始日DATETIME
- 終了日DATETIME
- ユーザー名 VARCHAR(20)
- パスワード VARCHAR(20)
- FNN VARCHAR(10)
- LocationID INT (FK: Locations.LocationID)
- AssetID INT (FK: Assets.AssetID)
- ...
サービス関連のデータを提供するために、単一のテーブルで全文検索を使用するだけでよく、レコードを結合することを心配する必要がないため、これは検索の観点からも扱いやすいソリューションであると思います。
ここでの私の主な懸念は、30 列以上のテーブルになってしまうことです。もう 1 つのことは、特定の検索にどのフィールドを使用する必要があるかを把握するためにコアの serviceTypes テーブルが必要であるため、両方の懸念が解決されないことです。
products テーブルとのある程度の重複は避けられないのでしょうか?
エンティティー属性値モデル
このデザインも検討しました。全体として、物事をそれほど柔軟で動的にする必要がないので、これはやり過ぎだと感じています。サービスの種類に応じて一連のフィールドのグループが必要になりますが、コア サービスの種類ごとに収集する必要があるデータはすぐに変更されるとは思えないため、これは静的である可能性があります。
また、このレベルの柔軟性を実装するために必要なアプリケーション ロジックは、それがもたらすメリットに対して複雑すぎるように思えます。
データベースなどから照会されたフィールドのタイプに応じて、表示する HTML フォーム フィールドのタイプを決定しなければならないということは、苦痛に思えます。
私が提供できる詳細があれば教えてください！すべてが明確であることを願っています。
ありがとう！
