4 ms·

It's one of the 'bug bears' I find with new technologies where they try and use it for something it wasn't really designed for. The most recent being the idea o

by awjr 14y ago

It's one of the 'bug bears' I find with new technologies where they try and use it for something it wasn't really designed for. The most recent being the idea of doing e-commerce with a no-sql db (mostly MongoDB). You are just using the wrong type of DB for this. It's nice to find a NoSQL solution that addresses this issue.

stephenpiment 14y ago
Transactions are great not only for e-commerce but for a broad range of applications. Take a look at our Transaction Manifesto: http://www.foundationdb.com/white-papers/the-transaction-manifesto/ http://www.foundationdb.com/white-papers/the-transaction-man...
VexXtreme 14y ago
A big part of the problem are developers who think that every new technology is a golden hammer and who try to shoehorn those same technologies into roles they are not well suited for. A pretty obvious example is people using Redis and Mongo for applications that would really benefit the most from relational databases. If you have a highly relational model that would benefit from things like referential integrity and normalization then use a relational database. If you need a massive highly scalable KVP database, use NoSQL. I don't see why people try to use a single approach as a solution to every problem. I thought this video about NoSQL fanboys was really hilarious: http://highscalability.com/blog/2010/9/5/hilarious-video-relational-database-vs-nosql-fanbois.html http://highscalability.com/blog/2010/9/5/hilarious-video-rel...
- jt2190 14y ago
  > If you have a highly relational model that would benefit > from things like referential integrity and normalization > then use a relational database. If you need a massive > highly scalable KVP database, use NoSQL. I don't see why > people try to use a single approach as a solution > to every problem. Part of the problem is that people present this as a choice between relational and non-relational models, when the choice is actually about how the database will scale when the data set gets very large.
  - obviouslygreen 14y ago
    You're turning one false dichotomy into... I don't know the word for it, but while how it scales can be part of choosing a database system, it definitely is not the main difference between the relational and noSQL models. How your data storage will scale is an important but tangential topic that should be addressed as complementary to deciding which class of storage will help you most effectively and efficiently model your data.
    - jt2190 14y ago
      > ...[database scaling is] definitely is not the main > difference between the relational and noSQL models. The post I was responding to strongly implies that one simply has to decide whether they want to use a relational model or not. I contend that framing the question this way is contributing to the misunderstandings of what the advantages and disadvantages of the popular noSQL databases are, which become very apparent when one thinks of what happens when the data set gets very large. Relational databases don't work nearly as well when you have to split the schema across multiple databases, and you can no longer use the database provided transactions or joins.
  - papsosouid 14y ago
    Except that virtually everyone can easily have everything in a single, fully normalized relational database on a single server. People have convinced themselves that relational databases can't scale, based on nothing at all.
- gav 14y ago
  I think it's more of an issue that developers consider their options to be SQL or NoSQL when the option of using both often is a great choice. You can pick the best technology to solve individual aspects of the system. For example, the current system I'm working on uses Oracle and Mongo, the previous used SQL Server and Redis. The main theme is to use a relational database for the structured data that we need transactional support for, e.g. orders, then use a NoSQL data for unstructured data and caching.
giulianob 14y ago
The issue I see the most is that NoSQL has become synonymous with distributed databases which is really where making ACID promises becomes a challenge. If you had a single node document DB, it probably wouldn't be very challenging to make it ACID. SQL or not, as soon as you want to make it automatically shard and distributed, then you will suffer large performance impacts with transactions. Are there any single node document DBs which provide ACID guarantees out there? I know Redis can do it with multi/exec but Redis isn't really document oriented though it's an awesome piece of software.
- misframer 14y ago
  Redis doesn't support transaction rollbacks, so they're not really "atomic."
  - giulianob 14y ago
    They do have DISCARD so if you call MULTI and want to bail out you can say DISCARD. What they don't have is automatically rolling back if there's a failure while executing commands. However, failures in Redis are mainly going to happen if you issue a bad command (something you should catch during development). IIRC, if there's a power failure or something happens before the transaction finishes, Redis is able to discard the transaction during startup.
- lucian1900 14y ago
  True. For example, CouchDB is ACID, as long as you consider versioned data equivalent to transactions.

by awjr 14y ago

stephenpiment 14y ago

Transactions are great not only for e-commerce but for a broad range of applications. Take a look at our Transaction Manifesto: http://www.foundationdb.com/white-papers/the-transaction-manifesto/ http://www.foundationdb.com/white-papers/the-transaction-man...

VexXtreme 14y ago

A big part of the problem are developers who think that every new technology is a golden hammer and who try to shoehorn those same technologies into roles they are not well suited for. A pretty obvious example is people using Redis and Mongo for applications that would really benefit the most from relational databases. If you have a highly relational model that would benefit from things like referential integrity and normalization then use a relational database. If you need a massive highly scalable KVP database, use NoSQL. I don't see why people try to use a single approach as a solution to every problem. I thought this video about NoSQL fanboys was really hilarious: http://highscalability.com/blog/2010/9/5/hilarious-video-relational-database-vs-nosql-fanbois.html http://highscalability.com/blog/2010/9/5/hilarious-video-rel...

jt2190 14y ago
> If you have a highly relational model that would benefit > from things like referential integrity and normalization > then use a relational database. If you need a massive > highly scalable KVP database, use NoSQL. I don't see why > people try to use a single approach as a solution > to every problem. Part of the problem is that people present this as a choice between relational and non-relational models, when the choice is actually about how the database will scale when the data set gets very large.
- obviouslygreen 14y ago
  You're turning one false dichotomy into... I don't know the word for it, but while how it scales can be part of choosing a database system, it definitely is not the main difference between the relational and noSQL models. How your data storage will scale is an important but tangential topic that should be addressed as complementary to deciding which class of storage will help you most effectively and efficiently model your data.
  - jt2190 14y ago
    > ...[database scaling is] definitely is not the main > difference between the relational and noSQL models. The post I was responding to strongly implies that one simply has to decide whether they want to use a relational model or not. I contend that framing the question this way is contributing to the misunderstandings of what the advantages and disadvantages of the popular noSQL databases are, which become very apparent when one thinks of what happens when the data set gets very large. Relational databases don't work nearly as well when you have to split the schema across multiple databases, and you can no longer use the database provided transactions or joins.
- papsosouid 14y ago
  Except that virtually everyone can easily have everything in a single, fully normalized relational database on a single server. People have convinced themselves that relational databases can't scale, based on nothing at all.
gav 14y ago
I think it's more of an issue that developers consider their options to be SQL or NoSQL when the option of using both often is a great choice. You can pick the best technology to solve individual aspects of the system. For example, the current system I'm working on uses Oracle and Mongo, the previous used SQL Server and Redis. The main theme is to use a relational database for the structured data that we need transactional support for, e.g. orders, then use a NoSQL data for unstructured data and caching.

giulianob 14y ago

The issue I see the most is that NoSQL has become synonymous with distributed databases which is really where making ACID promises becomes a challenge. If you had a single node document DB, it probably wouldn't be very challenging to make it ACID. SQL or not, as soon as you want to make it automatically shard and distributed, then you will suffer large performance impacts with transactions. Are there any single node document DBs which provide ACID guarantees out there? I know Redis can do it with multi/exec but Redis isn't really document oriented though it's an awesome piece of software.

misframer 14y ago
Redis doesn't support transaction rollbacks, so they're not really "atomic."
- giulianob 14y ago
  They do have DISCARD so if you call MULTI and want to bail out you can say DISCARD. What they don't have is automatically rolling back if there's a failure while executing commands. However, failures in Redis are mainly going to happen if you issue a bad command (something you should catch during development). IIRC, if there's a power failure or something happens before the transaction finishes, Redis is able to discard the transaction during startup.
lucian1900 14y ago
True. For example, CouchDB is ACID, as long as you consider versioned data equivalent to transactions.