[Uncle Bob Martin] NO DB
http://blog.8thlight.com/uncle-bob/2012/05/15/NODB.html
注：原文在后面。
NO DB
在1920年的美国，一项宪法修正法案，禁止了酒精的制造、销售和相关饮料的进口。13年后这项法案才被废除，在此期间，啤酒工业消亡了。
1933年禁令解除时，一些粮食巨头公司开始酿造啤酒，他们完全垄断了市场。在将近50年的时间里，美国开始喝这个泡沫沸腾的东西，并且称为“啤酒”。
作为60年代十几岁的年轻人，我无法理解它的吸引力。为什么要喝啤酒？那只是浅黄色的，很难喝的液体，提取自食物的下脚料，而且毫无品质可言。
在1984年，我去了英国，让我大开眼界。至少我理解了，因为我第一次尝了啤酒，觉得味道还不错。
从那时起，啤酒在美国大受欢迎。新的啤酒公司在全国各地兴起，基本上他们生产的啤酒都很好喝。我们的啤酒还没有比英国的苦啤好喝，但是我们正在努力追赶。
在80年代，一些数据库巨头公司垄断了市场。他们通过传播恐惧来达到目的，不能确定，但基本上经理和市场都被征服。关键字“关系数据库”基本上和“好的数据库”是等价了，其他的数据存储机制都是被抛弃的。
在担任首席开发工程师时，我们的产品用来测量通信线路的品质，我们的数据模型相对很简单，直接将数据保存在文件中，这个架构工作得很好。
但是，我们市场部的同事坚持对我们说，应该使用关系数据库，他说客户需要关系数据库。我觉得那是个很奇怪的需求，因为那个时候我们还没有卖出去一个产品给客户。但是市场部的同事很坚定，所以我们不得不废掉了文件，使用关系数据库。
作为首席工程师，确保软件质量是首要责任。在我看来，关系数据库是一个庞大的、笨重的、速度很慢的、而且昂贵的痛苦。因为我们并没有复杂的查询，我们也没有大量的报表，我们也没有一个消耗大量内存的进程做复杂的循环工作（因为那个时候还是80年代）。所以我坚持我的观点，使用任何可用的工具来支持我的观点，因为我觉得这是一个错误的技术方案。
我的做法并不英明，因为几个月之后，一个硬件工程师，没有写过几行代码，调到了我的团队，来和我一起负责整个团队。
没错！一个硬件工程师，没有软件经验，调过来“帮助”我来领导软件团队。你觉得他第一个问题是什么？“为什么我们要使用关系数据库？！”
我在一个月之后就离职了，然后开始了我的咨询顾问生涯。在我的职业生涯中，那是我做得最对的决定。那个公司在我离开之后也没有活多久，我觉得他们可能没有赚什么钱。
我看到关系数据库市场在90年代增长很快，其他数据存储技术，譬如对象数据库、B-tree数据库逐渐消亡了。和20年代的啤酒一样，90年代末，只有几家数据库巨头存活了下来。
哪些巨头翻云覆雨，无所不能，他们制定规则。在.com泡沫高峰时，他们中的一个甚至通过电视广告宣称，internet就是由他们的产品驱动的。这让我想起了70年代啤酒的口号：啤酒就是生活的意义。真不要脸！
在这之后，我看到一个个团队都把数据库作为系统的中心，这是极其傻逼的做法。他们已经被无休止的广告洗脑，确信数据模型是架构中最重要的部分，而数据库就是设计的灵魂和心脏！
我发现一个新的职位开始被热捧——DBA！能负责数据的程序员太少了，所以市场开始大肆宣传，数据太脆弱了，太容易出问题，我们需要特殊的人来管理数据。DBA就是数据库公司训练出来的，他们能够熟练使用和管理数据库，他们也帮忙宣传数据库巨头们的愿景：数据库就是系统的核心！企业的核心！世界的核心！宇宙的核心！
我看到SQL水银落地无孔不入，我甚至惊讶UI也开始用SQL。我强烈反对把所有的逻辑规则都写到存储过程。看到邮件合并程序都用SQL写，我感到很震惊。
每当我看到数据表渗透到系统的源码中，我就给予警告，但我明白我只是螳臂当车，以卵击石。
在21世纪最初的10年，大家开始关注到SQL的短处，NOSQL开始崭露头角。我认为那是一个奇迹，荒野上的明灯。大家终于意识到这个世界上可能需要一些新的系统，没有庞大、臃肿、慢的像蜗牛、昂贵，而且还巨吃内存的关系数据库！
我很开心看到BigTable、Mongo、CouchDB，还有其他轻量级的数据存储系统开始出现和增长，就像80年代出现的小啤酒厂一样，啤酒复兴了，而且味道还不错！
但是我又看到，人们开始围绕这些优美、简单、非关系数据库做设计了。那些披着光环的新的框架，里面封装了这些新数据库，开始成为设计的中心！那些关系数据库观念的余毒，有开始萦绕在设计者脑中：他们仍然在犯同样致命的错误！
“醒醒吧！不能这么干了！“我咆哮道，”你没有搞清楚，完全没有搞清楚“。但是思维定势太强了，框架大潮粉碎了我们的软件产业。这些框架底层包装了数据库，牢牢占据着我们设计的中心；宣称驾驭了数据库，甚至说能将关系数据库转换成非关系数据库！框架对世界宣称：依赖我吧，我能让你自由！
这个文章的标题是”No DB“，可能在我咆哮了这么久之后，你可能开始想为什么我要以这个作为标题了。
软件的核心不能是数据库，也不是任何框架。软件的核心应该是软件的用例（The center of your application are the use cases of your application）。
当我听说一个工程师描述他的系统为“Tomcat系统，使用了Sprint和Hibernate，Oracle数据库”时，我几乎要疯掉了。这就是将框架和数据库放在了软件的核心。
你觉得系统的架构应该是什么样子？你觉得你会把用例放在设计的核心吗？或者你觉得应该按照框架来编码？你是否会怀疑逻辑对象和数据库的列能一一对应？框架和数据库表具有破坏性？
软件就应该这样，用例应该是最重要，而且在架构中应该是最明了的。用例才是软件的核心。数据库和框架只是细节！你不能本末倒置。只有当你发掘了系统的所有用例，以及逻辑的规则，才应该考虑细节（数据库和框架）。
应该在什么时候才去考虑数据模型？当你知道有什么数据实体，并且他们如何关联，以及如何使用时。什么时候你才能知道这些？只有当你发掘了系统的用例，逻辑的规则，并验证正确时。那个时候，你才应该去定义查询，数据关系，数据元素，然后才是选择数据库来实现数据模型。
对于NoSQL，这个规则适用吗？当然适用。你必须全神贯注在分析系统用例，和验证用例上面，在此之前就不应该考虑数据库，不管是什么样的数据库。
如果过早的引入数据库，它会扭曲你的设计。他会逐渐变成设计的中心，你就必须做很多复杂的工作来保证数据库为系统中心。你必须不能那么早就引入数据库设计！
我们正在进入一个有趣的时代，不同的数据存储机制都大行其道，我们也能自由的使用各种新的方法。但是当我们在鼓捣CouchDBs、Mongos和BigTabls时，记住：数据库只是细节，不应该那么早引入( The database is just a detail that you don’t need to figure out right away.).
NO DB
In the United States, in 1920, the manufacture, sale, and importation of alcoholic beverages was prohibited by a constitutional amendment. That amendment was repealed thirteen years later. During that period of prohibition, the beer industry died.
In 1933, when prohibition was lifted, a few giant grain companies started brewing beer. They completely cornered the market. And for nearly 50 years, we in the United State drank this fizzy bodily effluent and called it “beer”. The only way to tolerate the flavor was to drink it very cold.
As a teenager in the ‘60s, I never understood the attraction. Why beer? It was a pale, yellow, distasteful fluid derived from the urine of sick boars, and had no redeeming qualities that I could see.
In 1984, I went to England; and the scales dropped from my eyes. At last I understood. I had tasted beer for the first time; and I found it to be good.
Since those days the beer situation in the United States has improved dramatically. New beer companies are springing up all over the country; and in many cases the beer they make is actually quite good. We don’t have anything quite so nice as a good english bitter; but we’re getting close.
In the ‘80s a few giant database companies cornered the market. They did this by promulgating fear, uncertainty, and doubt amongst managers and marketing people. The word “relational” became synonymous with “good”; and any other kind of data storage mechanism was prohibited.
I was the lead developer in a startup in those days. Our product measured the quality of T1 communications lines. Our data model was relatively simple, and we kept the data in flat files. It worked fine.
But our marketing guy kept on telling us that we had to have a relational database. He said that customers would demand it. I found that to be a strange claim since we hadn’t sold even one system at that time, and no customer had ever mentioned our data storage technology. But the marketing guy was adamant. We just had to have a relational database. Flat files were prohibited.
As the lead developer, responsible for the quality of the software, my view of a relational database was that it would be a big, stogy, slow, expensive pain in the rear. We didn’t have complex queries. We didn’t need massive reporting capabilities. We certainly didn’t need a process with a multi-megabyte footprint sitting in memory and burning cycles. (Remember, this was the ‘80s). So I fought against this idea with everything I had; because it was the wrong technical solution.
This was not a politically astute move for me. Over a period of several months, a hardware engineer who managed to write a few lines of code, was moved into the software group. He was gradually given more and more responsibility, and was eventually named my co-manager. He and I would “share” the responsibility for leading the software team.
Uh huh. Sure. Right. A hardware guy with no real software experience was going to “help” me lead the team. And what do you think his first issue was? Why it was to get a relational database into our system!
I left a month later and started my consulting career. It was best career move I have ever made. The company I left no longer exists. I don’t think they ever made a dime.
I watched the relational database market grow during the ‘90s. I watched as all other data storage technologies, like the object databases, and the B-tree databases dwindled and died; like the beer companies in the 20s. By the end of the ‘90s, only the giants were left.
Those giants were marketing up a storm. They were gods. They were rulers. During the dot com bubble, one of them actually had the audacity to buy television ads that claimed that their product was “the power that drove the internet”. That reminded me of a beer slogan from the ‘70s “Ya gotta grab for all the gusto in life ya can.” Oh brother.
During this time I watched in horror as team after team put the database at the center of their system. They had been convinced by the endless marketing hype that the data model was the most important aspect of the architecture, and that the database was the heart and soul of the design.
I witnessed the rise of a new job function. The DBA! Mere programmers could not be entrusted with the data — so the marketing hype told us. The data is too precious, too fragile, too easily corrupted by those undisciplined louts. We need special people to manage the data. People trained by the database companies. People who would safeguard and promulgate the giant database companies’ marketing message: that the database belongs in the center. The center of the system, the enterprise, the world, the very universe. MUAHAHAHAHAHAHA!
I watched as SQL slipped through every crack and crevice in the system. I ran screaming from systems in which SQL had leaked into the UI. I railed endlessly against the practice of moving all business rules into stored procedures. I quailed and quaked and ranted and raved as I read through entire mail-merge programs written in SQL.
I hammered and hammered as I saw tables and rows permeating the source code of system after system. I hammered out danger. I hammered out a warning. I hammered out that the schema had become “The Blob”, consuming everything in sight. But I knew all my hammering was just slinging pebbles at a behemoth.
And then, in the first decade of the 21st century, the prohibition was lifted, and the NOSQL movement was born. I considered it a kind of miracle, a light shining forth in the wilderness. Finally, someone realized that there might just be some systems in the world that did not require a big, fat, horky, slow, expensive, bodily effluent, memory hog of a relational database!
I watched in glee as I saw BigTable, Mongo, CouchDB, and all the other cute little data storage systems begin to spring up; like little micro-breweries in the ‘80s. The beer was back! And it was starting to taste good.
But then I noticed something. Some of the systems using these nice, simple, tasty, non-relational databases were being designed around those databases. The database, wrapped in shiny new frameworks, was still sitting at the center of the design! That poisonous old relational marketing hype was still echoing through the minds of the designers. They were still making the fatal mistake.
“Stop!” I yelled. “ Stop! You don’t understand. You don’t understand.” But the momentum was too great. An enormous wave of frameworks rose up and smashed down on our industry, washing over the land. Those frameworks wrapped up the databases and fought to grab and hold the center of our applications. They claimed to master and tame the databases. They even claimed to be able to turn a relational database into a NoSQL database. And the frameworks cried out with a great voice heard all over the land: “Depend on me, and I’ll set you free!”
The name of this article is “No DB”. Perhaps after that rant you are getting an inkling of why I named it that.
The center of your application is not the database. Nor is it one or more of the frameworks you may be using. The center of your application are the use cases of your application.
It makes me crazy when I hear a software developer describe his system as a “Tomcat system using Spring and Hibernate using Oracle”. The very wording puts the frameworks and the database at the center.
What do you think the architecture of that system would look like? Do you think you’d find the use cases at the center of the design? Or would you find the source code arranged to fit nicely into the pattern of the frameworks? Would you find business objects that looked suspiciously like database rows? Would the schema and the frameworks pollute everything?
Here’s what an application should look like. The use cases should be the highest level and most visible architectural entities. The use cases are at the center. Always! Databases and frameworks are details! You don’t have to decide upon them up front. You can push them off until later, once you’ve got all the use cases and business rules figured out, written, and tested.
What is the best time to determine your data model? When you know what the data entities are, how they are related, and how they are used. When do you know that? When you’ve gotten all the use cases and business rules written and tested. By that time you will have identified all the queries, all the relationships, all the data elements, and you’ll be able to construct a data model that fits nicely into a database.
Does this change if you are using a NoSql database? Of course not! You still focus on getting the use cases working and tested before you even think about the database; no matter what kind of database it ends up being.
If you get the database involved early, then it will warp your design. It’ll fight to gain control of the center, and once there it will hold onto the center like a scruffy terrier. You have to work hard to keep the database out of the center of your systems. You have to continuously say “No” to the temptation to get the database working early.
We are heading into an interesting time. A time when the prohibition against different data storage mechanisms has been lifted, and we are free to experiment with many novel new approaches. But as we play with our CouchDBs and our Mongos and BigTables, remember this: The database is just a detail that you don’t need to figure out right away.