フィットネス/ウェイトリフティングルーチンデータベースの設計
私は実際にAndroid用の Barbell Pro に似たアプリを作成したいのですが、実際には、興味/教育目的のためです。または、データベース目的の別の例として、 Fitocracy
問題は、データベースの設計方法がわからないことです...例：
- アプリを使用している1000人のユーザーがいます
- 各人は、日に応じて1〜7個の個別のWorkoutRoutinesを持つことができます。 （おそらくさらに-> AMワークアウト/ PMワークアウト）
- 各WorkoutRoutineには個別のエクササイズのセットがあり、いくつかのクロスオーバーがあります。誰かが月曜日と金曜日にベンチプレスをすることができた。
- 各練習にはいくつかのセットがあります
- 各セットには多数の担当者がいます
今、私には、これは各人のために保存する大量の情報である可能性があり、そうすることはかなり複雑かもしれないようです。
私はリレーショナルデータベースの経験が少ししかないのですが、リレーショナルデータベースの効率的な問題でそれをどのように設計すればよいのかわかりません。
私はデザインを求めるのではなく、どうやってそれを始めるのかを考えています。データベースの経験がないため、潜在的な複雑さは私にとって困難です。
多分それはそれほど複雑ではないかもしれませんが、私が言うように、私自身からの無知です。
これがプロトタイプのデータベーススキーマです。さまざまなエクササイズルーチンの作成を可能にし、それらのルーチンを日付によって人に割り当て、実行されたエクササイズと担当者の数を記録する場所さえあります。
最初にデータベースを設計しないでください。最初のスキーマに基づいて必要なすべての変数とテーブルを理解するのが難しいと思われる場合は、間違ったところから直接問題にアプローチしている可能性があります。
代わりに、データベースを設計してください何か保存するものがある場合、特に、要約または後者に対してクエリを実行するもの。 JSONまたはXMLをディスクに書き込むだけで、テキストファイルが必要なすべてになることがわかるでしょう。または、ルーチンごとにXMLまたはJSONのblobを保存し、ルーチンを照会、結合、および要約できるようにすることもできます。または、XMLとJSONは、その価値があるほど厄介で、実際に必要なのはいくつかのリレーショナルテーブルだけです。
すでにクライアントアプリケーションを停止していて、フィットネスセンターのクライアントのすべての情報を格納するデータベースサーバーで作業したい場合は、次の手順に従います。
- 実際にストーリー化およびクエリする必要があるものを特定します。前に触れたように、生データに対してクエリを実行しない場合は、Java内のデータオブジェクトのJSONまたはXMLシリアル化が最善の策になる可能性があります（ただし、ファイルが大きすぎて
CHARに収まらない場合は、データベースに応じて、テキストを「メモ」または「ブロブ」フィールドにいつでも保存できます。） - 繰り返される情報を探します。ここでは、複数のフィールドをいくつかの推定アイテムにリンクできます。つまり、2つ以上のフィールドを、出身地との1対1の関係。あなたが質問にリストしたものは、最初からかなり公正な出発ですが、あなたはもっと見つけるかもしれないし、あなたのスキーマをあまりに複雑にしたことに気付くかもしれません。
- 各テーブルについて、すべてのレコードに対して不変で一意になる正しい一意のキーを決定します。 IDまたは同様のメカニズムを介して仮想キーを作成することを恐れないでください。まだパフォーマンスにこだわらないでください。自然キーが仮想キーよりも優れていると思われる場合は、先に進んで使用してください。
- すべてのフィールドとテーブルに明確で明確な名前を付けます。キーの名前はデータベース全体で一意である必要がありますが、セカンダリフィールドは一意である必要はありません。 （もちろん、そうすることで害はありません。）
- 上記のすべてを手に入れて、初期データベース設計を行います。サンプルデータを送信できるいくつかのテーブルを取得し、適切なテストデータを入力したいとします。
- データベースが完成したら、アプリケーションのデータアクセスレイヤーをコーディングします。これにより、アプリのネイティブフォームのデータが読み取られ、データベースが受け入れることができる何らかの方法でネイティブフォームが送信されます。
- いくつかのコードが機能し、適切なデータを書き込み、期待したレコードを取得できるようになったら、開発データベースにサンプルデータをロードします。これは完全に架空のものか、ベータテスターからの情報、またはその両方の組み合わせです。そこに、予想される数年分のデータを自由に投入してください。以上。
- テーブルにいくつかの重要なデータが含まれているデータベースでは、データベースを最適化します。キーの追加または調整、一部のテーブルの正規化ビューへのリファクタリング、または一部のフィールドのデータ型の微調整が必要になる場合があります。数値とテスト容易性はあなたの友人であり、あなたのガイドになるはずです。
自分が一歩後退したり、順不同だったりするのを恐れないでください。できる限りプロバイダーに依存しないデータベースを維持してください。必要に応じて、設計の要求に応じて、SQLiteからMonoDB、MSSQLに切り替えることができます。
ボーナスラント
何をするにしても、リレーショナルデータベースに精通していない場合は、これを強調することはできませんKEEP YOUR TABLES NARROW。 set1Repsやset2Repsなどのフィールドを同じテーブルに追加しないでください。これはコード臭の頭痛の種であり、非対称データまたは明確で異なるサブテーブルを格納するための内部XMLまたはJSONフィールドが必要であることを示す大きな兆候です。
なんらかの理由で非常に広いレコードセットが必要で、フィールドをループして単一のデータオブジェクトに割り当てることができる場合は、ビューと巧妙なSQLを使用していつでも実行できます。しかし、その場合は、とにかく、データオブジェクトの多くをシリアライズおよびシリアル化解除する方がはるかに良いでしょう。
データベースから設計を開始しないでください。だれがどのように、どのように使用するかがわかったら、すべてが間違っているスキーマに閉じ込められます。要件から始めて、要件を証明するテストを記述し、テストに合格するコードを記述し、スキーマを完全に落とします。
開発を数回繰り返した後、JSON/MongoDBが要件に適していると判断する場合があります。または、すでに作成された優れたスキーマを見つけるかもしれません。または、HTML5ローカルストレージが必要なすべてであると決めるかもしれません。
グリーンフィールド（新規）アプリケーションの場合、スキーマは実装の詳細です。それについて心配しないでください。
私の2セント：
- トレーナーをサポート
- 計画作成者をサポート
- ルーティンを作成した人をサポート
- 運動計画は、数週間の間に実行されるいくつかのルーチンで構成されています
- 各エクササイズルーチンには、優先される平日があります
- 人はその存続期間中に多くの運動計画を実行でき、1つの運動計画を多くの人が実行できます
