Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I had a discussion with a friend about row vs column oriented RDBMS.

From my understanding, these things are closely linked with the fact that there's a concrete drive head reading and writing the data. This head moves and reading/writing data is faster if the head moves are limited.

Still from my understanding, SSD drives drops those mechanical artifacts and accessing the data is now taking the same amount time regardless of where they are physically stored on the chip / device (don't know the right term).

Considering these two points, will the SSD drives (when they'll have reached their full potential) make the distinction between row oriented and column oriented either obsolete or pointless?

share|improve this question

closed as not constructive by Jim G., Glenn Nelson, gnat, MichaelT, Frank Shearar Mar 11 '13 at 8:24

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

Modern DBMS's are both row and column oriented. Can you give some examples of what you consider to be row-oriented databases and column-oriented databases? – Robert Harvey Mar 10 '13 at 22:19
Interesting comment, I didn't knew that most of them tried to use both aspects. This doesn't change my question, shall it ? – AsTeR Mar 10 '13 at 22:31

The only time I've ever seen rotational latency mentioned in the same breath as a DBMS is with SQLite. SQLite recommends that, if you have a lot of consecutive inserts, you should wrap them into a transaction, because if you don't, the database engine does a read after write to verify each record. That takes about 1/60th of a second for each insert on a 7200 RPM drive, which is a lifetime in computer terms.

In any case, there's always a workaround in databases for this rotational latency; usually it's some sort of caching. The only thing that changes when you switch to a solid state drive is that this caching becomes less important. You still need the things like queries, joins and sets that databases provide; you'll just get them with a performance boost.

share|improve this answer
And not only does the read after write sound slow, it sometimes takes the system a lot of effort to assure that whatever it reads, is read from actual persistent storage, and not some buffer along the way. Firmware sometimes lies about having written data, and sometimes it writes correctly, but in the wrong spot. – Henk Langeveld Mar 10 '13 at 22:32

Not the answer you're looking for? Browse other questions tagged or ask your own question.