Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Miracle

Страницы: [1] 2 3
1
я ведь ответил
в быстродействии поиска
а если сделаю индексы как я написал то поиск будет быстрее

я просто спросил это в вопросительной форме так как не уверен на сколько критична разница во времени выполнения операции

но предполагаю что с индексами я проиграю только в размере базу

2
Цитировать
RomikChef:
а какие минусы?

ну если в таблице будут не только user_id и photo_id
а ещё два столбца
то ведь минусы есть?
в быстродействии поиска или как?
выгодней сделать иедксы по второму варианту что я описал выше

3
используй имена полей как массив
my_array["name1"]
my_array["name2"]
my_array["name3"]
и потом через foreach и получишь их
foreach ($my_array as $k => $v) {}

4
Цитировать
Phoinix:
интересно в чем сложнось???

база будет тяжелей

Цитировать
Phoinix:
У тебя индекс будет просто дублировать таблицу

ну я с планами на будущее
я ещё не уверен что будет только user_id и photo_id
вот всё думаю стоит ли добавить ещё пару полей
таких как какую именно оценку пользователь поставил и время когда он это сделал
просто может в будущем если уж слишком база будет большая то к примеру время голосования использовать для того что голоса старше к примеру двух месяцев удалять

вот такие дела

Цитировать
Phoinix:
А причем здесь PHP???

я думал на эту тему
но решил всё таки продолжить всё в этом топике
изначально запостил сюда так как думал что много предложений будет как с php всё это грамотно сделать

5
Цитировать
RomikChef:
вообще никаких индексов не делать

какие плюсы?

6
вот тут проблема возникла
остановимся на первом способе

и так, какие действия мы будем делать с этой информацией?
1. смотреть есть ли записи user_id | photo_id
если есть то не позволяем голосовать
для быстрого нахождения используем multipile_column_indexes
так как это быстрее в случаем поиска сразу по двум параметрам
(а ведь мы помним что при наших идеальных условиях у нас 100 млн. записей)
и так как повтор user_id в десять раз будет встречаться чаще чем photo_id (соотношение 100 тыс. к 1 млн. при наших идеальных условиях 1/10) то нам выгодней выставить крайним левом префиксом столбец user_id
так и поступаем

2. если вдруг ник пользователя надо удалить из базы, то ради рациональности мы удаляем и все логи по голосованию данного пользователя
и тогда опять возвращаемся к нашего логу голосований
DELETE FROM voted_photos WHERE user_id = \'$user_id\';
и всё отлично, при поиске нужных строк будет использован индекс

3. нам надо удалить фотографию в том числе её инфо из логов голосований
DELETE FROM voted_photos WHERE photo_id = \'$photo_id\';
но вот беда
при той структуре индексов что мы создали в данной ситуации индексы не будут использованы
вот тут вся проблема

и так вопрос:
как всё таки в данной ситуации лучше сделать индексы
1. сделать раздельные индексы
отдельно user_id и отдально photo_id
но тогда мы будем терять в скорости при самой популярной операции обращения (проверки на существования user_id & photo_id)
2. сделать многостолбцовый индекс для user_id & photo_id и ещё сделать один раздельный индекс для photo_id
но тогда файл индексов будет значительно больше
а отсюда и сложность с ним работать
ну и конечно немного дольше будет заноситься новая информация так как надо создавать больше индексов

или может ещё какие варианты есть?
хотелось бы послушать

7
Спасибо большое!

8
Цитировать
Forza:
самое главное - не забывать про индексирование!

конечно
это самособой разумеющееся

9
Цитировать
RomikChef:
стремный способ.

в смысле ты предлагаешь выбрать первый вариант?
я вот тоже к нему склоняюсь

10
Готов выслушать любые предложения
вплоть даже до того, чтобы кто-то привёл причины почему не стоит хранить все голоса до бесконечности!

кстати, забыл упомянуть что у первого способа есть один большой плюс
скажем при удалении фотографии можно легко и быстро удалить и все её логи по голосам из базы чтобы её не загромождать и к тому же нам эти логи больше не понадобяться

со вторым же способом это тоже сделать реально
но уж больно муторно и долго

11
Как грамотно организовать структуру MySQL базы для хранения информации для:
есть сайт, скажем фотосайт со множеством фотографий
пускай их в базе будет 1 млн.
есть пользователи на сайте, их скажем 100 тыс.

пользователи могут голосовать за фотографии
если все пользователи проголосуют за все фотографии то имеем 100 млн. голосов

надо организовать базу грамотно так чтобы скрипт как можно быстрее мог смотреть голосовал ли конкретный пользователь за конкретную фотографию и если да то повторый голос не засчитывать

у меня два способа как это организовать
первый
два стобца
user_id | photo_id
и так для каждого голоса прописывать новую запись
и того в нашем примере получаем 100 млн. записей

стрёмный способ

способ второй
два стобца
user_id | array_photo_id
то есть если пользователь хотя бы один раз за какую-то фотку проголосовал то для него создалась запись
user_id | array_photo_id
и уже для последующих его голосов в столбец array_photo_id добавлять новые photo_id скажем через запятую

и потом уже при проверки забирать весь масив и скажем смотреть через in_array есть ли уже такой photo_id или нет

если кому нарвится второй способ то каком виде лучше хранить столбец array_photo_id?
как text или что посоветуете?
всё-таки это массив будет очень большим если скажем пользователь сделал 100 тыс. голосов или даже 1 млн.

или кто что посоветует
какие другие есть способы для реализации данной задачи?

12
PHP / Подсчёт MySQL запросов
« : 29 Сентября 2004, 14:22:11 »
Спасибо большое!

13
PHP / Подсчёт MySQL запросов
« : 28 Сентября 2004, 22:05:49 »
Как грамотно сделать следующее?
Страница сгенерирована за 0.25157905 секунд (45.23% PHP - 54.77% MySQL) SQL запросов: 11
Время выполнения программы это понятно
а вот количество выполненных mysql запросов и их время?
есть ли какие-нибудь готовые функции в php?
есть нет и надо делать самому, то как сделать я знаю, и о timestat от php.spb.ru тоже знаю

просто вот подумалось может какие стандартные методы есть

14
Базы данных / MySQL и Индексы
« : 18 Января 2003, 19:09:23 »
Цитировать
Normally, you create all indexes on a table at the time the table itself is created with CREATE TABLE. See section 6.5.3 CREATE TABLE Syntax. CREATE INDEX allows you to add indexes to existing tables.

я там и прочитал

15
Базы данных / MySQL и Индексы
« : 18 Января 2003, 18:52:17 »
Цитировать
Miracle
Хамство незнание не красит

да я то и не хамил если ты не заметил
просто сказал в другой форме что мне нужно

ну да ладно
все русские (точнее СНГшный, так и живёте при совке! так вам и надо!) форумы - это опускание новичков бывалыми
вопрос бы корректный
просто ничего придумывать не надо
всё что надо было это приветсти пример создание базы с 1-2 индексами в ней
и элементарный php запрос, хотя это можно даже было и не приводить

ну да ладно
разберусь

P.S. кстати, могли бы и сказать мне что CREATE INDEX нужен только в том случае если база уже существует а так индексы создаются уже при CREATE TABLE
P.S.S. вот теперь я нахамил! прошу прощения! наболело!

Страницы: [1] 2 3