昨年 、オーストラリアの政治とツイッター専用のサイトhttp://tweetMp.org.auを立ち上げました。
昨年末、一部の政治家が引退し、新しい政治家が登場したため、政治家のスキーマを調整する必要がありました。
データベースを変更するには手動 (SQL) の変更が必要だったため、管理者が将来これらの変更を行えるように CMS を実装することを検討していました。
また、独自の政治家データを管理するオーストラリア向けの政府/政治サイトが他にも多数あります。
これを集中的に行う方法を考え出してみたいと思います。
しばらく考えてみると、おそらく最善のアプローチは、政治家データの現在のビューと政治システムとの関係をモデル化するのではなく、トランザクションをモデル化することです。現在のビューは、過去に発生したすべてのトランザクション/変更の予測です。
このアプローチを使用すると、他のサイトは変更を「サブスクライブ」して (いわゆる pubsubhub)、変更を送信し、これらの変更項目をスキーマに統合することができます。
このアプローチがなければ、ほとんどのサイトはデータベース全体を破棄して再作成する必要があるため、関連するレコードを再関連付けする必要があります。このような方法でデータを管理するのは非常に煩わしく、公共の利益のためにこのデータをマッシュアップすることは非常に妨げられます。
ソースバージョン管理、銀行記録、スタックオーバーフローポイントシステム、その他多くの例で、いくつかのことがこのように機能することに気付きました。
もちろん、このアプローチの差し迫った課題と設計上の問題には、次のようなものがあります。
- 現在のビューはキャッシュされ、再保存されていますか? どのくらいの頻度で更新されますか?
- 決して変わらない基本エンティティーが存在する必要があるのはどれですか?
- おそらく今は考えられないほどたくさんあります...
この主題に関して、誰もが推薦できる注目すべき文献はありますか? また、このようなデータ モデリングに役立つパターンやプラクティスはありますか?
どんな助けでも大歓迎です。
-履歴書