アプリケーションはユーザーとオブジェクトを処理し、ユーザーは3つの機能（機能ごとに1つの評価）でオブジェクトを評価します。
編集：最後の文は不明確です：機能によって私はすべてのオブジェクトによって共有される基準を意味します
そのようなシステムのデータベースをどの程度効率的に設計しますか？評価システムを扱うデータベースを設計するためのベストプラクティスは何ですか？
私が考えていたもの：
テーブル：
と関係：オブジェクトには多くの
ユーザーは多くを持っています
評価する評価機能の数を増減しないと仮定すると、ユーザー、製品、および 3 つの列 (機能ごとに 1 つ) を追跡する評価の単一のテーブルを作成します。
したがって、Users テーブル、Objects テーブル、および結合された主キーとして UserID と ObjectID を持つ Ratings テーブルがあり、ユーザー標準ごとにオブジェクトごとに 1 つの評価を適用することができます。
各テーブルには、処理する必要があるものに直接関連する情報のみが含まれるように、データをカプセル化する必要があります。リンク テーブルを作成して、異なるデータ セット (この場合はユーザーとオブジェクト) 間の関係を提供します。
次のテーブルを作成します。
ユーザー- ユーザーの基本情報: ログイン、パスワード、ユーザー ID など、必要なもの。
オブジェクト- 評価するオブジェクト: その名前/ID および属性。
フィーチャー- ある種のフィーチャー名/ID を含む、フィーチャーのタイプを説明するテーブル。これは 3 つの主要なタイプから始めることができますが、いつでもこれを拡張/変更できます。各オブジェクトが評価に使用できる機能をカスタマイズすることもできます。
ObjectFeature - オブジェクトと機能のリンク テーブル。各テーブルの主キーを含み、2 つの間に多対多の関係を作成します。
UserRating - ObjectFeature と User の間の別のリンク テーブル。これら 2 つのテーブルの主キーと、割り当てられた評価が含まれます。
リレーショナルの観点からは、これはあなたが提示したものよりもデータを整理するための優れた方法です。その設計により、データの各セットがどのように接続されているかが明確になり、拡張性が向上します (たとえば、評価する機能を追加する、別のオブジェクトに評価する機能が異なるなど)。
非常に奇妙なデザインだと言わざるを得ません。検討：
Object: ID, ...
// Provided features cannot be shared between objects
ObjectFeature: ID, ObjectID, ...
User: ID, ...
UserObjectFeatureRating: UserID, ObjectFeatureID, Rating