4 ms·

SQL databases are very powerful and capable tools, but they also hide some complexities behind a declarative language. That makes easy to get into a bad place,

SQL databases are very powerful and capable tools, but they also hide some complexities behind a declarative language. That makes easy to get into a bad place, performance-wise, if the DB mutates quickly. You don't need millions of accesses to the DB to have unbearable slow queries if schemas are not carefully designed, which is difficult in early stages of development. I usually consider the "I had to migrate from DB X to DB Y" a success story. You discovered what was required and later in the process, improved your system. Painful, but probably unavoidable. Databases are not easy to handle and operate. Is easy to underestimate them. We used to have people just devoted to them (can you remember DBAs?). It is worth to spend time learning them and knowing their goods and bads. And sometimes making mistakes in unavoidable...

mamcx 10y ago
> Is easy to underestimate them. VERY true. > Databases are not easy to handle and operate. I think instead are the easiest of all available options. With a SQL database you have at least available some kind of GUI to build the schema and do query and stuff. And have see not-very-technical people building databases just fine. Try the same with Cassandra "Hey, secretary, please build a Cassandra database for the contacts, please!". Yep, not easy. ------ You only get into trouble when: - You schema is super-bad. But is the same with NoSql - You don't create that 1-2 indexes per-table (and some Guis/RDBMS auto-create them for the ID and surrogate keys, that is almost enough) - You have a very large database. Or, you have a bad schema and is leaking as a very large resultset (or SQL query) that is overcomplicated everything. - You forgot you have a powerfull RDBMS and insist to use it below the capabilities of Acces, yet, have proud in learning C++. Because C++ is powerful. But why dedicate a few hours learning the basic of Sql?? Most people have very easy problems to solve, and in contrast with the nightmare that is debug a NoSql store that badly try to re-create what a RDBMS have and you know some data is lost but good look finding it... --- Where the situation get out of proportion is with the startup-mindset of "scalability". A problem that few have, even startups.
- user5994461 10y ago
  > You only get into trouble when: You have more than 10 TB of data.
  - cpburns2009 10y ago
    That's likely true, but honestly how many people really have TB of data?
    - user5994461 10y ago
      About anyone who doesn't run a toy project. Data can goes really really quick when you have some users.
bigiain 10y ago
I have several times done the "I had to migrate from DB X to DB X but designed and indexed properly" re-write and success story... (I've also got many many more stories of my team saying "We'll need to use $NoSQL-de-jour here for performance and scalability!" where I've talked everyone into "Let's just go with MySQL/RDS/Postgres as a prototype, and see where the speed or scaling problems arise before we rewrite things." and never coming close to bumping into scale or performance problems...)
swasheck 10y ago
I'm a dba so yes I can remember DBAs. I don't understand the condescension from you comment. As a DBA, I have never understood the argument of a mutating database as a solid justification. It just sounds lazy/unprepared, at best. Sure, there may be a valid complaint for the unicorns out there, but they represent such a small percentage of situations that I hardly see how ther experiences necessarily translate to everyone else's situation. "It's hard" or "it's difficult" sound like blame-shifting to cover for a lack of actually understanding requirements. I don't mean to single you out in this comment. The reality is that your comment just really reiterates so many of the same arguments that are regularly trotted out as justification. NoSQL already came and went. It was called ISAM. It has a use case, but it's not the silver bullet everyone wants it to be. Oh yeah, as a DBA, I've loved hearing how NoSQL was going to do away with my job and that I am a 39 year old dinosaur who'd better catch up and get on board with DevOps. Guess who runs data CI where I am? Guess who manages our Mongo and Redis servers. Yep. The ancient DBAs.
- cowardlydragon 10y ago
  How about some vitriol? You know what the #1 feature of nosql is? NoDBA. I can hear you screaming you'll still need a DBA. You don't get it. You won't need an Enterprise DBA. Enterprise DBAs are almost invariably horrible blockades to data storage in any enterprise. All they do is lock away the database from developers, cram Oracle down their throats, do things as slowly as possible behind ticket walls. You lock the data away pining for your halcyon mainframe days of white coats and clean rooms, and force your slow ponderous overtenanted infrastructure. Your profession, since you have proudly identified as a DBA, you are an Enterprise DBA, is a disgrace.
  - grzm 10y ago
    How about some vitriol? How about not? Bad actors can be found in all domains, DBAs included. Painting all with such sweeping brushes does little to suggest people should take your comment seriously or advance the conversation constructively. There are also plenty of DBAs who know the strengths and weaknesses of many different data models, engines, and platforms, and work with developers to make decisions to ensure efficient data storage and IO for a successful application. Edit to add: Your profession, since you have proudly identified as a DBA, you are an Enterprise DBA, is a disgrace. If you identify yourself as a DBA you must be an enterprise DBA? There are plenty of DBAs who are happy to dig into backend or frontend code as well, but have a lot of experience working with database systems. Many frontend and backend devs have experience working with databases, and similarly describe themselves to focus on their strengths. Are they enterprise frontend and backend devs?

mamcx 10y ago

> Is easy to underestimate them. VERY true. > Databases are not easy to handle and operate. I think instead are the easiest of all available options. With a SQL database you have at least available some kind of GUI to build the schema and do query and stuff. And have see not-very-technical people building databases just fine. Try the same with Cassandra "Hey, secretary, please build a Cassandra database for the contacts, please!". Yep, not easy. ------ You only get into trouble when: - You schema is super-bad. But is the same with NoSql - You don't create that 1-2 indexes per-table (and some Guis/RDBMS auto-create them for the ID and surrogate keys, that is almost enough) - You have a very large database. Or, you have a bad schema and is leaking as a very large resultset (or SQL query) that is overcomplicated everything. - You forgot you have a powerfull RDBMS and insist to use it below the capabilities of Acces, yet, have proud in learning C++. Because C++ is powerful. But why dedicate a few hours learning the basic of Sql?? Most people have very easy problems to solve, and in contrast with the nightmare that is debug a NoSql store that badly try to re-create what a RDBMS have and you know some data is lost but good look finding it... --- Where the situation get out of proportion is with the startup-mindset of "scalability". A problem that few have, even startups.

user5994461 10y ago
> You only get into trouble when: You have more than 10 TB of data.
- cpburns2009 10y ago
  That's likely true, but honestly how many people really have TB of data?
  - user5994461 10y ago
    About anyone who doesn't run a toy project. Data can goes really really quick when you have some users.

bigiain 10y ago

I have several times done the "I had to migrate from DB X to DB X but designed and indexed properly" re-write and success story... (I've also got many many more stories of my team saying "We'll need to use $NoSQL-de-jour here for performance and scalability!" where I've talked everyone into "Let's just go with MySQL/RDS/Postgres as a prototype, and see where the speed or scaling problems arise before we rewrite things." and never coming close to bumping into scale or performance problems...)

swasheck 10y ago

I'm a dba so yes I can remember DBAs. I don't understand the condescension from you comment. As a DBA, I have never understood the argument of a mutating database as a solid justification. It just sounds lazy/unprepared, at best. Sure, there may be a valid complaint for the unicorns out there, but they represent such a small percentage of situations that I hardly see how ther experiences necessarily translate to everyone else's situation. "It's hard" or "it's difficult" sound like blame-shifting to cover for a lack of actually understanding requirements. I don't mean to single you out in this comment. The reality is that your comment just really reiterates so many of the same arguments that are regularly trotted out as justification. NoSQL already came and went. It was called ISAM. It has a use case, but it's not the silver bullet everyone wants it to be. Oh yeah, as a DBA, I've loved hearing how NoSQL was going to do away with my job and that I am a 39 year old dinosaur who'd better catch up and get on board with DevOps. Guess who runs data CI where I am? Guess who manages our Mongo and Redis servers. Yep. The ancient DBAs.

cowardlydragon 10y ago
How about some vitriol? You know what the #1 feature of nosql is? NoDBA. I can hear you screaming you'll still need a DBA. You don't get it. You won't need an Enterprise DBA. Enterprise DBAs are almost invariably horrible blockades to data storage in any enterprise. All they do is lock away the database from developers, cram Oracle down their throats, do things as slowly as possible behind ticket walls. You lock the data away pining for your halcyon mainframe days of white coats and clean rooms, and force your slow ponderous overtenanted infrastructure. Your profession, since you have proudly identified as a DBA, you are an Enterprise DBA, is a disgrace.
- grzm 10y ago
  How about some vitriol? How about not? Bad actors can be found in all domains, DBAs included. Painting all with such sweeping brushes does little to suggest people should take your comment seriously or advance the conversation constructively. There are also plenty of DBAs who know the strengths and weaknesses of many different data models, engines, and platforms, and work with developers to make decisions to ensure efficient data storage and IO for a successful application. Edit to add: Your profession, since you have proudly identified as a DBA, you are an Enterprise DBA, is a disgrace. If you identify yourself as a DBA you must be an enterprise DBA? There are plenty of DBAs who are happy to dig into backend or frontend code as well, but have a lot of experience working with database systems. Many frontend and backend devs have experience working with databases, and similarly describe themselves to focus on their strengths. Are they enterprise frontend and backend devs?