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

Тема в разделе "Базы данных", создана пользователем Bags85, 1 ноя 2009.

Статус темы:
Закрыта.
Модераторы: latteo
  1. Bags85

    Bags85 Постоялец

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

    Eihwaz

    Регистр.:
    7 окт 2007
    Сообщения:
    156
    Симпатии:
    54
    А зачем? Меня просто смутила строчка "скрипт по-разному отображает просмотренные и непросмотренные тумбы", можете описать вашу задачу подробнее?
     
  3. Bags85

    Bags85 Постоялец

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

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

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

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

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

    Eihwaz

    Регистр.:
    7 окт 2007
    Сообщения:
    156
    Симпатии:
    54
    Можно, например, так:
    Таблица 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 нравится это.
  5. Bags85

    Bags85 Постоялец

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

    nittis Постоялец

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

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

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

    Bags85 Постоялец

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

    nittis Постоялец

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

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

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

    Bags85 Постоялец

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

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

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

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

    nittis Постоялец

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

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

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

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