Помогите со структурой таблицы(условия внутри)

[Bags85]

С MySQL сталкиваюсь впервые... Требуется собирать данные о просмотре юзвером рисунков, их около 2000. Скрипт по разному отображает просмотренные и не просмотренные тумбы. За раз выводится по 12 тумб. В среднем каждый юзвер будет просматривать по 200-300 рисунков.
Можно ли создать такую таблицу: 1-я колонка Юзвер, в остальных перечислены рисунки; в строках: "1" - картинка просмотрена, "0" - не просмотрена? Либо сделать таблицу в 2 столбца: в первом записывать имя юзвера, во втором имя просмотренной картинки?
Возможно есть еще какие нить варианты...

 

[Eihwaz]

А зачем? Меня просто смутила строчка "скрипт по-разному отображает просмотренные и непросмотренные тумбы", можете описать вашу задачу подробнее?

 

[Bags85]

А зачем? Меня просто смутила строчка "скрипт по-разному отображает просмотренные и непросмотренные тумбы", можете описать вашу задачу подробнее?

Просмотр платный, юзвер должен знать смотрел он этот рисунок или нет... поэтому не просмотренные будут отображаться затемненными... Также с помощью этой таблицы скрипт будет определять снимать с юзвера плату или нет(второй раз за просмотр платить не надо). Тумбы расположены в древовидной структуре по 12 штук на странице: переход с одной ведет к следующим 12, всего 3 уровня.
По сути вопрос в том, какой способ учета будет практичнее: таблица с почти 2000 столбцов(если такое возможно) 0 - не просмотрено, 1 - просмотрено:

Юзер:::Рис1:::Рис2:::Рис3...
Иван::::1::::::0::::::1
Петр::::0::::::1::::::0
...

Или таблица в которую заносятся при просмотре имя юзвера и маркер картинки:

Юзер:::Рисунок
Иван::::b1
Петр::::b1
Иван::::b3
Иван::::b1m1
Антон:::b2

Или какой нить другой вариант таблицы, о котором я не догадываюсь...

 

[Eihwaz]

Можно, например, так:
Таблица users
user_id int(11), autoincrement
user_name varchar(128)
Таблица images
image_id int(11), autoincrement
file varchar(128)
Таблица view_log
user_id int(11)
image_id int(11)
Ну, понятное дело, индексы, все дела.

 

[Bags85]

А насчет индексов можно поподробнее...
Почитал мануалы, но так и не понял, если в проиндексированную таблицу добавляются данные, они тоже индексируются?
В моем случае таблица view_log будет заполнятся на лету большим кол-вом данных, и они тут же будут использоваться в работе скрипта...
И еще решение с таблицей на 2000 колонок имеет возможность на существование или нет?

 

[nittis]

Индексы позволяют уменьшить время выполнения запроса и обычно строятся на всех полях, которые участвуют в условии WHERE. При этом строить индексы на полях с маленьким разбросом значений (напимер 0, 1) неэффективно.

Для задачи надо выбрать вариант с талицей пар (ПОЛЬЗОВАТЕЛЬ - КАРТИНКА), который позволяет быстро ответить на вопрос какие картинки пользователь уже посмотрел, без последующего анализа на PHP (или другом языке). В таблице с 2000 полей сделать это гораздо сложнее, да и ограниения по количеству стобцов скорее всего есть (для таблиц InnoDB - 1000 полей, для MyISAM данных не нашел)

В моем случае таблица view_log будет заполнятся на лету большим кол-вом данных

Насколько большой объем данных планируется?

 

[Bags85]

По крайней мере для меня большой=). Планируется где-то 1-2 тасячи юзверов, т.е. это примерно 300к-600к строк.
И все таки интересует как происходит индексирование: при выполнение команды в уже заполненой таблице(новые строки в индекс попадать не будут), или же если часть таблицы проиндексированна, то при добавление новых строк они тож буду индексироваться?
И еще вопросик: как будет чувствовать себя БД, когда эти 1-2к пользователей дновременно(а это будет именно так) будут лазить по картинкам и будет непрерывно вестись запись и чтение из этой таблицы

 

[nittis]

Я спрашивал о нагрузке, в короткий интервал времени. Если честно мне трудно представить такой сервис, на котором в один и тот же момент времени присутствует 2000 активных пользователей. Впрочем бывает всякое.

Индекс будет перестраиваться всякий раз, когда в таблицу производтся запись.

Таблица (а точнее СУБД) с такой нагрузкой будет чувствовать себя плохо, но на этот случай придумали кеширование, которое в проекте с подобной нагрузкой придется использовать по полной программе. Например, при логине пользователя можно один раз запрашивать список оплаченых картинок и хранить его в течение сессии.

 

[Bags85]

Кеширование думаю не подойдет. Маленько расскажу про проект поподробнее:
Юзверы соберутся за n-ое время(офлайн и онлайн реклама). За это время они приобретают себе "кредиты"(внутренняя валюта), эти кредиты и будут сниматься за просмотр картинок. Потом в определенный день и час стартует основная часть проекта, суть для пользователей будет просмотреть какую то часть картинок(зачем и почему объяснять не буду). Т.е. запись в таблицу будет в течении короткого времени(время зависит от скорости обработки данных скриптом и соединения пользователя)и в течении одной сессии. Самый лучший способ, как я считаю, держать данные о просмотре картинок в БД,но я могу заблуждаться, программировать я только учусь=). Конечно нужно было бы привлечь опытного прогера, но не позволяет бюджет...

Появилась еще такая идея:
меня все тянет в сторону большого числа столбцов=) По сути картинки выводятся блоками по 12 штук и для каждого блока набор неизменен. Данные просмотре тумб в конкретном блоке можно держать в массиве опять же с помощью нулей и единиц. Массив с информацией о блоке обрабатывать функцией serialize() и толкать в таблицу. Таблицу сделать такой:

Таблица view_log
user_name varchar(128)
blok1 (не определился пока с данными)
blok2
blok3
....

Кол-во столбцов сократится до 158, и как я понимаю сократится нагрузка на БД.
Как такой вариант?

 

[nittis]

В большинстве случаев работа с базой данных является узким местом проекта. Преимущества ее использования не в скорости чтения/записи, а в едином подходе к хранению данных и удобстве их выборки. Не случайно кешируют данные именно в файловую систему или оперативную память.

Если действия пользователя в вашем проекте не зависят от действий других пользователей, то файловое (сессионное) кеширование будет очень кстати. Если же пользователи могут влиять друг на друга, то надо смотреть в сторону memory cache.

Возможно, что вариант с разбиением на группы будет быстрее (а может и нет), но нагрузка на сервер все равно будет очень большой, если вы будете писать каждое изменение в базу данных. Кстати, в этом случае удобнее хранить 12-битовое число (от 0 до 4095), где каждый бит определяет просмотрена ли картинка с соответствующим номером в группе.

В качестве ключа в таблице лучше использовать не имя пользователя, а его числовой идентификатор - индексироваться будет быстрее.