3

だから私は私が作成しているこのアプリケーションを持っていて、私は自分のユーザーについて考え始めます。さて、私の最初の考えは、グループタイプごとにテーブルを作成することでした。私はこれを考えてきましたが、これが最善の方法かどうかはわかりません。

例：

// Users

Users [id, name, email, age, etc]

// User Groups

Player [id, years playing, etc]

Ref [id, certified, etc]

Manufacturer Rep [id, years employed, etc]

したがって、全員がアカウントを作成しますが、ユーザーごとに異なるグループがあります。また、複数の異なるグループに属することもできます。各グループには、異なる列の独自のリストがあります。では、これを行うための最良の方法は何ですか？5つのグループがあるとしましょう。8つのテーブルとそれぞれをユーザーテーブルに接続するリレーショナルテーブルが必要ですか？

ビルドする前に、これが整理するための最良の方法であることを確認したいだけです。

編集：プレーヤーには、プレイに使用するギア、プレイしたチーム、行ったイベントに関する列があります。

refには、彼らが持っている認定と彼らが参照したイベントに関する情報があります。

メーカーの担当者は、担当する会社内での自分の位置に関する情報を持っています。

親は、彼らがスポーツに関わってきた期間、おそらく彼らが親であるユーザーとの関係についての情報を持っているでしょう。

例として。

編集2：

**Player Table
    id
    user id
    started date
    stopped date
    rank
**Ref Table
    id
    user id
    started date
    stopped date
    is certified
    certified by
    verified

**Photographer / Videographer / News Reporter Table
    id
    user id
    started date
    stopped date
    worked under name
    website / channel link
    about
    verified

**Tournament / Big Game Rep Table
    id
    user id
    started date
    stopped date
    position
    tourney id
    verified

**Store / Field / Manufacturer Rep Table
    id
    user id
    started date
    stopped date
    position
    store / field / man. id
    verified

これは私がこれまでに計画したものです。私はまだこれに慣れていないので、完全に間違っている可能性があります。そしてそれはたった5つのグループです。少し凝縮するまではもっとでした。

4

2 に答える 2

1

互いに異なるエンティティが非常に多いのは奇妙に思えますが、これを無視して質問に進みます。

必要なグループ基準によって異なります。各グループに独自の列と情報がある場所を説明した場合、特にデータベースで読み取り可能な形式の情報が必要な場合は、設計が適切であると思います。単一のテーブルにすべてのグループが必要な場合は、グループに関連する情報を一種のオブジェクト (blob、XML 文字列、またはその他の形式) に保存する必要がありますが、データベースを使用してこれらの基準でフィルター処理する機能が失われます。 .

リレーショナルデータベースでは、あなたが説明した設計を使用してそれを行います。

于 2013-01-09T06:00:03.153 に答える
0

テーブルのデザインは、ソフトウェアの要件に大きく依存します。

たとえば、ユーザーの説明が間違った方向に私を導いた場合、私は最初、ソフトウェアの「通常の」ユーザーについて考えていました。基本的に名前、ログイン情報など。これは、ログイン、セッション処理などのタスクを実際に複雑にするため、異なるテーブルに分割することはありません。

私を驚かせたもう1つのポイントは、それらのユーザーのテーブルの列に機器を格納したいということでした。通常、人とその機器の関係は1対1ではなく、ほとんどの場合、さまざまな機器の数は異なります。したがって、通常、ユーザーとその機器の間には関係があります（1：n）。したがって、機器テーブルを設計し、そこに所有者のユーザーIDを参照します。

ただし、アプリケーションにどのデータがあり、どの関係がデータ間に存在するかを理解した後は、テーブルの設計などはかなり単純です。

良いニュースは、データモデルとデータベース設計が時間の経過とともに発展することです。ユースケースの大部分をカバーする基本モデルから始めてみてください。次に、ユースケース/アスペクトをゆっくりと追加します。計画と初期の実装段階にある限り、データベース設計を変更するのはかなり簡単です。

于 2013-01-09T07:05:07.497 に答える