Your senior colleague is a developer, not a data modeller. You are better off starting from scratch, without them. Normalisation is complicated only to those who will not read books. It is fair enough that he makes you think, but some of the issues are absurd. Your numbers: You need to appreciate the differences between … Read more
The two most common reasons to denormalize are: Performance Ignorance The former should be verified with profiling, while the latter should be corrected with a rolled-up newspaper 😉 I would say a better mantra would be “normalize for correctness, denormalize for speed – and only when necessary”
I believe post_save is too late to retrieve the unmodified version. As the name implies the data has already been written to the db at that point. You should use pre_save instead. In that case you can retrieve the model from the db via pk: old = Vote.objects.get(pk=instance.pk) and check for differences in the current … Read more
Denormalization is generally used to either: Avoid a certain number of queries Remove some joins The basic idea of denormalization is that you’ll add redundant data, or group some, to be able to get those data more easily — at a smaller cost; which is better for performances. A quick examples? Consider a “Posts” and … Read more
This is subjective but the following solution worked for me, my team, and our DB team. At the application layer, Microservices are decomposed to semantic function. e.g. a Contact service might CRUD contacts (metadata about contacts: names, phone numbers, contact info, etc.) e.g. a User service might CRUD users with login credentials, authorization roles, etc. … Read more
Denormalising to improve performance? It sounds convincing, but it doesn’t hold water. Chris Date, who in company with Dr Ted Codd was the original proponent of the relational data model, ran out of patience with misinformed arguments against normalisation and systematically demolished them using scientific method: he got large databases and tested these assertions. I … Read more