Форум MySQL

Здесь будет лучше INT потому, что при относительно коротком размере элемента индекса (4 байта)
пространство ключей достигает двух миллиардов, чего достаточно для подавляющего большинства приложений.
Вот и все рассуждение.

Сколько проектирую бд, столько задаюсь вопросом, какие же типы полей задавать.
Я не занимаюсь преждевременной оптимизацией, но не хочется допускать ошибок еще на этапе проектирования. Однако этот вопрос оказался настолько непростым, что я до сих пор с уверенностью не могу сказать, что в данном конкретном случаи лучше будет это и ничего другого.

P.S. Сам по энерции всегда использую INT (так в большинстве статей было, по которым я учился), однако аргументированно доказать, что здесь будет лучше именно INT не могу.

Вы специалист по большим нагрузкам?
Нет?
И я нет.
Какой смысл нам перетирать эту тему?



P.S.
Твою налево, ну почему люди пытаются лезть в оптимизацию до того, как научатся более менее прилично проектировать создаваемое?!

Я представляю, сколько надо добавить категорий, к примеру, чтобы INT хотя бы наполовину заполнить =)
Однако сильно ли сказывается на скорости (если это все-таки первичный ключ), да и размер в 4 раза увеличивается (пусть там 3 байта разницы, но при больших нагрузках, видимо, и такое ощутимо?)

Я говорил не только о первичных.
Когда пространство первичных ключей переполнится, кому-то сильно сплохеет.
При типах TINYINT и SMALLINT это может произойти куда раньше, чем загадывает автор.

Какое обоснование, что id (первичные ключи) следует делать INT?

5. какая команда нужна, что вся БД mysql была в utf-8?
Чтобы вся БД была - достаточно CREATE DATABASE dbname CHARACTER SET 'utf8'; ну и SET NAMES 'utf8' при обращениях.
А вот чтобы вся БД стала - одной командой не обойдешься.
Придется долго и нудно исправлять. Так что лучше сразу делать без ошибок.

10.
Почитать о функциях даты и времени MySQL
Применить подходящую.
Либо выполнять преобразование уже на php-уровне.

9.
Никаких регекспов. Массивные данные в ячейках не хранятся - это сразу и в лоб нарушает первую нормальную форму.
Массивные данные следует растягивать по строкам.
Так что второй вариант.

8.
а) Вы зря экономите на id. Делайте их INT
б) если текстовое поле несет ключевую информацию (логин, телефон, e-mail, URL) его делают VARCHAR, а не TEXT
в) если пароль хранится в виде хеша - вместо VARCHAR разумно применить VARBINARY
Если в открытом виде,... впрочем, в открытом виде пароли храниться не должны нигде.