Hello, I've got a database related design question. Let me explain it by using an example:
I've got Entities of the kind "*Article*" with the following properties: - title - userId - .... - *sumOfScore* SumOfScore should be the sum of all related "*Score*" entities, which have properties like: - articleId - userId - *score* In Pseudo-SQL: sumOfScore = select sum(score) from Score where score.articleId = article.id I see two possibilities to design this: *1.) No property sumOfScore for Articles; but query always:* This means: Every time an article is read, I need to do an query for this specific article for calculating the sumOfScore. Imagine a list of 100 Articles that is shown to a user. This would need additional 100 queries to the database, just to show the score for each article. Nevertheless: This would be my preferred way when using a Relational-DB. No redundancy and good normalization. And with SQL you can use just one join-select to catch all data. But it doesn't feel right for Google's BigTable. * 2.) Calculate the sumOfScore whenever Score entities are changed:* This means: Whenever a Score-Entity is added, removed or changed, the related Article updates the sumOfScore property. Advantage: When reading articles no additional queries are needed. The sumOfScore is redundant on the entity itself. Disadvantage: Every time a score is changed, there is one additional query and an additional write (updating an Article entity). And sumOfScore may mismatch with the actual Score entities (e.g. value is changed via DB-Console) What are more experienced people think? Is there a common best practice for such scenario? Thank a lot Mos -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
