4 ms·
I think this is the much of the reason document dbs are popular. If you have an array in your struct, just save it. Having used mongoDB in the past, for me it
by gregwebs 5y ago
I think this is the much of the reason document dbs are popular. If you have an array in your struct, just save it.
Having used mongoDB in the past, for me it was a better day 1 experience. I didn’t need SQL, I just stored my data. The problem is that on day 2 there’s a different access pattern for your data but now it’s stored in a way that’s highly optimized only for that first application.
- evanweaver 5y agoIf only there was some database that let you store flexibly structured documents but keep the data normalized. Perhaps you could even construct views and indexes to accelerate different access patterns.
- teitoklien 5y agoSounds a lot like sql databases with json extension to me
- yellowapple 5y agoI suspect that might indeed have been the joke.
- bob1029 5y agoIf only. Can you imagine if we also had some form of normalization so complete that it could actually manage an arbitrary number of dimensions? Can you tell me how many times that users email address changed in that document over the last 3 years by executing a simple query? What was the email after the 2nd time it changed? In 6th normal form, such a thing is trivial to manage. Discipline is the only price to pay for admission.
- evanweaver 5y agoFauna is temporal, so yes. Normal forms not required.
- bob1029 5y agoDoes Fauna support multiple temporal dimensions in the same query?
- evanweaver 5y agoCan you give me an example of the kind of query you have in mind?
- bob1029 5y agoI think your original claim is where I would like to focus my argument: > Normal forms not required. 3NF (approximately where document databases live) struggles to decouple the time domain from individual facts. Let me give you an example. Assume a Customer document has a LastModifiedUtc property. Does this tell you when their email specifically changed? No. It just says "something" in the customer document was modified. Now, you could say "how about we just add a property per thing I want to track?" Ok - so we now have Customer.EmailLastModifiedUtc, Customer.NameLastModifiedUtc, etc. This is pretty good, but now assume we also need to know what the previous email addresses and names were. How do we go about this? Ok - no big deal, lets just add another column that is some JSON array or whatever. Customer.PreviousEmailAddresses. Cool, so now we know when the email was last modified AND we know what every last variant of it was. What is missing? Oh right. What about when each of the previous email addresses actually changed? Who changed it? From what IP address? Certainly, we could nest a collection of documents within our document to keep track of all of this, but I hope the point is starting to come across that there may be some value in exploring higher forms of normalization. Imagine if I wanted to determine all of the email addresses that were modified by a specific IP address (across ALL customers), but only over the last 25 days. I feel like this is entirely out of the scope of a document database. Don't get me wrong. 3NF is extremely powerful and handles many problem domains with total ease. But, once you start talking about historization of specific fields and rates of change, you may need to consider something higher order.
- jimsimmons 5y ago