質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

SQL

SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

Q&A

3回答

5074閲覧

同じテーブルにユニークインデックスを2つつけるのは、DB設計上よくないでしょうか?

qaz3330

総合スコア113

MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

SQL

SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

2グッド

2クリップ

投稿2016/10/10 11:19

レコードのユニーク性を担保するため、ユニークインデックスを一つつけておりました。

しかし、業務要件上、一つでは事足りなくなったため、もう一つユニークインデックスをつける予定です。

2つ以上、ユニークインデックスをつけて運用したことがないため、一般的にこういうDB設計はよくないのかどうかご意見を伺いたく存じます。

宜しくお願いします。

Userテーブル uuidとarticle_idでユニークインデックス uuidとipadressでユニークインデックス <= こちらを新たに付与

一部、経緯などは省略しておりますが、uuidとarticle_idとipadressの3つで一つのユニークインデックスをかけるのは要件にみあわないため、2つつける方向で考えております。

KiyoshiMotoki, garasya👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

coco_bauer

2016/10/10 12:43

uuidはUniversally Unique Identifierですから、uuidだけでユニークインデックスのはずですが、「uuidとarticle_id」や「uuidとipadress」が必要なのですか?それは、article_idとipaddressがいずれもユニークインデックスではない(重複を許す)運用をするという事なのでしょうか?
qaz3330

2016/10/10 12:56 編集

カラム名の記載が悪く、誤解を招いてしまったのですが、uuidにあまり意味はありません。クライアント案件のため、あまり情報を詳しく開示できないため、仮のカラム名を入れております。そのため、実際にはuuidとは別のidになります。
guest

回答3

0

あえてテーブル設計のテンプレに則った意見を言いますと、
複合ユニーク制約キーが複数あるということは、
1テーブル内で複数の関連を保持していることを意味する可能性が高いので、
正規化した方が良いのでは、という意見は出てくるのかなと思います。

恐らくですが今回のテーブルだと正規化を極力推し進めた形としては、
0. ユーザマスタ
0. 記事投稿テーブル
0. ユーザ端末テーブル(IPアドレスとか保管)

のようなテーブル構成イメージになるかなと思います。
(※予想なので見当違いならすみません^^;)

上記の構成を取ると、

  • ユーザIDで一意
  • ユーザID、記事IDで一意
  • ユーザID、IPアドレスで一意

とそれぞれのテーブルで、
自然キーを主キーとした一意制約が実現可能となります。


ただし上記は理想論のお話ではあり、
実際は例示されたテーブルには既に多くのデータが格納されているとも思われますので、
1つのテーブルで複数ユニーク制約を張るという対応で良いのかなとは思います。

投稿2016/10/11 13:21

編集2016/10/11 13:26
Panzer_vor

総合スコア1636

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

たとえばユーザー管理テーブルでauto_incrementのprimary keyとしてidを用意するとともに
useridをユニークにすることはあります。
この場合意味合いとしてprimary keyのidはレコードを確定させるためのもので
永久不変ですが、useridはユーザーをユニークに管理するものなので途中で変更
させることもできるという運用上の違いがあります。

投稿2016/10/11 00:43

yambejp

総合スコア114585

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

具体的な理由がわからないので、判断難しいですが...
自分は、ユーザテーブルにおいて、ユーザ名とメールアドレスをそれぞれユニークにしたことはありますね。また、設計上よくないという話は聞いたことがありません。

意味的には、uuidごとにarticle_idはユニークである必要があり、uuidごとにipaddressもユニークである必要があるなら、問題ないと思います。ただ、アプリ側の実装もそれを前提としたものにしないとまずいとは思いますが。

投稿2016/10/10 20:27

編集2016/10/10 20:37
popobot

総合スコア6586

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問