4 ms·
To use your terminology, why wouldn't we want everything to be fast, dynamic, and unified? My assumption was that this is provably impossible - that well struc
by andreyf 17y ago
To use your terminology, why wouldn't we want everything to be fast, dynamic, and unified?
My assumption was that this is provably impossible - that well structured data will always be more efficient to interact with, but on second thought, I can't think of a good reason for that. To the contrary, it seems computational speed is unbounded, while the database size/speed we need are (for most current problems) bounded. Hence, "relatively slow" is going to be "fast enough" more and more often.
- gruseom 17y agoon second thought, I can't think of a good reason for that Isn't it simply that if you know the structure in advance, you don't have to figure out what it is at runtime? I agree that the tradeoff becomes moot if you can get both sides fast enough. The question is whether present-day hardware has gotten us to that point. That's why FluidDB is an interesting test case of whether a system supporting arbitrary flexibility can perform at scale. I assume Terry isn't being naive about this, which means he must be making some tradeoffs somewhere. The question I'd like the answer to is, what battles is he consciously not trying to fight (at a design level)? Terry Jones, if you're reading this, please speak up :)