Пишу все что связано с регистрацией. Впервые и самостоятельно. И возник вопрос.
После приема данных из формы регистрации, сохраняются временные данные в базе, чтобы после подтверждения пользователем в течении 24, они изменили статус на постоянный.
Ясно что таблица и в ней , поля логин, пароль , мыло.
Теперь временные данные(точнее пока это все временные и логин и пароль и мыло), какой то хеш, который должен совпасть с возвращенным от пользователя. Значит нужно создавать поле для этого хеша.
Поле этого хеша будет достаточно обьемным.
После подтверждения содержимое поля хеша удаляется, но поле то само остается.!!!!
Теперь проверка уже постояного , искать запись в которой пустое поле хеша, или же создавать поле в котором флаг уже постоянного пользователя.
И вот получается нужно два поля, для хеша и флага.
Как то нерационально получается.
Мало того что пустое поле хеша будет присутствовать, (и вопрос это же как то на обьеме отражается или на производительности???), а еще его проверять, или по флагам пробегаться.
Как то не так, а оптимизация.
Хотелось бы мнение знающих людей.
Спасибо.
Не задумывался не кто, для временных, свою таблицу, тогда таблица уже пользователей будет без этого поля, а ведь ее со временем однозначно будут ALTER
и контроль временных легче, и доступ и производительность.
Если подтверждение временного, пробежаться по временной очень быстро, и удалить старые, а по тоже по постоянным, уже морока, а потом только внести в постоянную, и потом не нужен поиск флага,
ведь поиск
SELECT *
намного быстрее чем
SELECT `flag`
Есть мнения???
Спустя 41 минута, 19 секунд (18.03.2010 - 13:06) FatCat написал(а):
| Цитата (yok @ 18.03.2010 - 13:25) |
| После подтверждения содержимое поля хеша удаляется, но поле то само остается.!!!! Теперь проверка уже постояного , искать запись в которой пустое поле хеша, или же создавать поле в котором флаг уже постоянного пользователя. |
Это не сильно увеличит ресурсоемкость конструкции при обычном наплыве регистраций.
Мне пришлось решать эту задачу, когда делал систему "миграции пользователей" из одного движка форума в другой движок. Сотни и сотни валидаций в день - эту нагрузку уже следует учитывать. Сделал на двух таблицах: members и members_incoming
Непроверенные мемберы попадают в таблицу members_incoming, после валидации они попадают в members, а из таблицы members_incoming запись удаляется.
Спустя 32 минуты, 44 секунды (18.03.2010 - 13:39) Nikitian написал(а):
У меня пользователь имеет флаг activate типа bool (int(2)). А код активации хранится в другой таблице. Сперва при регистрации activate=0 (это дефолтовое значение, так что при внесении записи пользователя о нём не вспоминаю). Когда приходит код подтверждения, он сравнивается с тем, что в таблице кодов. Если верен, то соответствующему юзеру ставится activate=1. И это поле activate проверяется при авторизации.
Работает, нагрузки выдерживается разные (на работе такая система несколько сотен регистраций в день держит).
Работает, нагрузки выдерживается разные (на работе такая система несколько сотен регистраций в день держит).
Спустя 1 час, 28 минут, 2 секунды (18.03.2010 - 15:07) yok написал(а):
Большое спасибо за ответы.
Склоняюсь к созданию дополнительной таблицы для хранения временного подтверждающего значения.
Nikitian, а зачем
------------------------------
У меня пользователь имеет флаг activate типа bool (int(2)).
----------------------------------------------------------
почему int(2), а не хотя бы int(1), а еще лучше или TINYINT(1) or CHAR(1)
а вот bool это хорошая мысль
и не задумывался, наличие самого флага, в основной таблице, необходимость??? (если только не для того, чтобы временно отказывать в авторизации сохраняя пользователя), конечно 1 байт мало, но 1000 записей с лишними 1000 ячеек, ведь все уже подтверждены, если во временной до подтверждения их держать, ??
Просто мысли.
Потом вот о чем подумал. Пользователь может год не появляться или полгода, значит можно удалить, а значит поле времени последнего захода надо также.
Это я к тому что как можно меньше таблицу делать.
Думаю однозначно, если подтверждающий код будет char(32) , для больших сайтов однозначно надо отдельную таблицу для подтверждающего кода.
Склоняюсь к созданию дополнительной таблицы для хранения временного подтверждающего значения.
Nikitian, а зачем
------------------------------
У меня пользователь имеет флаг activate типа bool (int(2)).
----------------------------------------------------------
почему int(2), а не хотя бы int(1), а еще лучше или TINYINT(1) or CHAR(1)
а вот bool это хорошая мысль
и не задумывался, наличие самого флага, в основной таблице, необходимость??? (если только не для того, чтобы временно отказывать в авторизации сохраняя пользователя), конечно 1 байт мало, но 1000 записей с лишними 1000 ячеек, ведь все уже подтверждены, если во временной до подтверждения их держать, ??
Просто мысли.
Потом вот о чем подумал. Пользователь может год не появляться или полгода, значит можно удалить, а значит поле времени последнего захода надо также.
Это я к тому что как можно меньше таблицу делать.
Думаю однозначно, если подтверждающий код будет char(32) , для больших сайтов однозначно надо отдельную таблицу для подтверждающего кода.
Спустя 16 минут, 54 секунды (18.03.2010 - 15:24) Nikitian написал(а):
Действительно, tinyint(1) Написал не посмотрев.
| Цитата |
| и не задумывался, наличие самого флага, в основной таблице, необходимость??? (если только не для того, чтобы временно отказывать в авторизации сохраняя пользователя), конечно 1 байт мало, но 1000 записей с лишними 1000 ячеек, ведь все уже подтверждены, если во временной до подтверждения их держать, ?? |
Пользователи держатся заданное время т1, после которого им отправляется письмо с уведомлением об активации. Через время т2 запись о пользователе удаляется, если она так и не была активирована.
Спустя 1 день, 43 минуты, 35 секунд (19.03.2010 - 16:07) yok написал(а):
Извините, немного не по теме, но вопрос всего один, а из - за него тему не хочется поднимать, а подобной не нашел.
Вопрос касается типа поля для хранения пароля.
Имеет ли значение в данном случае BINARY, генерируя хэш от комбинации до 10 символов, результат всегда 32 символа, но все в нижнем регистре.
Но не в этом дело. Может быть все таки стоит выставлять BINARY.?
Не совсем понимаю как это может помешать злоумышленнику, но всеже это палка в колеса по идее.
Соль это другое.
Мысли есть какие??
И кстати BINARY изменит вес ?
Чтото глянул локалхост, там ни user ни password ни в бинаре.
Странно. База mysql.user
хотя пароль latin1_bin
а юзер utf8_bin
или это как раз и говорит о бинаре bin ?
Просмотрел свою таблицу, да, похоже _bin это сравнение бинарное.
Получается и оба поля в базе mysql.user бинарные, но везде в примерах вижу предложения о создании простых полей.
Вопрос касается типа поля для хранения пароля.
Имеет ли значение в данном случае BINARY, генерируя хэш от комбинации до 10 символов, результат всегда 32 символа, но все в нижнем регистре.
Но не в этом дело. Может быть все таки стоит выставлять BINARY.?
Не совсем понимаю как это может помешать злоумышленнику, но всеже это палка в колеса по идее.
Соль это другое.
Мысли есть какие??
И кстати BINARY изменит вес ?
Чтото глянул локалхост, там ни user ни password ни в бинаре.
Странно. База mysql.user
хотя пароль latin1_bin
а юзер utf8_bin
или это как раз и говорит о бинаре bin ?
Просмотрел свою таблицу, да, похоже _bin это сравнение бинарное.
Получается и оба поля в базе mysql.user бинарные, но везде в примерах вижу предложения о создании простых полей.
Спустя 2 дня, 17 часов, 17 минут, 48 секунд (22.03.2010 - 09:25) Guest написал(а):
Просматривал TWINа образец регистрации, не понимаю почему для md5 хэша поле типа VARCHAR(32)??
Логично предположить что CHAR(32) лучше.
Почему поднимаю эти вопросы, ? потому что допустим в мото, там борьба за каждый грамм. Кто с опытом тот знает, купит эндуро с весом 125 кг, и мечтает о весе 107кг.
Думаю в построении таблицы не зря пишут о оптимизациях, и прочем.
А тут зря один байт, это бесспорно, а вот еще момент, точнее два
1. поле date 3 байта а поле timestamp 4байта, тут я не знаю , возможно interval быстрее работает и заточено под это, чем сравнение по date, хотя время 24 часа не будет определенно четко, думал кто о этом?
2. индексация может необходима по логину, ведь поиск в основном не по номеру записи.
Логично предположить что CHAR(32) лучше.
Почему поднимаю эти вопросы, ? потому что допустим в мото, там борьба за каждый грамм. Кто с опытом тот знает, купит эндуро с весом 125 кг, и мечтает о весе 107кг.
Думаю в построении таблицы не зря пишут о оптимизациях, и прочем.
А тут зря один байт, это бесспорно, а вот еще момент, точнее два
1. поле date 3 байта а поле timestamp 4байта, тут я не знаю , возможно interval быстрее работает и заточено под это, чем сравнение по date, хотя время 24 часа не будет определенно четко, думал кто о этом?
2. индексация может необходима по логину, ведь поиск в основном не по номеру записи.
Спустя 2 минуты, 27 секунд (22.03.2010 - 09:27) yok написал(а):
Забыл что тут и не авторизованный может написать.
Выше я написал.
И раз уж разбираю эту тему, то создаваемый пользователь mysql, точнее пароль шифруется password(), вот тут написано
http://www.mysql.ru/docs/man/Connection_access.html
а мы используем md5, чем обусловленно такое различие.?
Добавлю в отношении индекса, индекс по любому создается, и в нашем случае (регистрация) создается по полю id, все понимают о чем я auto_increment , теперь хотелось бы задать вопрос где в запросах именно это поле участвует. Скорее запрос идет по полю логина, получается , мы бессмысленно и затратно создаем индекс по полю id, а необходимый индекс по полю логина, почему то игнорируем. Получается что не оптимально.
Как думают эксперты, скажите пожалуйста??
Хотя конечно если будут еще таблицы, тогда id это удобно.
Выше я написал.
И раз уж разбираю эту тему, то создаваемый пользователь mysql, точнее пароль шифруется password(), вот тут написано
http://www.mysql.ru/docs/man/Connection_access.html
а мы используем md5, чем обусловленно такое различие.?
Добавлю в отношении индекса, индекс по любому создается, и в нашем случае (регистрация) создается по полю id, все понимают о чем я auto_increment , теперь хотелось бы задать вопрос где в запросах именно это поле участвует. Скорее запрос идет по полю логина, получается , мы бессмысленно и затратно создаем индекс по полю id, а необходимый индекс по полю логина, почему то игнорируем. Получается что не оптимально.
Как думают эксперты, скажите пожалуйста??
Хотя конечно если будут еще таблицы, тогда id это удобно.
_____________
Достучаться до небес.