I really like your example. This resonates with my experience as well.
I have observed at least 2 main reasons for data that is traditionally CRUD.
For humans
codes/names for identification - Because humans more easily recognize words than arbitrary numbers (IDs).
descriptions/notes/status text for understanding context and history
For software, configuration affecting run-time operation - E.g. One course requires a grade of 70 to pass. Another course, 60.
These are really two orthogonal dimensions of a given concept, but are typically packaged together for convenience.
Side tangent: I find that almost invariably, the human side of the data requires some manner of set-based constraints... the kind typically found in relational databases. Example: Humans gets really confused if there are 2 MATH101 in the course catalog. Or if PASCAL100 (a deactivated course) shows up in the catalog. So some parts of the data must be indexed for human consumption. While practicing event sourcing, I've often thought I could use a "database" product that allows me to directly update different indexes without requiring them to be attached to a table. I guess it'd be a key-value store but one that allowed me to choose the key index algorithm (hash, b+, reverse, etc) on each collection. If you know of a database product that does this, let me know. For now, I use relational tables and attach indexes to them. It's less efficient (2 copies of key data, 2 places to update, relational engine overhead), but it's already a solved problem.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I really like your example. This resonates with my experience as well.
I have observed at least 2 main reasons for data that is traditionally CRUD.
These are really two orthogonal dimensions of a given concept, but are typically packaged together for convenience.
Side tangent: I find that almost invariably, the human side of the data requires some manner of set-based constraints... the kind typically found in relational databases. Example: Humans gets really confused if there are 2
MATH101in the course catalog. Or ifPASCAL100(a deactivated course) shows up in the catalog. So some parts of the data must be indexed for human consumption. While practicing event sourcing, I've often thought I could use a "database" product that allows me to directly update different indexes without requiring them to be attached to a table. I guess it'd be a key-value store but one that allowed me to choose the key index algorithm (hash, b+, reverse, etc) on each collection. If you know of a database product that does this, let me know. For now, I use relational tables and attach indexes to them. It's less efficient (2 copies of key data, 2 places to update, relational engine overhead), but it's already a solved problem.