3

私は、作成中の Web サイトに非常に単純なユーザー データベースを実装していますが、当然のことながら、できるだけ「ベスト プラクティス」に近い作業を行いたいと考えています。データベースは MySQL にあり、テーブル定義に苦労しています。

CREATE TABLE IF NOT EXISTS 'users' (
  `user_id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'auto incrementing user_id of each user, unique index',
  `user_email` varchar(254) COLLATE utf8_unicode_ci COMMENT 'user''s email',
  `user_password_hash` text COLLATE utf8_unicode_ci NOT NULL COMMENT 'user''s password in salted and hashed format',
  PRIMARY KEY (`user_id`),
  UNIQUE KEY `user_email` (`user_email`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci COMMENT='user data' AUTO_INCREMENT=1 ;

このテーブル定義を php-login.net から借用し、それを編集して user_email を一意のキーにしました (元のキーはテキスト フィールドであり、一意ではありませんでした)。

いくつか読んだ後、これほど大きな一意のキー/インデックス（254 * 3バイト）を持つことはデータベース設計が悪いことを意味し、MySQLのキーの最大長が1000バイトであるという事実は私に考えさせるいくつかのコメントを見ました私は何か間違ったことをしています。このデータベースは改善できますか、それともこのままで問題ありませんか?

MySQL でのインデックス作成の内部動作と関連するオーバーヘッドの量がわからないので、これほど大きなキーが効率的でない可能性は十分にあると思います。

助けてくれてありがとう。

4

1 に答える 1

2

電子メールを一意のインデックスにすることは、制約として機能し、電子メールによるルックアップを改善するには問題ありませんが、電子メール フィールドのサイズを小さくしないのはなぜですか? 254 文字の電子メール アドレスをいくつ持つ予定ですか? 列を varchar(128) にすることでそれらを犠牲にできますか? 主キーには使用しません。自動インクリメントbigintを保持してください。

他のベスト プラクティスに関して言えuser_ば、ユーザー テーブルのすべての列に追加するのはなぜでしょうか? ユーザー テーブルに、ユーザー レコードに適用されない列はありますか? などを使用するだけです...クエリを記述する場合id、andはandよりもクリーンです。また、 を他のテーブルで外部キーとして使用する場合は、それらを として参照するだけです。このことから、外部キーがテーブルの列であることがわかります。データベース全体でこれを一貫して行います。emailuser.iduser.emailuser.user_iduser.user_emailuser_ididuser

于 2012-11-29T17:23:28.047 に答える