私はSQL Serverを初めて使いました。本当にありがとうと思います。この列を主キーとして設定できますか？
医療提供者であり、内部では各患者にIDを割り当てます（たとえば、1234）。私は現在、別のデータベースを構築しています。私たちの内部IDをプライマリキーとして使うことはできますか？もしそうなら、プライマリキーの計算を行うつもりはないので、それらをプライマリキーのstring/charデータ型に設定できますか？
プライマリキーの条件は、キーがテーブル内で一意であり、決してNULLでないことです。
お客様の患者IDには、次のような特性があるようです。
しかし、合成プライマリキー（データベースに応じて自動インクリメント/アイデンティティ/シリアル）を開発するのには良い理由があります。さらに重要なのは、実際の患者IDは機密情報である可能性があります。例えば、患者はログイン時にIDを使用するか、請求書に印刷される可能性があります。
機密情報をデータベース全体で繰り返すことはお勧めできません。このため、「内部」IDはテーブル内の患者を参照するために使用され、すべての機密情報は1つまたは少数のテーブルに格納されます。
「患者ID」が政府のID（「社会保障番号」）または電子メールアドレスであった場合、これはおそらくより明白になります。
要するに、そうかもしれませんが、はまったくお勧めできません。
はあなたにいくつかの頭を与えるまで：
もしあなたが何かを見つけるのに使いたい外部キーを持っているなら患者のために別の列を作成し、UNIQUE Constraintを追加します。それはdoesnの - はい
http://pilpag.blogspot.dk/2016/06/relational-database-designsimple-rules.html
が、IDはまた、数値主キーになります はちょうど
は、より多くの情報のための私のこの記事を読んで、その列のインデックスを追加することを忘れないでください文字列でなければならない。 IDがユニークである限り、あなたは大丈夫です。
はい、内部IDは一意であれば使用できますが、PK制限はchar/varcharデータ型では900バイトです。したがって、IDがintの場合は問題ありません。しかし、あなたのIDが時間とともに変化したり、複数の患者のためにそれらを再利用することができれば、混乱を避けるためにIDを使用しないことを強く推奨します。私はアイデンティティのような代理キーを好む
私が正しく理解しているならば、あなたはそれらを一意に識別するために各患者に番号を割り当てています。したがって、レポートには、あいまいな患者の名前だけでなく患者番号が含まれています。患者番号を変更することはありません。これは、すべてのデータベースでこれを変更しなければならず、依然として必要な患者のすべての文書を再印刷する必要があるからです。これにより、この番号はデータベースの患者テーブルの完全な主キーになります。
あなたでし代わりに、テーブルの主キーとして生成された技術的なIDを使用して、それが一意にまだビジネスキーであるので、静止画のみのコースのユニーク制約を持つことになり、テーブル内の別のフィールド（と患者数を持っています患者を特定する）。これを行うかどうかは、主に個人の好みや経験の問題です。私はID以上のナチュラルキーを好んでいます（私はでプライマリキーになります）。これは、ナショナル・キーがより高速な照会、データの一貫性の向上、および保守の容易化をもたらすことが証明された、数千のテーブルと多くの階層を持つかなり大きなデータベースで作業したことに起因します。しかし、他の人は異なる経験をしているかもしれません。
はい、患者番号は私の意見では完璧な自然な主キーと思われます。
「ID」が常に数値の場合は、「整数」型になります。整数型は、それらに対してある程度の計算を行う必要があるわけではありません。整数は、 'Varchar'よりも結果を照会または順序付けするときに役立ちます。 –
IDとして定義された' INT'データ型は他の型よりも一般的で高速です。 –
何かをプライマリキーとして使用することに注意してください。プライオリティキーが単なるキー以外の何かを意味する可能性がある場合は、注意してください。 「内部ID」が変更されるためにキーを変更する必要がある場合や、その他の理由で外部キーに依存する場合は、通常のフィールドとして定義し、データベース生成キーを使用する方がよいでしょう。 – trincot