Rules for Data Modeling with DynamoDB

Post by danenania » Thu, Apr 09, 2020, 6:15 AM UTC

AmericanChopper wrote: post #74

owenmarshall wrote: post #60

Earlier quoted context omitted.

Are there any basic examples you can give around maintaining that integrity? I'm liking DynamoDB for tasks that fit nicely within a single domain, have relatively pain-free access patterns, etc. And I've found good fits, but there are some places where the eventual consistency model makes me nervous. I'm specifically thinking about updating multiple different DynamoDB keys that might need to be aggregated for a data…

> Are there any basic examples you can give around maintaining that integrity? For those types of use cases, the OP’s advice would actually require implementing a fully bespoke concurrency control system in your business logic layer. Without trying to disparage the OP, this is for all intents and purposes, impossible (aside from also being very, very impractical). There’s some things you can do to create additional a…

Post by Ari_Ugwu » Thu, Apr 09, 2020, 12:46 PM UTC

__afk__ wrote: post #66

mabbo wrote: post #57

Earlier quoted context omitted.

I'm reminded of being 18, my first year of college, and I had this lovely database professor who was good with crowds. He'd get us all to memorize and repeat, as a group certain phrases. "Why do we normalize?" 150 students, in unison: "To make better relations" "And why do we DE-normalize?" 150 students, in unison: "Performance" "And what is a database?" 150 students, in unison: "A self-describing set of integrated r…

Self-describing? Maybe to someone who could make sense of the DDL and read the language the label col names are written in. And understand all the implicit units, rules around nulls/empties, and presence of magic strings (SSN, SKU) and special numbers (-1) and on and on. For that you need something like RDF and a proper data model.