литература, методы и методы моделирования исторических данных

Question

В прошлом году мы запустили http://tweetMp.org.au - сайт, посвященный австралийской политике и твиттеру.

В конце прошлого года наш политик схемы необходимо скорректировать, потому что некоторые политики в отставку и новые политики пришли.

Изменение нашей БД требуется ручное (SQL) изменение, поэтому я рассматриваю реализации CMS для наших админов, чтобы сделать эти изменения в будущем.

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

Я хотел бы предложить централизованный способ сделать это.

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

Используя этот подход, другие сайты могут «подписаться» на изменения (a la` pubsubhub) и представить изменения и просто интегрировать эти элементы изменения в свои схемы.

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

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

Конечно, непосредственные задачи и вопросы проектирования при таком подходе включает

• является текущий вид кэшируются и repersisted? как часто он обновляется?
• Какие базовые сущности должны существовать, которые никогда не меняются?
• вероятно осыпает больше я не могу думать прямо сейчас ...

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

Любая помощь очень ценится.

-CV

Answer 1

Это довольно распространенная проблема моделирования данных. В основном это сводится к следующему:

Вы заинтересованы в просмотре сейчас, вид в определенный момент времени или оба?

Например, если у вас есть услуга, которая моделирует подписки вам нужно знать:

• Какие услуги у кого-то в определенный момент времени: это необходимо для работы, сколько для зарядки, видеть историю счета и т. д .; и
• Какие услуги у кого-то есть сейчас: что они могут получить на Сайте?

Отправной точкой для такого рода проблемы, чтобы иметь таблицу истории, такие как:

• Service История: идентификатор, идентификатор пользователя, ServiceID, дата_начала end_date

цепь вместе истории обслуживания для пользователя, и у вас есть их история. Итак, как вы моделируете то, что у них есть сейчас? Самый простой (и наиболее денормализованный вид) состоит в том, чтобы сказать, что последняя запись или запись с датой окончания NULL или текущая или будущая дата окончания - это то, что у них есть сейчас.

Как вы можете себе представить, это может привести к некоторому gnarly SQL, поэтому это выборочно деномализировано, поэтому у вас есть таблица Services и другая таблица для истории. При каждом изменении Службы создается или обновляется запись истории. Такой подход делает таблицу истории более аудиторской таблицей (другой термин, о котором вы увидите).

Это аналог вашей проблемы. Вы должны знать:

• Кто является нынешним депутатом парламента для каждого места в Палате представителей;
• Кто является нынешним сенатором для каждого места;
• Кто является нынешним министром для каждого отдела;
• Кто является премьер-министром.

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

Так на 20 августа 2003 года, Питер Костелло сделал пресс-релиз, Вы должны были бы знать, что в это время он был:

• Член для Хиггинса;
• Казначей; и
• Заместитель премьер-министра.

потому что, возможно, кому-то может быть интересно найти все пресс-релизы Питера Костелло или Казначея, которые приведут к тому же пресс-релизу, но невозможно будет отслеживать без истории.

Кроме того, вам может потребоваться узнать, в каких местах находятся государства, возможно, географические границы и т. Д.

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