Most developers get started building applications without giving a lot of thought to their database. Either they get told that the company does everything with Database X, or they Google around and end up using MySQL or MS Access. Neither of these is the wrong choice, but it's often not the best choice. I was one of those guys, first with Access and then MySQL. As I've moved through my career, I've used a lot of database systems, both relational and non-relational ("NoSQL"), and my go-to choice has become PostgreSQL.
I'm not going to spend much time on the "SQL vs NoSQL" debate. It's sort of a straw man argument, because they're solving a variety of fundamentally different problems. It's also much better in discussion format, for that same reason: so much variety.
Like everything else in technology, there is no one-size-fits-all solution, but I want to show why I think it's a great first choice for most things, and the reasons why a lot of other options fall short. Your choice of database can shape a lot of how you build your application, how well it performs, and how it can grow over time. It can be a productivity boon, or force you to constantly working around it's limitations. As application developers, we should be spending our time solving business problems, not on low-level technology plumbing.
This session is intended for people who have built a few database-backed applications, and are curious about what options are out there and how to go about choosing between them.
Most developers get started building applications without giving a lot of thought to their database. Either they get told that the company does everything with Database X, or they Google around and end up using MySQL or MS Access. Neither of these is the wrong choice, but it's often not the best choice. I was one of those guys, first with Access and then MySQL. As I've moved through my career, I've used a lot of database systems, both relational and non-relational ("NoSQL"), and my go-to choice has become PostgreSQL.
I'm not going to spend much time on the "SQL vs NoSQL" debate. It's sort of a straw man argument, because they're solving a variety of fundamentally different problems. It's also much better in discussion format, for that same reason: so much variety.
Like everything else in technology, there is no one-size-fits-all solution, but I want to show why I think it's a great first choice for most things, and the reasons why a lot of other options fall short. Your choice of database can shape a lot of how you build your application, how well it performs, and how it can grow over time. It can be a productivity boon, or force you to constantly working around it's limitations. As application developers, we should be spending our time solving business problems, not on low-level technology plumbing.
This session is intended for people who have built a few database-backed applications, and are curious about what options are out there and how to go about choosing between them.