Сообщения

1

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

« : 27 Февраля 2005, 13:30:45 »

2. Имеется в виду и количество записей и неоправданно постоянно увеличивающийся id (который auto_increment) с каждым новым редактированием. И мне казалось, что увеличение запросов к таблице (кроме выборки будут еще запросы касательно редактирования и  модерирования) снизит производительность и надежность хранения данных. Однако, похоже для таких средних обьемов боятся нечего..

3. Ну вот у меня есть таблица моя. Из нее идет выборка по id или по category_id. Если в этой же таблице хранить еще и данные, ожидающие модерации, то нужно будет добавить еще как минимум одно поле - original_id. Теперь я думаю, что можно поле category_id для таких записей оставлять пустым, и оно автоматически не будет участвовать в выборке. Ну а moderated будет указывать на то, вынес ли модератор какое-то решение касательно этой записи или нет.

Тогда возникает вопрос: Что делать после одобрения редактирования модератором?
-удалять временную запись, обновить оригинальную
-или же обновить все поля на пустые вместо удаления, а original_id оставить, и при повторном редактировании использовать эту же временную запись

2

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

« : 26 Февраля 2005, 12:46:33 »

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

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

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

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

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

3

Базы данных / Обсуждение статьи ДЕРЕВО КАТАЛОГОВ NESTED SETS (ВЛОЖЕННЫЕ МНОЖЕСТВА) И УПРАВЛЕНИЕ ИМ

« : 18 Февраля 2005, 23:48:57 »

Phoinix:
ни фига себе изврат

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

Очень часто на сайтах необходимо отобразить все главные категории и несколько дочерних (потом обычно идет троеточие).

Вот я и хочу сделать все как можно меньшим количеством запросов.

Привожу пример:

http://www.alibaba.com/companies/0/company.html

4

Базы данных / Обсуждение статьи ДЕРЕВО КАТАЛОГОВ NESTED SETS (ВЛОЖЕННЫЕ МНОЖЕСТВА) И УПРАВЛЕНИЕ ИМ

« : 18 Февраля 2005, 23:34:32 »

А как 2мя?

А еще вот. Нужно посчитать сколько всего компаний в родительских категориях и их детях,при этом выводя только первый уровень.

Придумал вот:

SELECT count( comps.id ) , cats1.name
FROM companies AS comps, categories AS cats, categories
as cats1
where cats.id = comps.category_id
and cats.right_key <= cats1.right_key
and cats.left_key >= cats1.left_key
and cats1.level = 1
GROUP BY cats1.name

Работает, но думает треть секунды.. может можно как-то обойтись 2мя таблицами?

5

Базы данных / Обсуждение статьи ДЕРЕВО КАТАЛОГОВ NESTED SETS (ВЛОЖЕННЫЕ МНОЖЕСТВА) И УПРАВЛЕНИЕ ИМ

« : 18 Февраля 2005, 23:31:43 »

Надо еще бы!!

6

Базы данных / Обсуждение статьи ДЕРЕВО КАТАЛОГОВ NESTED SETS (ВЛОЖЕННЫЕ МНОЖЕСТВА) И УПРАВЛЕНИЕ ИМ

« : 17 Февраля 2005, 20:55:26 »

У меня такая проблема.. Нужно одним запросом взять все категории первого уровня и максимум 3 второго, при учете, что я не знаю сколько всего первого