It is arguable that the need for a DBA does disappear with the change in the systems. The base approach of the relational model is that there is a professional DBA who makes sure that the mission-critical data is available in a format that multiple applications and multiple department can use directly (the type of data is know but the ordering isn't set). Thus DBA is "hat" that most programmers can't "wear", especially since a large portion of programmers don't understand the relational model.
On the other hand, Nosql and object-databases allow a programmer to just stuff data into the a data-store without worrying about a cohesive datamodel. If we consider this as mission-critical data that multiple departments of a large organization would want to see in multiple forms, then we can find many ways that the approach of "just save this array of values" produces serious problems.
But there are many applications where these problems don't appear. Diggs seems like it could get away with doing nosql. A health-record site seems like it could not do nosql since it ultimately is going to want ACID-and-beyond in its data model.
Good comment, but I wouldn't quite say that using a non-relational database frees you from having to think about a cohesive data model. It might be more accurate to say that for some data models non-relational stores are a more natural fit which frees you having to think about how to force your model into the wrong container.
It's hard to find the right adjective for what's distinct about the relational model.
The relational model is a fantastic model of data independent of application. It can even be a great model for an application using the same data in different ways.
But this approach clearly has a cost. In ways, there's the question - is this an application with a company built around it or a company with a application built around it? Digg and Google are applications with companies built around them. Here the RDMS model doesn't make sense.
On the other hand, Nosql and object-databases allow a programmer to just stuff data into the a data-store without worrying about a cohesive datamodel. If we consider this as mission-critical data that multiple departments of a large organization would want to see in multiple forms, then we can find many ways that the approach of "just save this array of values" produces serious problems.
But there are many applications where these problems don't appear. Diggs seems like it could get away with doing nosql. A health-record site seems like it could not do nosql since it ultimately is going to want ACID-and-beyond in its data model.