databases are not designed to be browsed.
Casey Newton makes this blanket statement. Any real evidence for this beyond his "gut"?
Many "paper machines" like Niklas Luhmann's zettelkasten were almost custom made not just for searching, but for browsing through regularly much like commonplace books.
Perhaps the question is really, how is your particular database designed?
Don't worry about performance too early though - it's more important to get the design right, and "right" in this case means using the database the way a database is meant to be used, as a transactional system.
Coles, Stephen. “This Just In: Schriftenkartei, a Typeface Index.” Letterform Archive, November 3, 2023. https://letterformarchive.org/news/schriftenkartei-german-font-index/.
Example of a zettelkasten covering the available typefaces produced from 1958 and 1971 in West Germany.
These callbacks are focused on the transactions, instead of specific model actions.
At least I think this is talking about this as limitation/problem.
The limitation/problem being that it's not good/useful for performing after-transaction code only for specific actions.
But the next sentence "This is beneficial..." seems contradictory, so I'm a bit confused/unclear of what the intention is...
Looking at this project more, it doesn't appear to solve the "after-transaction code only for specific actions" problem like I initially thought it did (and like https://github.com/grosser/ar_after_transaction does), so I believe I was mistaken. Still not sure what is meant by "instead of specific model actions". Are they claiming that "before_commit_on_create" for example is a "specific model action"? (hardly!) That seems almost identical to the (not specific enough) callbacks provided natively by Rails. Oh yeah, I guess they do point out that Rails 3 adds this functionality, so this gem is only needed for Rails 2.
Object hierarchies are very different from relational hierarchies. Relational hierarchies focus on data and its relationships, whereas objects manage not only data, but also their identity and the behavior centered around that data.
Delegated types newly introduced here looks like a Class Table Inheritance (CTI).
A very visible aspect of the object-relational mismatch is the fact that relational databases don't support inheritance. You want database structures that map clearly to the objects and allow links anywhere in the inheritance structure. Class Table Inheritance supports this by using one database table per class in the inheritance structure.
I suggest to make it UNIQUE because it seems like the column should be unique
The takeaway from the article: Choose document-oriented database only when the data can be treated as a self-contained document