But the truth is the days of DB being king are almost gone.
These days you just don't hear about DBAs at all any more. You used to see constant jokes about DBAs being a pain in the ass and stopping programmers doing X or Y. ORMs going to win because there aren't enough of you left. Stored procedures, triggers, etc. are going to be viewed as ancient technology back from the days of yore when people didn't understand how to code properly.
At the risk of responding to a troll, being a DBA is far more than "Stored procedures, triggers, etc.". The relational database is still around (I notice you talk about databases as if all databases are relational, which is false), and will remain for decades to come because relational theory is sound and has proven to work for most use-cases.
The database is where you store your data. If you have data of which its integrity is critical to your organization, a properly designed and maintained database is going to save a lot of hastle.
I believe that databases will remain important, and maintaining data will always involve restrictions on how you can use it. Restricting data is not a relational database problem - it's more often than not a business constraint. Often times you don't want programmers doing stupid things with your data :-)
My experience seems to be different from yours. I am a working DBA and I have friends that are working DBAs and we generally do not have a hard time finding work.
I incidentally have stopped programmers from doing X or Y, but it was because the right answer was Z.
As for ORM's winning, I don't think its a war, For some things I use and recommend ORMs, but for others I recommend using pure SQL.
> Stored procedures, triggers, etc. are going to be viewed as ancient technology back from the days of yore when people didn't understand how to code properly.
You may be right about perception, but nearly every system I've worked has contained a big ugly mess somewhere because the author didn't know how to use a SQL DB properly.
I would be interested to know what you mean by "real data store", and what you believe Facebook does badly at in terms of handling data and caching and how it could be improved.
(I am an engineer/developer/whatever at Facebook, and I'm always interested in hearing the perception of the company's technology from the community.)
1. I've always been under the impression that for what Facebook does, a traditional RDBMS simply cannot handle the scale (like, not even close). Is this correct?
2. I'm also under the impression that due to the architecture Facebook runs on, from time to time some lesser-important data (ie: a status update or comment) can be lost (temporarily or permanently) and this is not considered unacceptable. (It seems perfectly reasonable to me for this particular use case.)
Perhaps it is best for the database team to talk about that themselves - wouldn't want to put words in their mouths. They gave a Tech Talk in December last year, which you can see at http://livestre.am/1aeeW
These days you just don't hear about DBAs at all any more. You used to see constant jokes about DBAs being a pain in the ass and stopping programmers doing X or Y. ORMs going to win because there aren't enough of you left. Stored procedures, triggers, etc. are going to be viewed as ancient technology back from the days of yore when people didn't understand how to code properly.