データベーステーブルに主キーがなくてもかまいませんか？
リレーショナルデータベース（MySQL/SQL SERVERなど）のテーブルに主キーがなくてもかまいませんか？
たとえば、テーブルday_temperature、ここでtemperatureとtimeを登録します。このようなテーブルの主キーを持つ理由がわかりません。
技術的には、このようなテーブルを宣言できます。
しかし、あなたの場合は、timeをPRIMARY KEYにする必要があります。同じ温度で異なる温度を設定することはおそらく間違いであり、同じ温度を複数回使用するのは無意味です。
論理的には、2つのレコードを区別できるように、各テーブルにはPRIMARY KEYが必要です。
データに候補キーがない場合は、サロゲートキー（AUTO_INCREMENT、SERIAL、またはデータベースが提供するもの）を作成するだけです。
PRIMARY KEYを持たない唯一の言い訳は、重いDMLの対象となるログまたは同様のテーブルであり、インデックスを持っていると、許容範囲を超えてパフォーマンスに影響します。
いつものように依存する。
テーブル持たない主キーを持つ。 はるかに重要は正しいインデックスを持つことです。データベースエンジンでは、主キーがインデックスに影響する（つまり、主キーの列に一意のインデックスを作成する）に依存します。
ただし、あなたの場合（および他の99％の場合も）、私は新しい自動インクリメントの一意の列を追加 like temp_idそして、それを代理キーにします。
それはるかに簡単になりますこのテーブルの維持-たとえば、レコード（重複したレコード）の検索と削除-そして私を信じて-すべてのテーブルで問題を修正する時が来ます:(。
本来、主キーは時間ではないでしょうか？一定の時間に複数の温度がありますか？
より良い質問は、「なぜテーブルを作成するのですかwithout主キー」
エントリが重複する可能性（たとえば、同時に）が問題にならず、特定のレコードまたはレコードの範囲を照会する必要がない場合は、どのような種類のキーも使用しなくてもかまいません。
PKは必要ありませんが、持っていることをお勧めします。一意の行を識別するのに最適な方法です。場合によっては、自動インクリメンタルint PKが必要ではなく、他の何かにPKを作成することがあります。たとえば、あなたの場合、時間ごとに一意の行が1つしかない場合、その時間にPKを作成する必要があります。時間に基づいて検索を高速化し、さらにそれらが一意であることを保証します（データの整合性が侵害されていないことを確認できます）。
特に、時間/温度の測定値が重複する可能性がある場合は、代理/自動インクリメントキーを含めます。重複する行を一意に識別する他の方法はありません。
あなたの答えによれば、私は3つのオプションを検討します：
- 両方の列にPKを配置します。この方法では、一時点が1つしかなく、その逆も同様です。このソリューションでは、同じ臨時AND時刻の2つの行が存在しないというだけで、同じ臨時または同じ時刻の複数の行を許可します。
- pKをまったく配置せず、両方の列に一意のインデックスを配置します。両方の列を含む1つの一意のインデックス。これにより、一時および時間でNULLが許可されますが、インデックスを維持するためにより多くのスペースが必要になります。
これらの2つのオプションは、読み取りが多い場合の検索速度に最適ですが、インデックスも更新する必要があるため、挿入率が低くなります。
- インデックスもPKも付けないでください。これは挿入には最適ですが、検索には非常に悪いでしょう。取得が別のメカニズムによって行われるロギングや、デバイスの挿入が重複をチェックする必要がない場合にログに役立ちます。
また、ここでカーディナリティを考慮し、自動インクリメントされた番号を使用した場合の将来の結果について考えることも非常に重要です。 A LOT OF挿入を行うことを計画している場合、自動インクリメントされた符号なしbigintでさえ、最終的には実行されないため、リスクになります。あなたの例では、毎日データを保存すると思います-どのくらいの期間ですか？毎分tempを保存すると問題が発生します...極端な例としてこれを取り上げます。
テーブルから必要なものを考えるのが最善だと思います。あなたは、毎分一時的に一年中「保存して忘れる」ことをしていますか？このテーブルをビジネスロジックのリアルタイムの意思決定で頻繁に使用しますか？リアルタイム（oltp）に必要なデータを、めったに必要とされない長期保存データから分離するのが最善であり、その検索レイテンシは高く（許可）できると思います。データを2つの異なるテーブルに複製する価値があります。1つは重度にインデックス付けされ、カーディナリティを制御するために時々消去されます。メインfsから別のfsへ）。
その後、時間が主キーになります。日付範囲などに基づいてデータをクエリできるように、その列にインデックスを付けるのに役立ちます。 PKは最終的に行を一意にするものであるため、この例では、日時はPKです。
Mysqlでデータベースを複製するとき、プライマリキーのないテーブルは複製の遅延を引き起こす可能性があります。
http://lists.mysql.com/mysql/227217
ROWまたはMIXEDを使用する際の最も一般的な間違いは、レプリケートするすべてのテーブルにプライマリキーがあることを確認できないことです。これは間違いです。ROWイベント（上記のようなイベント）がスレーブに送信され、マスターのコピーもテーブルのスレーブのコピーもテーブルにプライマリキーがない場合、どのキーを簡単に識別する方法がないためです。複製を変更する一意の行。
私がやったテーブルの1つで同じ質問に出くわします。
問題は、PKがテーブルのすべての行から構成されることになっているということでしたが、これは、各行が挿入されるとテーブルサイズが非常に速く成長することを意味します。
PKを持たないことを選択しますが、ルックアップを行う行にのみインデックスがあります。