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

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

1 голос
/ 16 января 2010

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

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

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

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

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

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

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

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

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

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

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

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

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

-cv

1 Ответ

2 голосов
/ 16 января 2010

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

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

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

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

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

  • История обслуживания: идентификатор, идентификатор пользователя, идентификатор службы, дата начала, дата окончания

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

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

Это похоже на вашу проблему. Вам необходимо знать:

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

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

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

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

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

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

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

...