数据库服务器上的强数据库名称
我们有一个 SQL 服务器，里面有很多数据库。我们的客户拥有类似应用程序的多个版本，并且单个客户拥有多个应用程序。几乎所有数据库都与特定网站相关联。
您如何保持数据库名称的组织性？当然没有单一的答案，但是您有适合您的数据库命名策略吗？
我们正在考虑：
客户+产品+开发阶段（生产、暂存等）
但这变成了当客户运行一个产品的三个版本时会很尴尬。
We have a SQL server with many databases in it. We have customers with multiple versions of a similar app and multiple apps for a single customer. Almost all databases are tied to specific websites.
How do you stay organized with your database names? Surely there is no single answer, but do you have a database naming strategy that is working for you?
We are considering:
Customer + Product + Phase of Development (Production, Staging, etc.)
But that becomes awkward when a customer runs three versions of a product.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我们的命名策略通常基于“三个字母缩写词”（TLA）的串联数据库的不同“维度”，用下划线分隔。此规则适用于站点、应用程序、客户端等。
例如，当我的应用程序首字母缩略词是 ABC 时，并且我们的阿联酋办事处是 ABC 数据库的订阅者，则该数据库名称将为 < code>ABC_UAE（使用该国的官方/ISO TLA当然是一个不错的选择）。
为客户提供 TLA 标识符后，您可以使用它来构建数据库名称：
ABC_ACM：用于 Acme 公司的主/中央 ABC 数据库ABC_ACM_CAN：用于其订阅者的数据库在加拿大现在，如果您维护不同的数据库版本，您可以选择：
ABC_012_ACM如果为多个客户端维护版本 1.2ABC_ACM_012如果 Acme 有其特定的 1.2 版本如果这些数据库有订阅者，那么
ABC_ACM_012_CAN的含义就很明显了。我建议您使用标准的 3 位数版本号编号。它让事情变得更容易！当谈论开发数据库时，这条规则有一些例外。例如，如果开发由客户维护，我的开发人员的
ABC_ACM数据库版本将为ABC_ACM_pgrondier，如果开发由版本维护，则为ABC_012_pgrondier。事实上，当您遇到个人订阅者时，数据库名称的最后一个“维度”不实现 TLA 规则的情况也很常见：ABC_ACM_012_username是ABC_ACM_012 的订阅者ABC_ACM_012_CAN_username是ABC_ACM_012_CAN的订阅者< /p>Our naming strategy is usually based on the concatenation of 'three letters acronyms' (TLA's) representing the different 'dimensions', of the database, separated by underscores. This rule is applied for sites, applications, clients, etc.
For example, when my app acronym is
ABC, and our United Emirates Office is a suscriber to the ABC database, this database name will then beABC_UAE(Using then the offical/ISO TLA of the country is of course a nice choice).Once you give your clients a TLA identifier, you can use it to build your database name:
ABC_ACM: for the main/central ABC database for Acme CompanyABC_ACM_CAN: for its subscriber's in CanadaNow, if you maintain different database versions, you have the choice between:
ABC_012_ACMif version 1.2 is maintained for multiple clientsABC_ACM_012if Acme has its specific 1.2 versionIn case these databases have subcribers, the meaning of
ABC_ACM_012_CANis then quite obvious. I'd advise you to use a standard 3 digits numbering for version numbers. It makes things really easier!This rule suffers some exception when talking about development databases. For example, my developer's version of
ABC_ACMdatabase will beABC_ACM_pgrondier, if development is maintained by client, orABC_012_pgrondierif development is maintained by version. As a matter of fact, having the last 'dimension' of the database name not implementing the TLA rule is also quite common when you come to individual suscribers:ABC_ACM_012_usernameis subcriber toABC_ACM_012ABC_ACM_012_CAN_usernameis subcriber toABC_ACM_012_CAN创建 Developmestuction，其中同一数据库上有同一数据库的多个实例（开发、生产）服务器只是自找麻烦。如果您无法获得第二台服务器（物理或虚拟），则应考虑创建单独的 SQL Server 实例。
您的数据库名称应反映您在内部引用应用程序的方式。你写道：
目前尚不清楚您的意思。是否要采用您的“基本”应用程序之一，然后为不同的客户定制该应用程序？您是否为不同的客户创建完全不同的应用程序？它是两者的混合物吗？
我的假设是，您首先开发一个一次性应用程序，如果另一个客户喜欢它，则将其用作未来客户的基础应用程序。基于此，通过名称+客户引用您的应用程序并相应地命名您的数据库是有意义的。
Creating a Developmestuction where you have multiple instances of the same database (Dev, Production) on the same database server is just asking for trouble. If you can't get a second server (physical or virtual), you should consider creating separate instances of SQL Server.
Your databases name should reflect how you internally refer to the applications. You wrote:
It's not clear what you mean. Do take one of your "base" applications and then customize the application for different clients? Do you create completely different applications for different clients? Is it a mixture of both?
My assumption is that you start by developing a one-off application and, if another client likes it, use that as a base application for future customers. Based on that, it would make sense to refer to your applications by name+customer, and name your databases accordingly.
我喜欢尽可能在我的数据库命名方案中包含站点名称：
如果一个客户端有多个应用程序在同一站点上运行相同版本，每个应用程序都需要自己的数据库......这似乎有点奇怪。根据用例，您将需要另一个区分因素。在最后附加实例编号或使用参考。
I like to include the site name in my db naming schemes when possible:
If one client has multiple apps running the same version on the same site that each need their own db... that seems a bit odd. You would need another distinguishing factor there depending on use case. Append an instance number or usage reference at the very end.
呼应之前的帖子并添加一些评论：
当然，公司/客户和应用程序。哪个先执行取决于哪个更重要——不是对客户重要，而是对支持软件的人员重要。
我完全同意只有生产系统才应该位于生产服务器上。开发、测试、QA、暂存、EAP 等等，最好都在自己的机器、SQL 实例或 VMWare 实例上提供服务。 （“Developmestuction”。喜欢它。）
我质疑将版本添加到数据库名称中。 X版本的数据库可以更新到X+1或X.1版本吗？如果是这样，您是否必须挖掘并重命名所有连接字符串和引用数据库名称的其他位？版本控制数据是我将（并且确实）存储在每个数据库中的信息。如果升级意味着将旧数据库中的数据迁移到新建数据库中，我想您可以将版本放在名称中。如果您必须主动支持给定数据库“类型”的多个版本，并且对于支持系统的人员来说，在数据库名称中清楚地说明该信息很有用，那么就继续使用它（不过，请再次注意更新/重命名问题） ）。
Echoing the prior posts and tossing in some comments:
Definitely, Company/Client and Application. Which goes first depends on which is more important--not to the client, but to the people supporting the software.
I totally agree that only Production systems should be on a Production server. Development, Testing, QA, Staging, EAP, whatever, they're all best served by being on their own box, SQL instance, or VMWare instance. ("Developmestuction". Love it.)
I question adding version to the database name. Can a database of version X be updated to version X+1 or X.1? If so, do you have to dig out and rename all your connection strings and other bits referencing database names? Versioning data is information I would (and do) store within each database. If an upgrade means migrating the data in an old database to a newly constructed one, I guess you could put the version in the name. And if you have to actively support multiple versions of a given database "type", AND it's useful for the people supporting the system to have that information clearly stated in the database name, then go for it (though again, beware updating/renaming issues).
我们使用{产品}{版本}{开发|测试}_[可选功能描述、所有者、日期]
它很长，但确实意味着每个数据库都可以跟踪，并且每个数据库都有一个可识别的所有者。因此，版本 4.2 的主要产品数据库是
Product42Development...并且具有关联的同行测试数据库Product42Test。对等测试数据库与主测试数据库是分开的（位于不同的服务器上，并且纯粹由测试团队使用）：开发人员在将其放入主树之前，在其中进行修复，并由其他开发人员对其进行测试（因此，同行测试），但将其排除在积极的开发之外（不断变化且不稳定）。
如果因为有人正在进行非常颠覆性的开发而需要数据库的一个分支，那么它最终会包括功能名称、功能所有者和创建日期。类似于：
Product42Development_NewFeatureName_OwnerName_20090812...这确保 DBA 不仅可以跟踪存在的数据库，而且（更重要的是）所有其他开发人员也可以跟踪数据库，这样他们就不会与数据库发生冲突而不部分了解数据库的用途。We use {product}{version}{Development|Test}_[optional feature description, owner, date]
Its lengthy, but does mean each database can be tracked and each database has an identifibale owner. So the main product database for version 4.2 is, say,
Product42Development... and that has an associated peer-test databaseProduct42Test.The peer-test database is separate from the main test database (which is on a different server and used purely by the test team): it's where developers stage their fixes prior to making it into the main tree, having it tested by other devs (hence peer-test) but keeping it out of the active development (which is constantly changing and unstable).
If there's a branch of the database needed because someone's doing very disruptive development, it would end up including the feature name, feature owner and date of creation. Something like:
Product42Development_NewFeatureName_OwnerName_20090812... this makes sure that not only can the DBAs keep track of what databases exist, but (more importantly) so can all other devs so they don't bugger about with the database without being partially informed about what the DB's there for.我们使用容器隔离来运行不同实例/多个版本的数据库（postgres 和 mysql），但命名方案问题仍然相同。我们遵循下一个：
客户名称 + 产品 ID + 任务类型（生产、登台、测试、会计等）
，例如：nuxil_erp_test、nuxil_erp_prod、nuxil_erp_accountingTraining。
然而，我们可能会放弃这种命名方案，因为客户有能力创建新的数据库，并且他们对命名数据库都有自己的想法。
We are using container isolation to run different instances/multiples version of the databases (postgres and mysql) but the naming scheme problem is still the same. We follow the next one :
Customer name + product ID + task kind (prod, staging, test, accounting, etc.)
eg : nuxil_erp_test, nuxil_erp_prod, nuxil_erp_accountingTraining.
However, we'll probably let go off that naming scheme because customers have the ability to creating new databases, and they all have their own ideas about naming databases.
去年，我在一家大公司部署了雇主出售的工具集，我们遵循他们的区域命名约定：
US
{p|d} 英国 + 香港
这对他们有用。就我个人而言，我也根据应用程序名称和用法来命名我的数据库实例。
At one of the large companies I worked with last year deploying the toolset my employer sold, we followed their regional naming conventions:
US
<appname>{p|d}where p is for production and d for developmentUK + HK
<datacenter><appname>{p|d}That works for them. Personally, I name my database instances around the appname and usage, too.