Как организовать структуру

 
0
 
Datenbanken
ava
Samotnik | 17.03.2013, 20:42
Привет.

Ситуация:
Предположим есть сервис с объявлениями. Т.е. человек логиниться, заполняет форму и оставляет объявление на портале. Это объявление сперва проходит модерацию, затем только отображается на портале. Через какое-то время пользователь редактирует объявление, которое перед публикацией опять должно пройти модерацию и так может продолжаться до бесконечности с любым объявлением, пользователь его может редактировать неограниченное кол-во раз. Но при этом оно сразу не отображается на портале, а будет показано только после прохождения модерации.
В этом и загвоздка, что когда юзер подал объявление и оно прошло модерацию, на портале всегда нужно показывать объявление, которое было последним прошедшим модерацию. Т.е. если юзер его отредактировал, оно все равно должно показываться, но должен показываться предыдущий промодерированный вариант.

Вопрос в этом и заключается, как лучше всего хранить в БД объявление и версию, которую нужно отобрадать напортале и ту версию, которая ждет модерацию?
 smile 
Kommentare (19)
ava
Akina | 17.03.2013, 21:04 #
Две (три, более) записи в БД. Все - с одним и тем же номером объявления. Версия, не прошедшая модерацию, имеет NULL в поле даты модерации. Показывается версия, имеющая максимальную дату модерации среди всех с таким номером.
ava
Samotnik | 17.03.2013, 23:27 #
Ну это впринципе стандартный подход, который крутился у меня в головею. Думал может другой вариант какой-нибудь есть. Этот кажется мне каким-то простым. smile 
Но спасибо в любом случае.
ava
Zloxa | 18.03.2013, 14:52 #
Цитата (Akina @ 17.3.2013,  22:04)
Две (три, более) записи в БД. Все - с одним и тем же номером объявления. Версия, не прошедшая модерацию, имеет NULL в поле даты модерации. Показывается версия, имеющая максимальную дату модерации среди всех с таким номером.

Мне не нравится. smile
Тут ведь нагурзка по чтению многократ превышает нагрузку по модификации.

Я бы организовал обособленную очередь модерации. И модераторам проще будет выбрать не отмодерированные сообщения и дополнительная нагрузка по вычислению актуальной версии при отображении уходит, на витрине всегда актуальная отмодерированная версия ибо. Логика постановки сообщения в очередь лишь усложняется.
ava
Akina | 18.03.2013, 15:16 #
Ну сколько там может быть последовательных копий объявления? десяток? два? к тому же не факт, что их все необходимо хранить, что нужна вся история правки от рождения до смерти и после... так что при наличии индекса (НомерОбъявления - ДатаМодерации) выборка будет ненамного накладнее, если кроме установленных дат там будут ещё и NULL-даты. По-моему, очередь модерации, с переносом зааппрувленных объявлений в публикации - неоправданное усложнение. А ведь ещё есть вариант редактирования незааппрувленного сообщения.
ava
Zloxa | 18.03.2013, 15:22 #
Akina, выбери из своей структуры все сообещния, подлежащие модерации.

Цитата (Akina @  18.3.2013,  16:16 findReferencedText)
ненамного накладнее,

Зависит от того, на сколько эта накладность умножается.
Если ружье стреляет раз в год, то триста ружей будут стрелять почти каждый день.
ava
Akina | 18.03.2013, 15:49 #
Цитата (Zloxa @  18.3.2013,  16:22 findReferencedText)
выбери из своей структуры все сообещния, подлежащие модерации.

Если ВСЕ - то индекс по дате аппрува и select * from adverts where dtApproved is null ... а что?
ava
Zloxa | 18.03.2013, 15:59 #
Цитата (Akina @  18.3.2013,  16:49 findReferencedText)
select * from adverts where dtApproved is null 

Маська использует индекс по is null?

Оракл, в общем случае - нет.
ava
Akina | 18.03.2013, 18:32 #
Цитата (Zloxa @  18.3.2013,  16:59 findReferencedText)
Маська использует индекс по is null?

Цитата


MySQL can perform the same optimization on col_name IS NULL that it can use for col_name = constant_value. For example, MySQL can use indexes and ranges to search for NULL with IS NULL. 



Examples: 





SELECT * FROM tbl_name WHERE key_col IS NULL;



SELECT * FROM tbl_name WHERE key_col <=> NULL;



SELECT * FROM tbl_name
   WHERE key_col=const1 OR key_col=const2 OR key_col IS NULL;



If a WHERE clause includes a col_name IS NULL condition for a column that is declared as NOT NULL, that expression is optimized away. This optimization does not occur in cases when the column might produce NULL anyway; for example, if it comes from a table on the right side of a LEFT JOIN. 



MySQL can also optimize the combination col_name = expr OR col_name IS NULL, a form that is common in resolved subqueries. EXPLAIN shows ref_or_null when this optimization is used. 



This optimization can handle one IS NULL for any key part. 

ava
Zloxa | 18.03.2013, 18:59 #
Цитата (Akina @  18.3.2013,  19:32 findReferencedText)
<=>

а щтойта?

Эквиалент выражения (a=b or a is null and b is null)?
ava
Akina | 18.03.2013, 20:02 #
Цитата


<=> 



NULL-safe equal. This operator performs an equality comparison like the = operator, but returns 1 rather than NULL if both operands are NULL, and 0 rather than NULL if one operand is NULL. 

ava
Samotnik | 18.03.2013, 22:24 #
а что делать со связанными таблицами? тоже все дублировать? ))
ava
Akina | 19.03.2013, 07:51 #
Цитата (Samotnik @  18.3.2013,  23:24 findReferencedText)
что делать со связанными таблицами? тоже все дублировать?

Какими связанными таблицами? почему - дублировать?
ava
Samotnik | 19.03.2013, 09:26 #
ну объявление хранится ни в одной таблице, а в трех. Основная часть инфы конечно же в одной, но есть некоторая инфа, например адресс, город,Ю которые хранятся в друних таблицах по связям
ava
Akina | 19.03.2013, 09:39 #
и что?
ava
Samotnik | 19.03.2013, 10:03 #
ну как что smile давай тогда сначала.
Есть объявление, которое в случае редактирование нужно не затирать старые, а создавать в бд запись новые записи с тем же номером объявления.
Это твоя мысль в первом пеосте была.
Теперь я уточняю, что объявление находится не в одной таблице, а в нескольких, т.е. есть свзяанная инфа в других таблицах. ТУ инфу тоже может пользователь отредактировать может. Получается что там тоже нужно хранить две и более записи?
ava
Akina | 19.03.2013, 10:16 #
Цитата (Samotnik @  19.3.2013,  11:03 findReferencedText)
объявление находится не в одной таблице, а в нескольких, т.е. есть свзяанная инфа в других таблицах. ТУ инфу тоже может пользователь отредактировать может. Получается что там тоже нужно хранить две и более записи? 

ОБЯЗАТЕЛЬНО. Даже если пользователь НЕ редактировал сведения. хранящиеся в связанной таблице.

später ergänzt:
С другой стороны - а какой смысл был дробить таблицу, если это фактическая связь один-к-одному?
ava
LSD | 19.03.2013, 10:29 #
Цитата (Akina @  19.3.2013,  11:16 findReferencedText)
С другой стороны - а какой смысл был дробить таблицу, если это фактическая связь один-к-одному? 

Есть подозрение, что адрес будет один на несколько объявлений.
ava
Samotnik | 19.03.2013, 23:59 #
Цитата (LSD @  19.3.2013,  10:29 findReferencedText)
Есть подозрение, что адрес будет один на несколько объявлений. 

В точку! Это еще один большой вопрос, который нужно бкдет завтра решить. smile 
Но это уже вопрос программирования, а не структуры БД. Тут шлавное именно с логикой БД не ошибиться, что бы потом все не переделывать
ava
Akina | 20.03.2013, 08:07 #
Цитата (LSD @  19.3.2013,  11:29 findReferencedText)
Есть подозрение, что адрес будет один на несколько объявлений. 

Мне не кажется разумным в этом случае устраивать связь один-ко-много...

Цитата (Samotnik @  20.3.2013,  00:59 findReferencedText)
это уже вопрос программирования, а не структуры БД. 

Вот как раз нет. Как только организуется (утверждается тобой в структуре) связь один-ко-много, надо принимать политическое решение - либо адреса в этом случае не модерируются, либо они модерируются независимо от объявления (при этом изменение в части "адрес" ставит на модерирование не только изменённый адрес, но и все объявления, где он используется). Это первое. И второе - перенос решения этого вопроса в программирование приводит к разрыву логики на куски, один из которых остаётся на уровне СУБД, второй выносится на клиента.

später ergänzt:
Другое дело, что для хранения ШАБЛОНА адреса можно использовать отдельную таблицу, и помещать подготовленный юзером адрес в объявление нажатием одной кнопки.
Registrieren Sie sich oder melden Sie sich an, um schreiben zu können.
Unternehmen des Tages
Вы также можете добавить свою фирму в каталог IT-фирм, и публиковать статьи, новости, вакансии и другую информацию от имени фирмы.
Подробнее
Mitwirkende
ava  LSD   Akina   Samotnik ava  Zloxa
advanced
Absenden