

Hold a sec. Rolling your own RDBMS out of a NoSQL database is insane. But is the opposite feasible? Wouldn’t it be a simple table with two columns: a key and a JSON blob?
Hold a sec. Rolling your own RDBMS out of a NoSQL database is insane. But is the opposite feasible? Wouldn’t it be a simple table with two columns: a key and a JSON blob?
Gotcha. Thanks!
Right, RDBMS for object permanence is a pain. It’s meant as efficient data storage and retrieval. But I counter that a huge amount of data problems are of that kind, and using object permanence for general database applications seems very contrived. I’m imagining loading a huge amount of data to memory to filter the things you need, essentially rolling your own DBMS. Am I missing something?
I don’t know if it was you, but thanks for the initiative.
Still under the umbrella and control of the Mozilla organization. Just a different subsidiary from Firefox. The concerns are very valid.
Right, and you’d never do a search for messages with a particular reaction, so there’s no functionality loss is this use case.
What I’m hearing is that they’re very different beasts for very different applications. A typical web app would likely need both.
Let me see if I got it. It would be like a denormalized table with a flexible number of columns? So instead of multiple rows for a single primary key, you have one row (the file), whose structure is variable, so you don’t need to traverse other tables or rows to gather/change/delete the data.
The downsides are the usual downsides of a denormalized DB.
Am I close?
That’s very Windows-y.
Reduce, Reuse, Recycle; in that order. Recycling is always the most expensive option.
Got it, thanks.