[vadimiron]

Vlad Drakula

Сенкс, но же написал что сам запрос был неправильно составлен, то есть с лишними скобками, и естественно mysql_fetch_row() выдавал ошибку, так как не получал нормальной инфы из запроса

Сейчас всё работает

[Vlad Drakula]

Prisoner
а что означает DISTINCT

Добавлено:

vadimiron
дело в том что в данной задаче очень сложно определить нужны ли индексы и какие именно!

если нужна оптимизация то я бы посоветовал сделать одну таблицу с тремя полями и индексом по id.

на мой взгляд это будет наиболее оптимальный вариант!

[mar]

Vlad Drakula

DISTINCT

- значит выбор несовпадающего

[Prisoner]

Выбор несовпадающего... угу. Вообще говоря

Параметры (опции) DISTINCT, DISTINCTROW и ALL указывают, должны ли возвращаться дублирующиеся записи. По умолчанию установлен параметр (ALL), т.е. возвращаются все встречающиеся строки. DISTINCT и DISTINCTROW являются синонимами и указывают, что дублирующиеся строки в результирующем наборе данных должны быть удалены.

На счет организации данных. Исходя из того, что сессия в общем-то необходима одна , то получается, что можно сделать одну таблицу:

Код:

CREATE TABLE `users` (
  `u_id` TINYINT(5) UNSIGNED NOT NULL AUTO_INCREMENT,
  `s_id` CHAR(32) NOT NULL,
  `s_init_time` TIMESTAMP(14) NOT NULL,
  `u_name` CHAR(100) NOT NULL,
  `u_mail` CHAR(50) NOT NULL,
  PRIMARY KEY (`u_id`),
  UNIQUE KEY `u_id` (`u_id`),
  UNIQUE KEY `s_id` (`s_id`),
  UNIQUE KEY `u_mail` (`u_mail`)
);

Правда уникальность некоторых полей дает неудобства при вставке новой позиции, скажем, здесь необходимо уже иметь уникальный номер сессии (UID автоинкрементный, а мыльница у нас есть из формы). Выбор типа столбца для даты начала сессии обусловлен принципом общности - мало ли когда она начата... Правда тут уже загвоздка, как по таблице определить начал пользователь сессию или нет? Стало быть уникальность сессии надо убрать и если это поле пустое, то сессия не начата, а данные в поле даты - не адекватны.

[vadimiron]

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

Добавлено:

Верней, чтобы узнать какие сессии стирать можно  а какие ещё рано

[Prisoner]

А как ты выявляешь факт устаревании сессии? Ну пусть какой-то такой факт есть. Скажем это время - пусть сессия выделяется на 5 часов (сразу прикинь на каком типе ресурсов это окажется незаменимым ) и факт нажатия на ссылку "выход". В любом случае перед уничтожением сессии опустоши в таблице поле этой сессии для конкретного пользователя, по той логике, что была предложена выше это означает, что сессия закрыта. Еще ко всему, каждый раз когда делаешь это опустошай (и удаляй сессии PHP) поле сессий которые зарегестрированы более 5ти часов назад. Для этого достаточно выполнить всего два запроса.
Для шага (а)

Код:

UPDATE `users` SET `s_id` = '' WHERE `u_id` = какой_то_там

Для шага (б)

Код:

UPDATE `users` SET `s_id` = '' WHERE `s_init_time` < (CURRENT_TIMESTAMP() - 18000)

Причем следует знать, что первый в таблице столбец типа timestamp означивается в операциях INSERT, UPDATE текущей датой в том случае, если он явно не указан в этих операциях (есть еще уточняющие моменты, но их можно найти в мануале). Это нам не мешает, а даже наруку.