5 ms·

Instead of defining columns on a table, each attribute has its own table (new tables are created on the fly), which means that we can add and remove attri

Instead of defining columns on a table, each attribute has its own table (new tables are created on the fly), which means that we can add and remove attributes at will. In turn, performing a select simply means joining all of the tables on that individual key. ... and now you know why nobody is doing this. Back before NoSQL had a name (and fast implementations) and we would just build key-value stores inside of relational databases and describe them to people as "tall, skinny tables", this was how you would construct a query. Of course, it was a lot easier in a skinny table than the method you describe because you'd simply join the table back on itself n times rather than having n tables sitting around in your database. Regardless, doing things that way was generally regarded as a bad idea even back in the 90's, and was only something to consider when you had highly-configurable things to describe that didn't fit well into a relational structure. Everybody realized that you suffered huge performance hits at query-time, and you were essentially eliminating the possibility of reporting. So no, given that NoSQL is all about using key/value stores to boost performance by trading off reportability, this solution (which actually trades both sides of that equation away) is not a replacement.

timtadh 17y ago
The issue is no matter if you are using a column store or simulating a column store in a row store you will have to do tuple reconstruction. Unless all of you queries really only need one attribute this will require at least one join. Some column stores use clever techniques, like cracker columns, to make these joins faster. This is why a column store may perform better than a row store for specific kinds of queries. But if your queries are constantly asking the dmbs to re-construct the a relation with many attributes a row store may actually work better for you. My point is that the decision to choose your dbms should be driven by, the kind of data you have, and the kind of queries you are going to run. If performance really matters to you, you should really do some empirical testing before choosing the technology. Both there is some give and take here, one is not definitively better than the other. That said I agree with you that this is a bad solution don't simulate a column store with a row store it won't perform as well as a good column store since it is not optimized for tuple reconstruction.

timtadh 17y ago

The issue is no matter if you are using a column store or simulating a column store in a row store you will have to do tuple reconstruction. Unless all of you queries really only need one attribute this will require at least one join. Some column stores use clever techniques, like cracker columns, to make these joins faster. This is why a column store may perform better than a row store for specific kinds of queries. But if your queries are constantly asking the dmbs to re-construct the a relation with many attributes a row store may actually work better for you. My point is that the decision to choose your dbms should be driven by, the kind of data you have, and the kind of queries you are going to run. If performance really matters to you, you should really do some empirical testing before choosing the technology. Both there is some give and take here, one is not definitively better than the other. That said I agree with you that this is a bad solution don't simulate a column store with a row store it won't perform as well as a good column store since it is not optimized for tuple reconstruction.