лучший подход MySQL?

0

Я пишу приложение, которое отображает сообщения, как простая система форума. Сообщения могут быть отмечены как срочные для пользователей при отправке сообщения, но модератор должен утвердить "срочный" статус. Сообщение будет по-прежнему отображаться, даже если оно не было утверждено как срочное, но будет выглядеть как обычная почта, пока модератор не одобрит срочный статус, после которого сообщение получит специальное лечение.

Я рассмотрел два подхода для этого:

1) имеют два флага в таблицах сообщений. Один из них сказал, что пользователь запросил срочный статус, а второй указал, одобрил ли администратор срочный статус. Только если оба они верны, пост будет показан как срочный.

2) имеют две таблицы. Запрошенная таблица ожидания, в которой хранятся все ожидающие срочные разрешения. После того, как администратор утвердит срочный статус, я удалю запрос из ожидающей таблицы и обновит таблицу сообщений, чтобы поле срочности стало истинным для этой записи.

Я не уверен, что любой подход лучше, чем другой.

Первое решение означает, что у меня есть только одна таблица, о которой нужно беспокоиться, но в ней больше полей. Не уверен, что это фактически делает запрос медленнее или нет, учитывая, что таблица сообщений будет самой запрашиваемой таблицей в приложении.

Второе решение сохраняет таблицу сообщений более компактной, чем реклама другой таблицы (не так сложно).

Я склоняюсь к второму решению, но задаюсь вопросом, не перестаю ли я анализировать позы и усложнять жизнь, чем это должно быть. Совет?

Теги:

4 ответа

1
Лучший ответ

Определенно 1). Дополнительный стол просто разбирает вещи. Достаточно одного дополнительного поля состояния со значениями: 0 = нормальный, 1 = срочный_захват, 2 = срочный_приобретенный, например.

Вы можете запросить статус = 1 для запросов, требующих утверждения, и если вы закажете по статусу desc, вы, естественно, получите срочные сообщения вверх.

Поделиться
  • 0
    Какая хорошая идея. В таблице записей уже будет храниться флаг «срочно», но таким образом я могу сложить ожидающий запрос в то же поле. Благодарю.
  • 0
    Ну, это именно то, что я предложил: D выглядит так, будто меня немного неправильно поняли. В моем решении 2-я таблица содержит значения, которые он имеет в виду - это то, что вы написали с 0 = normla и т.д ..
Показать ещё 2 комментария
1

Я думаю, что вариант 1 лучший. Единственное, что вам нужно сделать, это сделать индекс с двумя полями. Опция 2 добавляет слишком много сложности

У меня есть запрос mysql только для таких вещей. Я отправлю его, как только я запомню/найду правильный синтаксис

Поделиться
  • 0
    Вот. Это приведет к тому, что все строки с флагом = 1 пойдут на первое место, а затем все будет отсортировано по «datetime» или какому-либо полю, которое вы используете. ORDER BY CASE WHEN flag = 0 THEN 0 ELSE 1 END, datetime
  • 0
    ошибка, опечатка: замените 0 на 1 и наоборот
Показать ещё 2 комментария
1

Есть другое решение, которое приходит в голову:)

У вас может быть таблица с статусами сообщений, а в вашей таблице Posts вы будете иметь столбец, который ссылается на статус.

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

Поделиться
  • 0
    Мне нравится эта идея, но сейчас я перейду к варианту 1), который пока кажется фаворитом в ответах.
1

Второй подход является самым чистым с точки зрения дизайна, и он, вероятно, в конечном итоге будет использовать меньше дискового пространства. Первый подход менее "чист", но с точки зрения обслуживания и кодирования он проще; поэтому я бы пошел с таким подходом.

Кроме того, здорово видеть, что кто-то думает о дизайне, прежде чем они уйдут и напишутся коды кода.:) Не могу сказать, сколько запутанных проектов я видел, где один час размышлений о дизайне спас бы много часов усилий для всех, кто участвует...

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню