大卫·惠勒提出了一种用于数据库连接的标准URI格式。该提议将允许基于不同技术构建的应用程序共用相同的连接串。这对于包括报表设计器、自动构建和部署工具以及ORM在内的众多工具都是有好处的。该提议以db作为方案名，紧随其后是数据库引擎名。这是第一个与当前做法不同的地方。它没有指定具体的驱动程序，而是留给应用程序自己决定。
对于跨平台的URI标准而言，这是关键。由于连接到同样的数据库引擎常常需要不同的驱动程序名，所以在JDBC、OleDB和ODBC之间共用连接串非常困难。即使在一种API中，也可能有多种驱动程序可用。
在引擎名之后是一组标准化的参数：用户名、密码、主机、端口和数据库名。这些参数总是以相同的顺序出现，这是又一个与当前做法不同的地方。 - db:engine://[username[:password]@]host[:port][/dbname][?params]
- db:engine:[dbname][?params]
任何数据库在“？”之后指定参数都非常像HTTP请求的查询参数。这些参数会使用标准的键-值格式。
最后是一个可选段，用符号“#”表示，用于指定具体的表或视图。
有若干格式都是遵循engine://authority/dbname这一惯例，该格式即是受此启发。
有人对使用前缀“db：”提出了若干反对意见。彼得·艾森特劳特写到，
我认为前缀db：是没有必要。首先，我认为，RFC 3986的语法规则不允许有两个方案前缀。其次，它没用。假设一款软件能够使用这些URI，那么它也将能够通过方案本身知道需要做什么。
通常，URL确定了用于访问资源的协议，但它并不是资源的性质。例如，一个git库可以通过几种不同的方案访问。没有单独的git：URL系统，更不用说scm：git或者其它什么实现。另外，浏览器能够通过诸如http：和ftp：等几种不同的协议访问文件。没有单独的textfile：或者video：URL方案。真见鬼，文件甚至可能是一个数据库，因此，我希望有个像SQLite的东西，可以接受典型的http：URL作为其数据库URL。
除了要求实现者尽力忠实地遵循RFC 3986外，我不认为有很多东西需要标准化。
我们也可以反驳上述观点。例如，如果没有一个通用的前缀，开发人员将不得不在操作系统中为应用程序能够连接的每个数据库引擎注册一个单独的前缀。当遇到先前不知道的数据库时，这种方案会允许应用程序提示用户，而不是简单地失败。这类似于每个文件类型都一个单独的前缀，而不是仅仅使用http/https，然后由浏览器决定做什么。
大卫·惠勒在其声明中提到了其它需要考虑的问题。
首先，权限部分必须包含一个主机地址的要求阻止了可用于连接Unix套接字的只包含一个用户名的URI规范。其中，PostgreSQL和MySQL提供经过身份验证的套接字连接。RFC 3986需要主机名，而其前身RFC 2396并不需要。此外，作为先例，文件URI也不需要。因此，我正考虑允许使用类似的方式连接到PostgreSQL数据库： db:pg://postgres:secr3t@/
总之，允许用户信息中没有主机名是有意义的。
第二个问题是在权限部分之后的路径部分中不允许相对文件名。这里的问题是，大部分数据库引擎并不使用路径作为数据库名，因此，前面的斜杠毫无意义。例如，在db:pg:localhost/foo中，PostgreSQL数据库的名称是foo，而不是/foo。但在db:firebird:localhost/foo中，Firebird数据库的名称是路径/foo。这样，每一种引擎实现必须知道路径部分是否是一个文件名。
但实际上，有些数据库可能允许为本地连接指定路径，为远程连接指定名称。Informix似乎就支持这种变体。那么如何知道路径是文件路径还是命名的数据库呢？这两种变体是无法区分的。
RFC 2396非常明确地规定，当路径部分在权限部分的后面时必须是绝对路径。但是，RFC 3986只在没有权限部分时才禁止双斜杠。因此，我认为，对于绝对路径，最好是有第二道斜杠。使用简单名称或者相对路径的引擎可以直接将它们放在第一道斜杠后面，而绝对路径可以使用第二道斜杠： - 绝对路径： db:firebird://localhost//tmp/test.gdb
- 相对路径： db:firebird://localhost/db/test.gdb
- 名称： db:postgresql://localhost/template1
查看英文原文：A Proposal for a Database URI Standard
转自 http://www.infoq.com/cn/news/2013/12/DB-URI-Standard | 
