DKWSLabs

yok

Добрый день ДЕН И ДЕНЧАНЕ.

Пишу все что связано с регистрацией. Впервые и самостоятельно. И возник вопрос.

После приема данных из формы регистрации, сохраняются временные данные в базе, чтобы после подтверждения пользователем в течении 24, они изменили статус на постоянный.

Ясно что таблица и в ней , поля логин, пароль , мыло.
Теперь временные данные(точнее пока это все временные и логин и пароль и мыло), какой то хеш, который должен совпасть с возвращенным от пользователя. Значит нужно создавать поле для этого хеша.
Поле этого хеша будет достаточно обьемным.
После подтверждения содержимое поля хеша удаляется, но поле то само остается.!!!!
Теперь проверка уже постояного , искать запись в которой пустое поле хеша, или же создавать поле в котором флаг уже постоянного пользователя.

И вот получается нужно два поля, для хеша и флага.

Как то нерационально получается.
Мало того что пустое поле хеша будет присутствовать, (и вопрос это же как то на обьеме отражается или на производительности???), а еще его проверять, или по флагам пробегаться.

Как то не так, а оптимизация.
Хотелось бы мнение знающих людей.
Спасибо.

Не задумывался не кто, для временных, свою таблицу, тогда таблица уже пользователей будет без этого поля, а ведь ее со временем однозначно будут ALTER

и контроль временных легче, и доступ и производительность.
Если подтверждение временного, пробежаться по временной очень быстро, и удалить старые, а по тоже по постоянным, уже морока, а потом только внести в постоянную, и потом не нужен поиск флага,
ведь поиск
SELECT *
намного быстрее чем
SELECT `flag`

Есть мнения???

den

Поле для хэша занимает аж 32 байта, char(32), а поле для флага - char(1). Вот и вся оптимизация

yok

Ден спасибо за ответ.

Но меня конкретно интересует вот что, после подтверждения, содержимое поля хэша удаляю, но само то поле остается.
И получается на 1000 подтвержденных 1000 полей пустых. Структура на 1000 ячеек больше, и даже если они пусты, они занимают какой то обьем??? или вот в частности если у поля char(32), то значит даже если они пустые, то вес дополнительный 32 * 1000, так что ли , или просто структура больше а вес не добавляется пока пустые поля???

den

32 * 1000 = 32 Кбайта, * 10 000 = 320 Кбайт. Это что много???? В крайнем случае всегда можно удалять пользователей, которые не заходили на сайт, скажем, последние полгода, что позволит уменьшить к-во записей

yok

Спасибо ДЕН, огромное, за свет в конце тонеля.
Значит, даже на пустые ячейки типа char(32), выделяется 32байта, и они суммируются, а не просто что могут быть выделены. Они есть, хоть пусто, хоть есть что.
И вот как раз мысль о поле времени последнего входа пользователя.

Огромное спасибо ДЕН. Idea

den

Не за что!

yok

Здравствуйте жители ДЕНЧАНИИ.

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

И вот допустим , для регистрации всего одна таблица. ОДНА. ИМенно.

И вот первый вопрос 1, если таблица одна, и выборка идет по логину, зачем нам индекс, и само поле вообщето id INT,
мало того, что оно есть вес, плюс еще и индекс автоматически на нем формируется.
Почему не назначить индекс по логину. Разумней , оптимальней. Про индексы я из Дена книги вычитал. Да и увидел в локалхосте.

2 вопрос. Поле date 3 байта, поле timestamp 4байта. Вобще ресурсозатраты на запрос вероятно заточенный под INTERVAL, от timestamp , меньше чем сравнение с date.

2 вопрос это как бы познавательный. А вот 1 почему то даже оправданный, лишнее поле int , и не необходимое, по которому формируется индекс. НЕРАЗУМНО ПОЛУЧАЕТСЯ.

yok

Я был прав когда сомневался, индекс по префиксу решает проблему, вот только опять
МЕНЯ ТЕРЗАЮТ СОМНЕНИЯ
"у .... магнитофон, у посла медальон"
ну а если серьезно то как затратно и отличие по весу и ресурсозатратам индекс по префиксу от простого.

den

yok

Но возникают траблы
1) пользователи иногда вместо логина указывают хз что. потом с этим нужно работать.

О ДЕН, вот спасибо за ответ, об этом я не подумал, как сам индекс работает с содержимым поля. Возможен ли ущерб если хз данные.
СПАСИБО ДЕН Idea

den

не за что

Anderson

yok, проблема с автоувеличением ID решается легко же: просто сделать ID как "id int AUTO_INCREMENT". Затем, если, например, есть таблица "sometable ( id int AUTO_INCREMENT,login varchar(30),password varchar(30), PRIMARY KEY(id));", то добавлять записи нужно так:

yok

Anderson, о спасибо за внимание. Вопрос был совсем в другом. О префиксе. Но спасибо за полный ответ, скоректирую его только по синтаксису

INSERT INTO `anytable` VALUES(' ".mysql_real_escape_string($login)." ',' ".next." ') ;

Да и еще раз пароль это всегда md5 хеш, то 32 знака всегда, поэтому лучше CHAR(32) not VARCHAR(32)