|
|
|
Посоветуйте, как организовать таблицу и индексы
|
|||
|---|---|---|---|
|
#18+
Делаю БД для веб-сайта, в котором в том числе будет осуществляться регистрация сессий посетителей. Особенности сайта таковы, что под одним логином может быть только одна активная сессия; если при авторизации пользователя под этими учетными данными уже есть ранее созданная активная сессия, она должна быть закрыта. У меня будут использоваться следующие запросы: Код: sql 1. 2. 3. 4. 5. Посоветуйте структуру таблицы и индексы? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. Вариант 1 - это обычная БД, которую обычно советуют в разных статьях. Вариант 2 - с MSSQL я не работал уже довольно давно и могу заблуждаться, но ЕМНИП в нем можно создать уникальный индекс, который тем не менее будет игнорировать значения с NULL. Если в MySQL есть что-то подобное, то мне это кажется хорошим решением. Вариант 3 - будет дополнительное поле USERNAME_ACTIVE по которому будет создан уникальный индекс; в этом поле буде указываться USERNAME для активных сессий и NULL или ID для неактивных сессий. И соответственно update-запрос нужно будет немного переделать (set ACTIVE=0, USERNAME_ACTIVE=ID). ________________________ Мы смотрим с оптимизмом... ...в оптический прицел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2015, 16:53:57 |
|
||
|
Посоветуйте, как организовать таблицу и индексы
|
|||
|---|---|---|---|
|
#18+
Я считаю что правильней будет организовать так (я по крайней мере так делаю): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. В этом случае в session у меня хранится архив сессий (на случай там чего-то когда-то узнать), в session_active хранятся только активные сессии, которые удаляются по параметру lastCheck (в случае если пользователь минут 5 допустим не был на сайте), а в userAuth связь активных сессий с авторизованными пользователями. В этой схеме немного упрощено всё, подразумевается, что в userAuth тоже записи неактивных сессий удаляются. У меня это всё сделано с помощью триггеров. Работает, не жужжит. В целом идея такая. Плюс в том, что поиск активной сессии не будет замедляться со временем, так как таблицы session_active и userAuth не разрастаются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2015, 14:01:58 |
|
||
|
Посоветуйте, как организовать таблицу и индексы
|
|||
|---|---|---|---|
|
#18+
Гуляев ГошаПлюс в том, что поиск активной сессии не будет замедляться со временемИ сильно он у вас замедлялся? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2015, 06:58:23 |
|
||
|
Посоветуйте, как организовать таблицу и индексы
|
|||
|---|---|---|---|
|
#18+
Перешёл на такую схему после года работы веб приложения. Тогда замедление стало проявляться, так как проверка информации из таблицы с сессиями при каждом обращении к страничке происходит. На тот момент кол-во сессий в таблице было около 400 000. Понимаю что это не много, но и железо на котором работает сервер у меня обычный "писюк". На котором кроме собственно БД крутится ещё и почта, сайты и самба. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2015, 08:41:06 |
|
||
|
Посоветуйте, как организовать таблицу и индексы
|
|||
|---|---|---|---|
|
#18+
Пришел к такой схеме: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. Основная таблица сессий это AUTH_SESSION, в ней хранится вся информация по сессиям и пользователям. Кроме этого создана memory-таблица AUTH_ACTIVE, в которой хранится информация только по активным сессиям (с индексами HASH для быстрой выборки). Кроме того в memory-таблице хранится поле ALIVE; это специальное поле, которое обновляется при любой активности пользователя на сайте. А memory - чтобы частые операции обновления не писать в БД. Не посоветуете, что улучшить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2015, 00:34:54 |
|
||
|
Посоветуйте, как организовать таблицу и индексы
|
|||
|---|---|---|---|
|
#18+
Alibek B. Код: sql 1. Для хранения обычного ip-адреса вполне достаточно 4-байтового поля unsigned int. Alibek B. Код: sql 1. Не рекомендую использовать тип TEXT без нужды, если можно обойтись VARCHAR-ом. Для некоторых типов запросов наличие в выборке BLOB/TEXT-полей автоматически означает создание временного файла на диске. Alibek B. Код: sql 1. Слово KEY является зарезервированным словом. И хотя формально его можно употреблять в правильных кавычках, лучше этого не делать. Кроме того, не стоит называть разные объекты БД одинаковым именем. Alibek B. Код: sql 1. Эти причины могут быть произвольно-разнообразными? Если нет (т.е. если это ограниченный набор вариантов), то лучше вынести это в отдельную таблицу-справочник, а тут оставить ссылку на нее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2015, 01:09:09 |
|
||
|
Посоветуйте, как организовать таблицу и индексы
|
|||
|---|---|---|---|
|
#18+
miksoftДля хранения обычного ip-адреса вполне достаточно 4-байтового поля unsigned int. Возможно я потом заменю на binary. Но пока что я не разобрался, как передавать параметры подобного типа (в параметрических запросах) через PDO. Кроме того есть IPv6. miksoftНе рекомендую использовать тип TEXT без нужды, если можно обойтись VARCHAR-ом. Понял. Вынесу в отдельную таблицу. miksoftСлово KEY является зарезервированным словом Я знаю. В запросах я всегда использую кавычки для имен объектов. miksoftЭти причины могут быть произвольно-разнообразными? Да, это произвольный текст. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2015, 09:43:03 |
|
||
|
Посоветуйте, как организовать таблицу и индексы
|
|||
|---|---|---|---|
|
#18+
Alibek B.Но пока что я не разобрался, как передавать параметры подобного типа (в параметрических запросах) через PDO.как, как... да как обычные параметры Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2015, 12:42:49 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39115633&tid=1832386]: |
0ms |
get settings: |
10ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
453ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
| others: | 235ms |
| total: | 780ms |

| 0 / 0 |
