Меню
Что нового?

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

webxtor

Новичок
Как лучше организовать структуру модерируемой таблицы?

У меня есть таблица, в которой хранятся некоторые данные, внесенные пользователями.
Появилась задача пропускать все изменения и создания новых записей через модератора. Сайт расчитан на большую посещаемость, а обьем данных таблицы будет около 300 тыс записей.

Стоит ли создавать новую таблицу, где хранить ожидающие модерации данные, с целью снизить нагрузку на таблицу, из которой постоянно идет выборка?

Еще есть вариант немного изменить структуру таблицы, добавив новое поле moderated TINYINT(1), но в таком случае выборка получит еще одно условие в where: and moderated=1, что немного уменьшит скорость работы.

Как же лучше посупить?

Спасибо за внимание!
 

bEstard

Guest
мне кажется, что лучше создать еще одну небольшую табличку, которая будет служить вроде темповой, в которой записи после модерирования будут уничтожаться...
Это, конечно, снизит нагрузку на основную таблицу..
Там правда, возможно потребуется таки такое же поле moderated для удаления уже отмодерированных записей, чтобы случайно не удалить пришедшие свежие записи для модерирования (если работа параллельно осуществляется..)
 

webxtor

Новичок
bEstard

А как ты думаешь, в этом маленькой табличке лучше записывать и удалять, или обновлять? То есть вместо удаления можно ведь все поля пустыми оставить, кроме связывающих, а при повторном редактировании, обновлять пустые. Таким образом никогда не будет DELETE. Просто я читал в доке, что плохо, когда постоянно удаляется и добавляется инфа.. сильно фрагментируются данные.
 

Demiurg

Guest
>Это, конечно, снизит нагрузку на основную таблицу..
ты уверен ? а на сколько ?

webxtor
создание еще одной таблицы - это денормализация. Попробуй потестировать обы этих варианта на предпологаемых нагрузках, если результаты будут сильно отличаться, тогда, наверно, стоит прибегать к денормализации.
 

bEstard

Guest
Насчет фрагментирования..., я c MySql недавно стал работать, до этого с MSSQL работал в основном.. я не знаю насколько это проблематично для сего движка..., но по идее это проблема из области администрирования - администратор должен регулировать фрагментацию, по крайней мере на сиквеле, я завел несколько администратовных задач, решающих в том числе и проблему фрагментации и забыл об этой проблеме...
А какая там у тебя ситуация и как движок MySql работает и как на него фрагментация влияет, я пока не знаю, только начал изучать...)). Если сможешь все через апдейты построить - хуже не будет, хотя сам по себе апдейт работает медленнее чем просто инсерт или делет, поскольку поиск выполняет... Возможно это скажется потом на производительности, когда темповая таблица связями обрастет...., опять же это я по опыту работы на сиквеле рассуждаю....
 
Фанат

Фанат

oncle terrible
Команда форума
webxtor, не испытывая к тебе ни малейшей симпатии, не могу, тем не менее, не отметить того, факта, что твой "советчик" даже не то что не читал - а даже АДРЕСА документации не знает.
И в соседней теме задает вопросы гораздо более идиотские, чем твои.
Впрочем, по сеньке и шапка.
общайтесь дети мои. потом в юмор топик поедет
 

bEstard

Guest
Demiurg
Денормализация - нормальное явление при работе с большими объемами данных, частенько и поля дублируются в угоду ускорения выборок, дабы избежать большого количества объединений...))
Я, честно говоря, еще ни разу не встречал на 100% нормализованные БД, кроме учебных ))
 

Demiurg

Guest
> хотя сам по себе апдейт работает медленнее чем просто инсерт или делет, поскольку поиск выполняет...
а поиск по индексу выполняется дольше, чем перестройка индекса ?

-~{}~ 26.02.05 13:34:

bEstard
я не говорил, что это не нормально, читай внимательно.
 

bEstard

Guest
Фанат
И не претендую на знатока MySQL...
Твои рекомендации на 99% полны воды - имел возможность ознакомиться ))

-~{}~ 26.02.05 15:42:

Demiurg
А какие в темповой таблице индексы перестраивать...??
Туда предполагалось заносить временно записи для модерации и связанной ей быть не важно ключом (в случае с удалением), достаточно дублировать ид исходной записи...
Может я постановку неправильно понял?
 

Demiurg

Guest
имеется ввиду вставку в основную таблицу. И вобще при частых апдейтах по одной записи не апдейтят, если, конечно не нужен realtime.
 
Фанат

Фанат

oncle terrible
Команда форума
Твои рекомендации на 99% полны воды
Нажмите для раскрытия...
опять же. чьё это мнение? лоха и недоучки.
цена такому мнению? грош.
однако оно показательно. видно, что наш собеседник не только дурачок, но и выскочка. или, по-компьютерному говоря - ламер. сам сопли еще не утёр, а уже других учить полез.
 

bEstard

Guest
Фанат
Без комментариев..., спрашивал не ты, не тебе и отвечал...
 

uchenik

Новичок
webxtor

Сколько модераторам нужно проверить записей в день? 100-500? Такое количество «лишних» записей в таблице на скорости выборки никак не скажется. Твое решение с дополнительным полем moderated наиболее логично. Кстати для 300 тыс. записей проверка условия «moderated=1» сколько-нибудь заметно выборку не замедлит.

Поэтому нет никакого смысла мучатся с дополнительной таблицей – в скорости не выиграешь, а проблем добавишь.
 

webxtor

Новичок
Demiurg
А как же ж сэмулировать такое количество запросов? Я вот потому что не имею возможности все протестировать или точнее предсказать, обратился в форум за советами тех, кто такую возможность имел!

bEstard

Ты понял все верно!! И мне кажется, что для ускорения выборок правда резонно делать дублирование полей! Хотя это к теме не относится..

uchenik

Да.. примерно столько! Тут просто понимаешь в чем дело.. если я буду хранить эти временные записи в той же таблице, то она будет постоянно расти.. будет расти максимальный ID (тот, который auto_increment), повысится вероятность краха.. Ведь эта таблица преднозначена сугубо для хранение инфы, а не для постоянного добавления/удаление полей..

И проблемы будут в любом случае: после модерации ведь как ни крути придется удалять (ну или обновлять на пустые поля) отмодерированные данные и заменять существующие, а не просто поменять moderated=1 (на тут случай, если тебе так показалось..)

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

Какие у вас есть еще мысли, ребятки? :)

Фанат

Прежде чем говорить, люди учатся. Чему может научить человек, который не умеет говорить?
Не зря вспомнил ты видимо про детей.. ты видно с ними любишь общаться по тебе известным причанам, а тут люди взрослые, культурные и говорящие по существу, в отличие от детей!
Детский сад не тут.
 

Demiurg

Guest
>А как же ж сэмулировать такое количество запросов?
способов очень много ab(Apache Benchmark), например или самому написать что-то более интелектуальное.
 

webxtor

Новичок
Имеется в виду, написать скрипт, который скажем многопотоково будет запускать определенные запросы и запоминать время их исполнения?

Хм.. еще что-ли и сгенерировать наполнение данных всяким мусором? Это конечно лешит всех сомнений, спасибо за такю очевидную идею! Я это обязательно сделаю! Но пока нет времени.. хотелось бы еще немного послушать опытных в этом деле людей, и сделать как они говорят! :) А потом уже когда будет время для досуга, сделать тестер такой!
 

Demiurg

Guest
это все умеет ab. Если еще нужен какой то анализ, то писать придется самому.
 

webxtor

Новичок
У апаче конечно.. случайно забыл указать в предидущем посте...
 
Войдите или зарегистрируйтесь для ответа.
Сверху