2

次のテーブルを含むデータベース（ペットシッター会社用）があります。

  • お客様
  • 緊急連絡先
  • 電話番号
  • 電話の種類

電話番号は別のテーブルに保存されるため、顧客ごとに事実上無制限の数の電話番号を効率的に保存できます。電話番号テーブルには、主キーに加えて、顧客 ID と電話タイプ ID の両方が格納されます。私の質問は、緊急連絡先が電話番号レコードと同じ機能を持ち、電話番号テーブル「緊急連絡先 ID」に別のフィールドを追加できるようにする最善の方法ですか? それとも、緊急連絡先を顧客と同じテーブルに保存する必要がありますか (そして個人の名前を変更します)? もしそうなら、同じテーブル内のレコード間の関係を作成する方法を教えてください。

どうもありがとう、ジェシカ

4

3 に答える 3

0

自問自答する必要があります: データの正規化ルールを尊重するには、実際にどこまで行く必要がありますか?

テーブルに何が含まれるかはわかりませんが、それがMobile、Work、Home、iPhonePhoneTypesのようなもののリストである場合、おそらくすでに少し行き過ぎているでしょう: あなたは連絡先アプリケーションを構築しているのではなく、構築していますペット シッティング アプリケーションの場合、おそらく開発時間を必要とするソフトウェアのより重要な領域があります。

ソフトウェアの複雑さを増すとコストがかかります。機能を実装するまでの時間が長くなる傾向があり、複雑さとともに、エラーのリスク、メンテナンスのコスト、そして多くの場合、パフォーマンスも低下します。

これらの連絡先の詳細は、実際にはお客様の所有物です。

顧客は、複数の電話番号と複数の緊急連絡先を持つことができます。
通常、これらは重要な順にリストする必要があるため、必要が生じた場合は、最も関連性の高い人に最初に電話します。

これ以上の情報がなければ、これを処理する方法は、アプリのユーザーが好きな方法でそのデータを入力できる Customer テーブルに 2 つのメモ フィールドを残すだけで、正しい順序でリストし、次のように注釈を付けることができます必要（月曜のみ、お客様のお母様、午前11時以降のみ、など）。

必要に応じて、データ入力をさらに制限することができます。たとえば、セミコンロンを使用するか、単にCrLfレコードを分離することにより、フィールドにデータを追加する「追加」ボタンをクリックする前に、ユーザーが詳細を入力するテキストボックスを用意することができます。次に、データをセミコロンまたは CrLf で分割し、フォームのリストボックスに表示して、見やすくすることができます。
お客様の電話番号と緊急連絡先番号の両方を同じように扱うことができます。

これにより、物事が簡単になります。すべての顧客データは、複数のテーブルに分割されるのではなく、1 つのテーブルにあり、不要な結合がなく、複数のテーブルを使用するよりも多くのスペースを必要としません (実際には、スペースを節約できます)。レポートが簡単になり (顧客リストを表示するだけで、特別なことをしなくてもすべての顧客の利用可能な電話番号がすべて表示されます)、検索も簡単になります。

1 つのフィールドに複数の値を持つことは、周辺データでは非常に一般的です。
連絡先を分離し、連絡先に基づいて複雑なレポートを作成したり、連絡先を再利用できることを確認したりする必要がない限り、すべての情報に対してテーブルを作成する必要はありません。アプリケーションのユーザーが顧客に関連するものを入力できるようにします。
データ入力を制限してフォーマットし、必要に応じて一貫性をチェックしますが、最終的には、ソフトウェアの目的が複雑な連絡先リストを維持することでない限り、必要以上に難しくしないでください。少しの VBA といくつかの文字列操作でデータを制限し、ユーザーにとって最も関連性の高い順序で再配置できるようにするだけで十分です。複雑さを回避することで、アプリをよりスマートにします。

とにかく、単純なものから始めて、データを複数のテーブルに分割することが理にかなっているのかどうかを後で確認します。
時期尚早の最適化は避けてください。

ただし、これを本で本当に処理する必要があると感じた場合は、おそらく次のように処理します。

Contact次のようなプロパティを持つテーブルにすべてを格納します。

  • ID: 一意の連絡先 ID
  • PhoneNumber： 文章
  • PhoneTypeID: (それが PhoneType テーブルにリンクしている場合は何でも)
  • IsEmergencyContact: ブール値
  • ContactName: TEXT、フリーフォーム、担当者の宛名の書き方
  • CustomerID: Customer テーブルにリンクする外部キー
  • Notes: MEMO、連絡先に関する有用な情報
  • Rank: INTEGER、この連絡先のソート可能な重要度

複数の顧客に連絡先を再利用できるように、顧客を連絡先から切り離したい場合は、中間テーブルが必要になります。

Contactテーブルは次のようになります。

  • ID: 一意の連絡先 ID
  • PhoneNumber： 文章
  • PhoneTypeIDPhoneType: (それがあなたのテーブルにリンクしている場合は何でも)
  • ContactName: TEXT、フリーフォーム、担当者の宛名の書き方
  • Notes: MEMO、連絡先に関する有用な情報

そしてCustomerContactテーブル (多対多の関係を可能にする):

  • CustomerID: Customer テーブルにリンクする外部キー
  • ContactID: Contact テーブルにリンクする外部キー
  • IsEmergencyContact: ブール値
  • Rank: INTEGER、この連絡先のソート可能な重要度

IsEmergency連絡先のリストと緊急連絡先のリストを表示および管理するには、true または falseに基づいて情報を表示する各リストボックスまたはサブフォームをフィルタリングするだけです。

同じ連絡先に複数の電話番号を持たせたい場合は、すべてをさらに分割する必要があります。

Contactテーブルは次のようになります。

  • ID: 一意の連絡先 ID
  • ContactName: TEXT、フリーフォーム、担当者の宛名の書き方
  • Notes: MEMO、連絡先に関する有用な情報

PhoneNumberテーブルには次のものが含まれます。

  • ID: 電話記録ID
  • ContactID: Contact テーブルにリンクする外部キー
  • PhoneNumber： 文章
  • PhoneTypeID: (それが PhoneType テーブルにリンクしている場合は何でも)
  • Notes: MEMO、この特定の電話番号に関する有用な情報

これで、必要なすべての情報を保存し、必要な方法で共有するための 4 つのテーブルができました。そのため、顧客は複数の連絡先 (緊急かどうかに関係なく) を持つことができ、連絡先は複数の電話番号を持つことができ、連絡先は顧客間で共有できます (つまり、1 人の顧客のcontact は別のお客様の緊急連絡先です):

  • Customer
  • Contact
  • PhoneNumber
  • CustomerContact

先ほど言ったように、正しい方法で行うと、実際に必要なよりもはるかに複雑になります。

時期尚早に複雑さを構築しないように注意してください。最悪のシナリオを予測するのは良いことですが、それは多くの場合、時期尚早に最適化し、アプリのコアほど重要ではないソフトウェアの領域に時間を費やしていることを意味します。
常に自問自答する必要があります: これを実装するのに 2 日間を費やすべきか、それとも UI の改良、データの整合性を確保するためのコードのテストまたは追加などに 2 日間を費やすべきか?

多くの場合、YAGNI

于 2013-08-22T02:04:33.710 に答える
0

あなたの最初の直感 (顧客と連絡先を 1 つのテーブルに格納すること) は正しかったです。考えてみれば、顧客も取引先も人です。ただ、お客様も緊急連絡先も特殊なケースです。これは、リレーショナル DB を使用してモデル化できます。

人に関する情報を保持するテーブルを作成しましょう。

create table tblPeople (
  ID autoincrement primary key
, FirstName varchar(100)
, LastName varchar(100)
, Notes memo
)

次に、顧客に関する情報を保持するテーブルを作成しましょう。ただし、顧客も人でなければならないという事実を強制します。

create table tblCustomers (
  ID long primary key
  constraint Customers_ID
  references tblPeople (ID)
, EmergencyContactID long
  constraint Customers_EmergencyContactID
  references tblPeople (ID)
)

これは1 対 1 の関係と呼ばれ、オブジェクト指向プログラミングにおける継承のような特殊化を実装するために使用されます。

ここで選択肢があります。各人に、任意の種類の任意の数の電話番号を持たせたいですか? これは明らかにより一般的で強力です。しかし、より複雑でもあります。それとも、前に戻って、各ユーザーの固定数の電話番号を保存しますか?

前者を最後までやりたいとしましょう。その場合、電話番号を保持するテーブルが必要です。

create table tblPhoneNumbers (
  ID autoincrement primary key
, PhoneNumber varchar(15)
)

ここでは、電話番号の種類について何も指定していないことに注意してください。その部分は次のとおりです。

create table tblPhoneNumberTypes (
  ID autoincrement primary key
, PhoneNumberType varchar(20) not null
)

次に、各個人を電話番号とタイプに関連付けます。

create table tblPeople_to_PhoneNumberTypes_to_PhoneNumbers (
  PersonID long not null
  references tblPeople (ID)
, PhoneNumberTypeID long not null
  references tblPhoneNumberTypes (ID)
, PhoneNumberID long not null
  references tblPhoneNumbers (ID)
, constraint People_to_PhoneNumberTypes_to_PhoneNumbers_PK
  primary key (
    PersonID
  , PhoneNumberTypeID
  , PhoneNumberID
  )
)

ここでは、各人 (したがって、各顧客と各緊急連絡先) は、任意の種類の任意の数の電話番号を持つことができます。したがって、これは実際には多対多対多のリンク テーブルです。それが連絡先電話タイプ電話番号モデルの鍵 (または「秘密のソース」としましょう) だと思います。

上記のようなリンク テーブルでは、整数の主キー列には有用な目的がないと感じているため、複数列の主キーを使用することを好みます。ここで、主キーは、個人と電話番号の各組み合わせを 1 つの電話番号タイプで 1 回だけリストする必要があるという事実を強制します。

上記はすべて有効な Access ANSI-92 SQL であることに注意してください。

于 2013-09-28T18:15:54.413 に答える
0

電話番号を保存するのと同じ方法で保存します。独自のテーブルで。これにより、複数の番号を保存することができ、一部の人は複数の緊急連絡先番号を持っている場合があります。データベースを設計するときは常にスケーラビリティについて考え、最も複雑な状況に備えて計画する必要があります。たとえば、ペットシッターの場合、多くの顧客が口コミでやってくると想像できます。また、複数のクライアントに同じ連絡先を使用する可能性が非常に高くなります。

于 2013-08-22T01:09:44.780 に答える