| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > СУБД, общие вопросы > Как организовать структуру |
| Автор: Samotnik 17.3.2013, 19:42 |
| Привет. Ситуация: Предположим есть сервис с объявлениями. Т.е. человек логиниться, заполняет форму и оставляет объявление на портале. Это объявление сперва проходит модерацию, затем только отображается на портале. Через какое-то время пользователь редактирует объявление, которое перед публикацией опять должно пройти модерацию и так может продолжаться до бесконечности с любым объявлением, пользователь его может редактировать неограниченное кол-во раз. Но при этом оно сразу не отображается на портале, а будет показано только после прохождения модерации. В этом и загвоздка, что когда юзер подал объявление и оно прошло модерацию, на портале всегда нужно показывать объявление, которое было последним прошедшим модерацию. Т.е. если юзер его отредактировал, оно все равно должно показываться, но должен показываться предыдущий промодерированный вариант. Вопрос в этом и заключается, как лучше всего хранить в БД объявление и версию, которую нужно отобрадать напортале и ту версию, которая ждет модерацию? |
| Автор: Akina 17.3.2013, 21:04 |
| Две (три, более) записи в БД. Все - с одним и тем же номером объявления. Версия, не прошедшая модерацию, имеет NULL в поле даты модерации. Показывается версия, имеющая максимальную дату модерации среди всех с таким номером. |
| Автор: Samotnik 17.3.2013, 23:27 |
| Ну это впринципе стандартный подход, который крутился у меня в головею. Думал может другой вариант какой-нибудь есть. Этот кажется мне каким-то простым. Но спасибо в любом случае. |
| Автор: Zloxa 18.3.2013, 14:52 | ||
Мне не нравится. Тут ведь нагурзка по чтению многократ превышает нагрузку по модификации. Я бы организовал обособленную очередь модерации. И модераторам проще будет выбрать не отмодерированные сообщения и дополнительная нагрузка по вычислению актуальной версии при отображении уходит, на витрине всегда актуальная отмодерированная версия ибо. Логика постановки сообщения в очередь лишь усложняется. |
| Автор: Akina 18.3.2013, 15:16 |
| Ну сколько там может быть последовательных копий объявления? десяток? два? к тому же не факт, что их все необходимо хранить, что нужна вся история правки от рождения до смерти и после... так что при наличии индекса (НомерОбъявления - ДатаМодерации) выборка будет ненамного накладнее, если кроме установленных дат там будут ещё и NULL-даты. По-моему, очередь модерации, с переносом зааппрувленных объявлений в публикации - неоправданное усложнение. А ведь ещё есть вариант редактирования незааппрувленного сообщения. |
| Автор: Zloxa 18.3.2013, 15:22 |
| Akina, выбери из своей структуры все сообещния, подлежащие модерации. Зависит от того, на сколько эта накладность умножается. Если ружье стреляет раз в год, то триста ружей будут стрелять почти каждый день. |
| Автор: Akina 18.3.2013, 15:49 |
Если ВСЕ - то индекс по дате аппрува и select * from adverts where dtApproved is null ... а что? |
| Автор: Zloxa 18.3.2013, 15:59 |
Маська использует индекс по is null? Оракл, в общем случае - нет. Добавлено через 2 минуты и 20 секунд У нас есть 100500 сообщений, из них не модерировано 100. Индекс по 100400 значениям нам не нужен |
| Автор: Akina 18.3.2013, 18:32 | ||||
|
| Автор: Zloxa 18.3.2013, 18:59 |
а щтойта? верна ли догадка что выражение (a<=>b) эквивалентно (a=b or a is null and b is null)? |
| Автор: Akina 18.3.2013, 20:02 | ||
|
| Автор: Samotnik 18.3.2013, 22:24 |
| ребята, вы отдалились а что делать со связанными таблицами? тоже все дублировать? )) |
| Автор: Akina 19.3.2013, 07:51 |
Какими связанными таблицами? почему - дублировать? |
| Автор: Samotnik 19.3.2013, 09:26 |
| ну объявление хранится ни в одной таблице, а в трех. Основная часть инфы конечно же в одной, но есть некоторая инфа, например адресс, город,Ю которые хранятся в друних таблицах по связям |
| Автор: Akina 19.3.2013, 09:39 |
| и что? |
| Автор: Samotnik 19.3.2013, 10:03 |
| ну как что Есть объявление, которое в случае редактирование нужно не затирать старые, а создавать в бд запись новые записи с тем же номером объявления. Это твоя мысль в первом пеосте была. Теперь я уточняю, что объявление находится не в одной таблице, а в нескольких, т.е. есть свзяанная инфа в других таблицах. ТУ инфу тоже может пользователь отредактировать может. Получается что там тоже нужно хранить две и более записи? |
| Автор: LSD 19.3.2013, 10:29 | ||
Есть подозрение, что адрес будет один на несколько объявлений. |
| Автор: Samotnik 19.3.2013, 23:59 |
В точку! Это еще один большой вопрос, который нужно бкдет завтра решить. Но это уже вопрос программирования, а не структуры БД. Тут шлавное именно с логикой БД не ошибиться, что бы потом все не переделывать |
| Автор: Akina 20.3.2013, 08:07 |
Мне не кажется разумным в этом случае устраивать связь один-ко-много... Вот как раз нет. Как только организуется (утверждается тобой в структуре) связь один-ко-много, надо принимать политическое решение - либо адреса в этом случае не модерируются, либо они модерируются независимо от объявления (при этом изменение в части "адрес" ставит на модерирование не только изменённый адрес, но и все объявления, где он используется). Это первое. И второе - перенос решения этого вопроса в программирование приводит к разрыву логики на куски, один из которых остаётся на уровне СУБД, второй выносится на клиента. Добавлено через 2 минуты Другое дело, что для хранения ШАБЛОНА адреса можно использовать отдельную таблицу, и помещать подготовленный юзером адрес в объявление нажатием одной кнопки. |