Моя таблиц users - не нравится вообще...

Сенсей

Новичок
Моя таблиц users - не нравится вообще...

Проэкт работает уже 5 лет. Местная мини-социалка такая. На своем движке, смарти и т.д. Вот решил переписать сейчас движок на codeigniter дабы облегчить себе жизнь...

Вот заодно хотелось бы и базу правильнее сделать...

Сейчас в базе 32,000 пользователей. Вот привожу вам свою таблицу users - объяснять каждое поле не буду - и так думаю понятно. Почему то мне она перестала нравится. Где то глубоко в душе сидит мысль что надо бы разделить таблцу как минимум на 2 - в одной держать например тольок логин, мейл, пароль, а во второй - остольную информацию (год рождения, текст обо мне и т.д.)

Еще есть мысль сделать 3 таблицу где бы были данные типа флагов - то есть 0 или 1 (например can_uploda_music - может ли пользователь загружать музыку) - то есть жалкое пожобие permissions

В общем реально прошу советов :)

Ключи я убрал дабы незря не загружать страницу.

Поясню только про

`user_birth_day` и `user_birth_d` `user_birth_m``user_birth_y' - дата рождения хранится как есть + разбивается на части для того что бы быстрее выполнялась выборка при таких запросах как например выбор тех у кого дн.ха сегодня.

Вобщем вот таблица:

PHP:
CREATE TABLE `cms_ashdoda_users` (
  `user_id` int(10) NOT NULL auto_increment,
  `user_session_id` varchar(255) NOT NULL default '',
  `user_status` varchar(255) NOT NULL default '',
  `user_login` varchar(255) NOT NULL default '',
  `user_login_color` tinyint(3) unsigned NOT NULL default '0',
  `user_name` varchar(255) NOT NULL default '',
  `user_email` varchar(40) NOT NULL default '',
  `user_icq` varchar(25) default NULL,
  `user_icq_show_to` tinyint(3) unsigned NOT NULL default '0',
  `user_skype` varchar(255) default NULL,
  `user_skype_show_to` tinyint(3) unsigned NOT NULL default '0',
  `user_msn` varchar(255) default NULL,
  `user_msn_show_to` tinyint(3) unsigned NOT NULL default '0',
  `user_sex` tinyint(3) unsigned NOT NULL default '0',
  `user_birth_day` date NOT NULL default '0000-00-00',
  `user_birth_d` tinyint(2) unsigned NOT NULL default '0',
  `user_birth_m` tinyint(2) unsigned NOT NULL default '0',
  `user_birth_y` year(4) NOT NULL default '0000',
  `user_born_country_id` int(11) unsigned NOT NULL default '0',
  `user_city_id` int(10) unsigned NOT NULL default '0',
  `user_notes` text,
  `user_password` varchar(255) NOT NULL default '',
  `user_regdate` datetime NOT NULL default '0000-00-00 00:00:00',
  `user_photos` tinyint(3) unsigned NOT NULL default '0', /* количество загруженных фотографий */
  `user_views` int(11) unsigned NOT NULL default '0', /* количествопросмотров профиля */
  `user_last_visit` datetime NOT NULL default '0000-00-00 00:00:00',
  `user_comments_count` int(11) unsigned NOT NULL default '0',
  `user_points` int(11) NOT NULL default '0', /* что то вроде положительной кармы */
  `user_new_messages` int(11) unsigned NOT NULL default '0', /* количество новых комментариев на страничке */
  `user_last_comment` datetime NOT NULL default '0000-00-00 00:00:00',
  `user_hidden` tinyint(3) unsigned NOT NULL default '0',
  `user_ip` varchar(255) default NULL,
  `user_avator` varchar(255) default NULL,
  `user_new_comments` int(10) unsigned NOT NULL default '0',
  `user_blog_name` varchar(255) default NULL,
  `user_blocked` tinyint(1) unsigned NOT NULL default '0',
  `user_blocked_until` datetime NOT NULL default '0000-00-00 00:00:00',
  `user_reg_hash` varchar(255) default NULL,
  `user_reg_temp` tinyint(3) unsigned NOT NULL default '1',
  `user_on_page` int(10) unsigned NOT NULL default '0',
  `user_winks` tinyint(3) unsigned NOT NULL default '0',
  `user_last_user_page` int(11) unsigned NOT NULL default '0',
  `user_last_user_page_date` datetime NOT NULL default '0000-00-00 00:00:00',
  `user_do` tinyint(3) unsigned NOT NULL default '0',
  `user_mobile_operator_one` tinyint(3) unsigned NOT NULL default '0',
  `user_mobile_operator_two` tinyint(3) unsigned NOT NULL default '0',
  `user_television` tinyint(3) unsigned NOT NULL default '0',
  `user_smoke` tinyint(3) unsigned NOT NULL default '0',
  `user_born_city_id` int(11) unsigned NOT NULL default '0',
  `user_spy_blogs_new` tinyint(1) unsigned NOT NULL default '0', /* количество новых записей блоггеров на чьи блоги подписан юзер */
  `user_poll_voted` tinyint(1) unsigned NOT NULL default '0',
  `user_photo_albums` tinyint(3) unsigned NOT NULL, /* количество созданных фотоальбомов юзером */
  `user_can_upload_music` tinyint(3) unsigned NOT NULL default '0', /* может ли юзер загружать музыку */
  `user_signed_poll_id` int(11) unsigned default NULL, /* id присоединенного опроса на страничке юзера */
  `user_photo_albums_new_comments` tinyint(3) unsigned NOT NULL default '0', /* количество новых комментариев к фоткам в альбомах */
  PRIMARY KEY  (`user_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE utf8_general_ci;
 

tashkentchi

Новичок
назначать пермишены 32 тыщам юзерам нетривиально. Проще сопоставить им группы, а группам назначить пермишены.
 

Сенсей

Новичок
findnext
Не трудно ли муське сортировать данные например при поиске юзеров когда например берутся с в основном данные такие как имя логин аватор и т.д?

Остальные данные во основном показываются только на страничке пользователя...

Просто я не раз читал что люди делают одну таблицу типа

users (id, login, name, email, password)

и таблицу типа

user_properties (user_id, reg_date, birth_day, city_id, photos, views)
 

pilot911

Новичок
какая разница ?
ты при поиске используешь поля, имеющие ключи
соответсвенно, за остальные данные не волнуйся...

и вообще, каждая запись должна браться из кэша по ID - тогда не будет заморочек с таблицей
 

LONGMAN

Dark Side of the Moon..
У меня две таблицы, users и anket, в первом только те данные которые часто меняется или является основним (идентификатор, логин, пароль, посты, время пребывания юзера, пермишн, настройки) а во втором имя, адрес, инфа, скайп, майл, аська и т.д. Думаю так рациональнее. Часто вообше не приходится брать данные из anketa и сайт работает быстро.
 

LONGMAN

Dark Side of the Moon..
Не приходится читать большую таблицу anketa, хоть и по первычному ключу но всёравно. А в users пачти только tinyint поля и флаги 1 и 0 в нём.
 

findnext

Новичок
Сенсей
тут всё дело в том что ты в SELECT указываешь. В запросах нужно выбирать только то что тебе нужно, т.е SELECT * будет занимать больше времени, чем SELECT несколько колонок, и всё, больше тут ничего нет, а то сколько у тебя полей, 10 или 300 при SELECT col1, col2 выполнится одинакого.
 

LONGMAN

Dark Side of the Moon..
А вот этого я не знал.. Если выбираем запись по PRIMARY KEY, влияет на времени сколько записей в таблице?
 
Сверху