Таблица с 50 полями или 2 таблицы???

[kutsanov]

Ситуация такая
Есть свойства пользователя.
Они фиксированы! Возможно в будущем, очень далеком, кто захочет еще пару создать, но не факт.
Есть два пути
1 Создать таблицу со всеми этими полями

2 Создать две таблицы
первая некоторое стандартное описание
вторая с полями USER_ID, KEY, VAL
USER_ID - ссылка на первую
KEY - ключ свойства
VAL - значение свойства
---
как правильнее??? Можно холиварить!:)

[SiZE]

EAV это один большой холивар. А если используются процедуры, то у них есть ограничение на количество передаваемых полей. Надо отталкиваться от того какие это будут поля. Удобно хранить поля, которые заполняются при регистрации, в одной таблице. Есть поля, которые должны быть внешними ключами, их тоже надо оставить в таблице. Другие поля надо смотреть, возможно дешевле будет привести к какой-то из нормальных форм таблиц.

[samdark]

1 потому что «возможно» и «очень далеком».

[kutsanov]

EAV это один большой холивар. А если используются процедуры, то у них есть ограничение на количество передаваемых полей. Надо отталкиваться от того какие это будут поля. Удобно хранить поля, которые заполняются при регистрации, в одной таблице. Есть поля, которые должны быть внешними ключами, их тоже надо оставить в таблице. Другие поля надо смотреть, возможно дешевле будет привести к какой-то из нормальных форм таблиц.

Булевый (0/1)
Внешних ключей не будет
просто некрасиво получиться что таблица с 50 полями!
Я так никогда не делал, вот и интересуюсь. Это вообще нормально?

[kutsanov]

1 потому что «возможно» и «очень далеком».

так и сделаю!:)

[yan]

Второй вариант тут точно не нужен, EAV очень муторная затея поэтому стоит его применять только при острой необходимости, при одном типе объекта такой необходимости явно нет.
Еще есть третий, неописанный здесь, но часто применяемый вариант - разделение на две таблицы, часть полей в первой, например признаки-флаги, типа активный-неактивный и тп, а всякие описательные во второй, в частности при использовании в YII это дает, что при при любом запросе пользователей в запросе не будут перечисляться и соответственно выбираться все 50 полей, ну и полезно для производительности тем что можно оптимизировать таблицы - например первая будет с фиксированными строками, все динамическое во второй, насколько это полезно в процентах правда не скажу.

[zelenin]

я бы разбил на функциональные таблицы по какому-либо признаку. В первой, понятно, основная информация типа id, name, date, а в других мета-информация.
ну конечно не чистый первый вариант. ты вы правы - это некрасиво и непрактично. плюс один - быстродействие. Хотя в общем варианте и при несольких таблицах вы несильно потеряете.