《 HELLAND, PAT.The Singular Success of SQL.Communications of the ACM，2016》
SQL has been singularly successful in its impact on the database industry. Nothing has come remotely close to its ubiquity. Its success comes from its high-level use of relational algebra allowing set-oriented operations on data shaped as rows, columns, cells, and tables.
SQLrsquo;s impact can be seen in two broad areas. First, the programmer can accomplish a lot very easily with setoriented operations. Second, the high-level expression of the programmerrsquo;s intent has empowered huge performance gains.
This column discusses how these features are dependent on SQL creating a notion of stillness through transactions and a notion of a tight group of tables with schema fixed at the moment of the transaction. These characteristics are what make SQL different from the increasingly pervasive distributed systems.
SQL has a brilliant past and a brilliant future. That future is not as the singular and ubiquitous holder of data but rather as a major figure in the pantheon of data representations. What the heck happens when data is not kept in SQL?
SQL: THE MIRACLE OF THE AGE, OF THE AGES, AND OF THE AGED
I launched my career in database implementation when Jimmy Carter was president. At the time, theremwere a couple of well-accepted representations for data storage:the network model was expressed in the CODASYL (Conference/Committee on Data Systems Languages) standard with data organized in sets having one set owner (parent) and multiple members (children); the hierarchical model mensured that all data was captured in a tree structure mwith records having a parent-childgrandchild relationship. Both of these models required the programmer to navigate from record to record.
Then along came these new-fangled relational things. INGRES (and its language QUEL) came from UC Berkeley. System-R (and its language SQL) came from IBM Research.Both leveraged relational algebra to support set-oriented abstractions allowing powerful access to data.
At first, they were really, really, really slow. I remember lively debates with database administrators who fervently believed they must be able to know the cylinder on disk holding their records! They most certainly did not want to change from their hierarchical and network databases. As time went on, SQL became inexorably faster and more powerful. Soon, SQL meant database and database meant SQL.
A funny thing happened by the early 2000s, though.People started putting data in places other than“the database.”The old-time database people (including yours truly) predicted their demise. Boy, were we wrong!
Of course, for most of us who had worked so hard to build transactional, relational, and strongly consistent systems, these new representations of data in HTML, XML, JSON, and other formats didnrsquo;t fit into our worldview. The radicals of thersquo;70s andrsquo;80s became the fuddy-duddies of thersquo;00s. A new schism had emerged.
SQL, VALUES, AND RELATIONAL ALGEBRA
Relational databases have tables with rows and columns. Each column in a row provides a cell that is of a well-known type. DDL (Data Definition Language) specifies the tables, rows, and columns and can be dynamically changed at any time, transforming the shape of the data.
The fundamental principle in the relational model is that all interrelating is achieved by means of comparisons of values, whether these values identify objects in the real world or indicate properties of those objects. A pair of values may be meaningfully compared, however, if and only if these values are drawn from a common domain.
The stuff being compared in a query must have matching DDL or it doesnrsquo;t make sense. SQL depends on its DDL being rigid for the duration of the query.
Therersquo;s not really a notion of some portion of the SQLm data having extensible metadata that arrives with the data. All of the metadata is defined before the query is issued. Extensible data is, by definition, not defined (at least at the receiverrsquo;s system).
SQLrsquo;s strength depends on a well-defined schema. Its set-oriented nature uses the well-defined schema for the duration of the operations. The data and metadata (schema) must remain still while SQL does its thing.
THE STILLNESS AND ISOLATION OF TRANSACTIONS
SQL is set oriented. Bad stuff happens when the set of data slides around during the computation. SQL is supposed to produce consistent results. Those consistent results are dependent on input data that appears to be unchanging.
Transactions and, specifically, transactional isolation provide the sense that nothing else is happening in the world.
The Holy Grail of transaction isolation is serializability. The idea is to make transactions appear as if they happened in a serial order. They donrsquo;t actually have to occur in a serial order; it just has to seem like they do.
In figure 1, the red transaction Ti depends upon changes made by the green transactions (Ta, Tb, Tc, Td, and Tf). The blue transactions (Tk, Tl, Tm, Tn, and To) depend on the changes made by Ti. Ti definitely is ordered after the green transactions and before the blue ones. It doesnrsquo;t matter if any of the yellow transactions (Te, Tg, Tj, and Th) occur.before or after Ti. There are many correct serial orders. What matters is that the concurrency implemented in themsystem provides a view that is serializable.
Suddenly, the world is still and set orientation can smile on it.
A SENSE OF PLACE
SQL and its relational data are almost always kept inside a single system or a few systems close to each other. Each SQL database is almost always contained within a trust boundary and protected by surrounding application code.
I donrsquo;t know of any systems that allow untrusted third parties to access their back-end databases
全文共21330字，剩余内容已隐藏，支付完成后下载完整资料
《艾兰，SQL的独特成功，ACM的通信，2016》
SQL在其对数据库行业的影响方面取得了异乎寻常的成功。没有什么东西能和它的广泛性相比。它的成功来自于它高层次的使用了关系代数，允许以行、列、单元格和表为形状的数据进行基于集的操作。
SQL的影响可以从两个广泛的领域看到。首先，程序员可以很容易地使用面向对象的操作方法完成很多事情。第二，为程序员想高层次表达的意图赋予了巨大的性能增益。
本专栏讨论这些功能如何依赖于SQL，通过事务创建静止概念，以及在事务处理时固定架构的一组紧密表的概念。这些特性使得SQL与日益普及的分布式系统不同。
SQL拥有辉煌的过去和美好的未来。它的未来并不仅仅是代表单一的数据持有者，而是作为数据处理中的一个主要工具。数据还未保存在SQL中时发生了什么？
SQL：奇迹的时代
当吉米卡特担任总裁时，我开始了执行数据库的职业生涯。当时，有两种公认的数据存储表示形式：网络模型在CODASYL（数据系统语言会议/委员会）标准中表达，数据按照集合拥有一个集合所有者（父）和多个成员（子女）; 分层模型确定所有数据都是以具有父子关系的记录的树结构捕获的。这两种模式都要求程序员从记录导航到记录。
后来传来的这些新的关系。INGRES（及其语言QUEL）来自加州大学伯克利分校。System-R（及其语言SQL）来自IBM。同样是利用关系代数来支持面向集合的抽象，从而实现对数据的强大访问。
起初，它们运行真的很慢。我记得数据库管理员进行了热烈的辩论，他们热切地相信他们必须能够知道磁盘如何保存他们的记录！他们当然不希望改变他们的分层和网络数据库。随着时间的推移，SQL变得越来越快，越来越强大。很快，SQL代表着数据库和数据库也意味着SQL。
然而，一个有趣的事情发生在2000年代早期，人们开始把数据放在“数据库”以外的地方。孩子，我们错了吗？！
当然，对于我们这些努力构建事务性、关系型和强一致性系统的人来说，这些新的HTML、XML、JSON和其他格式的数据表示并不符合我们的世界观。在70年代和80年代产生的守旧者中，出现了新的分裂。
SQL和关系代数值；
关系数据库有具有行和列的表。行中的每个列都提供一个已知类型的单元格。DDL（数据定义语言）指定的表、行和列，可以随时动态地改变，改变数据的形状。
关系模型的基本原理是所有的相互关联都是通过比较值来实现的，无论这些值是在现实世界中识别的对象还是指示这些对象的属性。然而，当且仅当这些值来自一个公共域时，才可以对一对值进行有意义的比较。
在查询的东西相比，必须有配套的DDL或它没有意义。SQL的DDL刚性取决于它的查询时间。
SQL数据的某些部分没有可扩展的元数据与数据一起到达的概念。在发出查询之前定义所有的元数据。根据定义，可扩展数据没有定义（至少在接收者的系统上）。
SQL的强度取决于定义良好的模式。它的面向对象的性质使用定义良好的模式来操作操作的持续时间。SQL执行任务时，数据和元数据必须保持不变。
交易的静止与孤立
SQL是面向对象的。在计算过程中，当一组数据滑动时，就会发生不好的事情。SQL应该产生一致的结果。这些一致的结果依赖于看起来不变的输入数据。
事务处理，特别是事务性隔离提供了世界上没有其他事情发生的感觉。
事务隔离的特殊性在于它是可串行化的。这个想法是使事物看起来好像是按照连续顺序发生的。实际上它们不必以连续顺序发生，只是看起来像连续的。
在图1中，红色事物Ti取决于绿色事物（Ta，Tb，Tc，Td和Tf）所做的更改。蓝色事务（Tk，Tl，Tm，Tn和To）取决于Ti所做的更改。Ti绝对是在绿色事物之后和蓝色之前订购的。在Ti之前或之后是否发生任何黄色事物（Te，Tg，Tj和Th）并不重要，因为不同事物有其对应的序列号。重要的是，在系统中实现的并发提供了一个可序列化的视图。
突然间，世界仍然在按原有的方向顺利发展。
场所感
SQL及其关系数据几乎总是保存在一个系统或几个彼此靠近的系统中。每个SQL数据库几乎总是包含在信任边界区域内，并受到周围应用程序代码的保护。
我不知道有哪些系统可以让不受信任的第三方访问他们的后端数据库。例如，我的银行的ATM从未让我直接使用JDBC（Java数据库连接）访问其后端数据库。到目前为止，该银行已将我限制在一些诸如存款，提款或转账等操作中。 这真的很烦人！事实上，我想不出任何允许不受信任的第三方在他们的数据库上“派对”的企业数据库。他们都坚持使用应用程序代码来缓解外国人对系统的访问。
这些系统之间发生交互，但它们是通过一些消息或其他数据交换实现的，它们与每个底层数据库松散耦合。消息对应在应用程序代码而不是数据库。
这些数据库中的每一个库似乎都是一个孤岛。现在，这个岛可能有渡船，甚至连连接其他岛屿的四车道桥也可以有。不过，当你访问数据库时，你总是知道你站在哪个岛上。
不同的地方意味着不同的时间
多个数据库共享一个事务的范围是极其罕见的。当一个事务在一个数据库上执行时，与其他系统数据库上的时间相比，它的时间概念并不清晰。 跨不同SQL数据库的分布式事务很少见，也很具有挑战性。
如果您假定两个数据库不共享事务范围，那么跨越空间（数据库）传播工作的简单行为意味着跨时间传输工作（多个事务）。从一个数据库到多个数据库的这种转换是一个开创性的语义转变。 空间和时间本质上是相互联系的。
当从一到多弹出时，SQL及其关系代数不能在没有某种限制的情况下运行。最常见的形式是将一些数据转换成不可变的视图，这些视图可以随着时间的推移有意义的查询。投射这些观点的系统不会改变它们。当它们不改变时，你可以在空间上使用它们。
及时冻结数据可以在空间范围内使用。通常情况下，您还可以投射数据以在您跨越信任边界进行投影时剥离私人内容。为了跨越空间边界，时间必须冻结，至少对于共享的数据而言。当你冻结数据时，它是不可变的。
不变性：一个分布式系统常数
不变的数据可以是不朽和无所不在的。把它看作是基甸圣经，它似乎在每个旅馆的房间里; 我怀疑那里会有很长时间的圣经。如果你想利用基甸圣经作为输入来进行查询，那么你就不会面临并发挑战或隔离。将副本缓存到您需要的位置相对比较简单。
SQL的关系操作可以大规模应用于不可变数据，因为元数据是不可变的，数据是不可变的。使得MapReduce，Hadoop和其他大数据计算成为可能。通过不可变，内容仍然是面向集合的计算是有意义的。
不可变数据在任何时候都可以随处可见。这允许它既在奇点内部又在奇点外面。这没什么了不起，这正是一个分布式系统统一的力量。
典型的集中式数据库强制使用事务来显示它们的数据不可变。当分发阻碍了事务的使用时，您可以快速找到数据的子集，以便可以用可预测的行为穿越边界。
逃脱奇点
SQL数据库功能非常强大，并且在访问和控制数据方面享有独特的成功。 它们允许利用关系代数来组合和分析数据。关系代数涉及包含在表的行和列中的值。这为编程提供了难以置信的力量，并在访问关系数据方面获得了巨大的性能提升。
要做到这一点，关系代数需要静态的一组表，并且不受到并发更改的影响。数据和数据模式在执行操作时都必须是静态的。这是通过事务性可序列化或其他稍微弱化的隔离策略实现的。可序列化提供了一种错觉，即数据库的每个用户在单个时间点都是孤立的。
在关系数据库中，很难在分布式的情况下提供完整的功能，除非可能是在少数几个机器上。更深入地说，SQL在诸如部门或公司这样的单一信任边界内工作得很好。SQL数据库提供了它们存在于空间中某个点的错觉。
在空间和时间上提供一个单一点，既可以产生静止又可以隔离的位置。这增强了关系代数的基于价值的比较。它看起来就像一个奇点。
该行业已迅速转向既不局限于单个时间点的数据表示，也不分布于具有分布式、异构和松散耦合系统的空间中的单个点。现在，SQL环境以外的数据正在生成。
这一趋势正在加速，本专栏探讨了逃避奇点和放宽空间和时间限制的各种后果。不，它不再是你原本的数据库了。
1978年起Pat Helland一直在执行交易系统、数据库、应用平台、分布式系统、容错系统、通讯系统。为了消遣，他偶尔写技术论文。他目前在Salesforce工作。
《布洛赫，有效的java，电子工业出版社，2016》
单例简单来说就是一个类只被实例化一次，通常单例表示一个系统组件。在本质上来说是唯一的，例如窗口管理或文件系统。一个类成为单例会使它的客户端测试变得很困难，因为不可能用伪实现来代替单例，除非它实现了一个接口，这个接口作为它的服务类型。
在1.5版本之前，有两种方式来实现单例。它们都是通过保持私有构造函数并输出一个公有静态成员来提供对类唯一实例的访问来实现的。在第一种方法中，公有静态成员被声明为最终变量：
为了初始化公有静态最终变量，私有构造函数只调用一次。公有或保护构造函数的缺失保证了全局唯一性：确切的说一旦这个被类初始化，将只有一个实例存在——不会多也不会少。客户端不能改变这个情况，要提醒一点：有特权的客户端可以借用连接项目的方法，通过反射机制的调用私有构造函数。如果你需要抵御这种攻击，修改构造函数使它在创建第二个实例时抛出异常。
在第二种实现单例的方法中，公有成员是一个静态工厂方法：
所有上述方法的调用都会返回同一个对象实例，并且不会有其它的实例被创建（提醒同上）。
公有变量方法的主要优势在于更清晰的声明这个类是一个单例类：公有静态变量是最终的，因此它总是包含同一个对象的引用。公有变量方法没有任何性能优势：现代Java虚拟机（JVM）的大多数实现都是将静态工厂方法当做内联函数来调用。
工厂方法的一个优势在于你可以灵活的改变你的想法，无论类是否是单例你都不必修改它的API。工厂方法返回唯一的实例，但它很容易被修改成为每个调用它的线程都返回一个唯一的实例。第二个优势是关于泛型的，在讨论。这些优势往往都是相关的，最终变量方法更简单。
为了使上面方法实现的单例类可序列化（第11章），仅仅在它的声明中实现接口是不够的。为了保证单例性，你必须将所有的实例变量声明为其并提供一个只读方法。否则，每次一个序列化的实例在反序列化时将会创建一个新的实例，在我们的例子中，会看到一个假的类。为了防止这种情况发生，要在该类中添加方法：
在1.5版本中，有第三种实现单例的方法。简单声明一个只有一个元素的枚举类型：
这个方法除了它更简洁之外，它在功能上等价于公有变量方法，免费提供了序列化机制，并且强有力的保证了不会被多次实例化，即使是在面临复杂的序列化或反射攻击时。虽然这个方法仍没有被广泛采用，但单元素的枚举类型是实现单例的最好方式。
有时你会想写一个只包含一组静态方法和静态变量的类。这种类的名声很不好，因为有些人滥用它们来避免思考如何面向对象，但它们确实是有用的。它们可以用来以java.lang.Math或java.util.Arrays的方式来组织与基本类型或数组相关的方法。它们也可以用来以java.util.Collections的方式来组织实现特定接口对象的静态方法，包括工厂方法。最后，它们可以用来组织一个最终类的方法，从而代替扩展这个类。
这种工具类被设计成不能实例化：它的实例是没有意义的。然而，在缺少显式构造函数的情况下，编译器会提供一个公有的无参构造默认函数。对用户而言，这个构造函数与其它的构造函数没有任何差别。在发布的APIs中看到无意义的可实例化类是很罕见的。
企图通过声明一个类为抽象类来强制类不能被实例化是行不通的。这个类可以被子类化，子类可以被实例化。而且，它会使用户误认为这个类是为继承而设计的。然而有一些简单的习惯用法可以确保类不能被实例化。如果一个类没有显式的构造函数，会产生默认的构造函数，因此，一个含有私有构造函数的类不能被实例化：
因为显式构造函数是私有的，因此类的外部不能访问构造函数。不是必须的，但它可以避免类内部无意的调用构造函数。这种习惯用法有点违背直觉，似乎构造函数的提供就是为了它不能被调用一样。因此明智的做法是在类中加上注释，像上面的例子一样。
这种习惯用法的一个副作用就是阻止了类的子类化。子类的所有的构造函数必须调用父类的构造函数，无论是显式的或隐式的，但这种情况下子类不能调用父类构造函数。
本书的目的是为了帮助你最有效的利用Java编程语言和它的基础库，java.lang，java.util，在更小程度上包括java.util.concurrent和java.io。本书有时会讨论其它的库，但不包括图形用户接口编程，企业或移动设备。
本书包括七十八个条目，每个条目传达一条规则。这些规则通常是从实践中得到并且最好最有经验的程序员坚信它是有益的。这些条目被松散的分为十章，每章都是关于软件设计方面的一个扩展。本书不打算被从头到尾的读，每个条目或多或少都是依赖于它本身。这些条目之间的交叉引用非常严重，因此你可以很容易的通过本书划分自己的进度。
Java 5平台增加了许多新功能。本书中的大多数条目在某种程度上使用了这些功能。下表列出了这些新功能在本书中的位置：
大多数条目通过程序实例进行说明。本书的一个重要特点是它包含了说明许多设计模式和习惯用法的代码实例。这些条目放在哪里是合适的，它们被交叉参考引用到了这个领域的标准参考著作。
许多条目包含一个或多个用来表明一些应该在实践中避免的程序实例。这些例子中的都加上了清楚的注释例如“不要做这个”，有时候这些例子也被称为反模式。在每一个例子中，这个条目都解释了为什么这个例子是不好的，并且提建议了一种可替代方法。
本书不是给初学者
全文共6121字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[14894]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
