一项针对数据库URI标准的提议

　　大卫·惠勒提出了一种用于数据库连接的标准URI格式。该提议将允许基于不同技术构建的应用程序共用相同的连接串。这对于包括报表设计器、自动构建和部署工具以及ORM在内的众多工具都是有好处的。该提议以db作为方案名，紧随其后是数据库引擎名。这是第一个与当前做法不同的地方。它没有指定具体的驱动程序，而是留给应用程序自己决定。

　　对于跨平台的URI标准而言，这是关键。由于连接到同样的数据库引擎常常需要不同的驱动程序名，所以在JDBC、OleDB和ODBC之间共用连接串非常困难。即使在一种API中，也可能有多种驱动程序可用。

　　在引擎名之后是一组标准化的参数：用户名、密码、主机、端口和数据库名。这些参数总是以相同的顺序出现，这是又一个与当前做法不同的地方。

• db:engine://[username[:password]@]host[:port][/dbname][?params]
• db:engine:[dbname][?params]

　　任何数据库在“？”之后指定参数都非常像HTTP请求的查询参数。这些参数会使用标准的键-值格式。

　　最后是一个可选段，用符号“#”表示，用于指定具体的表或视图。

　　有若干格式都是遵循engine://authority/dbname这一惯例，该格式即是受此启发。

• PostgreSQL libpq URIs
• SQLAlchemy URLs
• Stackato数据库URLs
• Django数据库URLs
• Rails数据库URLs

　　有人对使用前缀“db：”提出了若干反对意见。彼得·艾森特劳特写到，

我认为前缀db：是没有必要。首先，我认为，RFC 3986的语法规则不允许有两个方案前缀。其次，它没用。假设一款软件能够使用这些URI，那么它也将能够通过方案本身知道需要做什么。

通常，URL确定了用于访问资源的协议，但它并不是资源的性质。例如，一个git库可以通过几种不同的方案访问。没有单独的git：URL系统，更不用说scm：git或者其它什么实现。另外，浏览器能够通过诸如http：和ftp：等几种不同的协议访问文件。没有单独的textfile：或者video：URL方案。真见鬼，文件甚至可能是一个数据库，因此，我希望有个像SQLite的东西，可以接受典型的http：URL作为其数据库URL。