Просмотр «журнала» новых (отдельных) событий в базе данных

Question

У меня есть приложение, в базе которого есть несколько несвязанных таблиц. Я объясню, используя в качестве примера «автоматически обновляемую» версию домашней страницы SO, так что допустим, у меня есть таблицы « users », « comments » и « вопросы ».

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

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

Проблема в том, , что происходит, когда я добавляю новый тип информации, скажем, голоса. Теперь я должен сохранить другую переменную на стороне клиента, а сервер должен опросить другую таблицу. И так далее, для каждого нового типа информации, которую я храню.

Я ищу решение, которое поможет мне избежать этого.

Другая проблема - скажем, я хотел бы видеть все «события», которые произошли с прошлого раза, но отсортированы по времени, когда они произошли.

У меня было одно направление - иметь одну таблицу «событий», которая содержит информацию о том, когда произошло каждое событие. Затем я могу опросить только эту таблицу и получить список всех новых событий, которые произошли. Проблема в том, что каждое событие довольно отличается (у нового комментария есть разные столбцы, чем у нового upvote и т. Д.), Поэтому я не уверен, как это реализовать, или это даже хорошая идея.

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

Спасибо!

Answer 1

Для меня это звучит так, как будто вы пытаетесь заглянуть в будущее через дизайн базы данных. Хотя это можно сделать с помощью модели EVA , я предостерегаю против этого, потому что добавленная стоимость, как правило, не стоит затрат.

Вместо этого вам следует моделировать базу данных как можно ближе к реальности, а не к тому, как вы собираетесь ее использовать.

Затем используйте SQL, чтобы проецировать данные так, как вам нужно. Вы можете сделать это с помощью операторов, которые либо доставят необходимые вам метаданные

, например

Select 
  Count(ID) , 'Comments' Type
From 
  Comments
Where
  lastUpdate > #InputParamter1#
UNION Select 
  Count(ID) , 'Questions' Type
From 
  Questions
Where
  lastUpdate > #InputParamter1#

Или (и это часто не используется)

Возвращает более одного набора результатов из вашей базы данных за один раз

Select 
    userid,
    ComentText
From 
    Comments
 Where
      lastUpdate > #InputParamter1#;
Select
    userId,
    Questions,
    Tags
From 
    Questions
 Where
      lastUpdate > #InputParamter1#

Тем не менее, вам все равно придется написать некоторый код, если вы добавите новый материал, но он должен быть ограничен обновлением вашего sql, добавлением новых контейнеров для ваших данных, а затем кода для отображения конечным пользователям, а затем проверки и сохранения его. .

Честно говоря, идея добавления нового материала, требующего некоторой работы, не кажется мне такой ужасной.