Сильные имена базы данных на сервере базы данных

Создание Developmestuction , где вы иметь несколько экземпляров одной и той же базы данных (Dev, Production) на одном сервере базы данных просто вызывает проблемы. Если вы не можете получить второй сервер (физический или виртуальный), вам следует подумать о создании отдельных экземпляров SQL Server.

Имя вашей базы данных должно отражать ваше внутреннее обращение к приложениям. Вы писали:

У нас есть клиенты с несколькими версиями одного и того же приложения и несколькими приложениями для одного клиента

Непонятно, о чем вы. Возьмите одну из своих "базовых" приложения, а затем настроить приложение для разных клиентов? Вы создаете совершенно разные приложения для разных клиентов? Это смесь того и другого?

Я предполагаю, что вы начинаете с разработки одноразового приложения и, если оно нравится другому клиенту, используете его в качестве базового приложения для будущих клиентов. Исходя из этого, было бы разумно ссылаться на ваши приложения по имени + клиенту и соответствующим образом называть свои базы данных.

• SalesManager_Wilco
• SalesManager_AbcInc
• SalesManager_Internal
• TimesheetKeeper_Internal
• ExpenseTracker_Wilco
• HelpBuilder_Wilco
• HelpB ]

Мне нравится включать имя сайта в мои схемы именования баз данных, когда это возможно:

client_sitename_app_version

Если у одного клиента есть несколько приложений, работающих с одной и той же версией на одном сайте, каждому из них нужна собственная база данных .. Это кажется немного странным. В зависимости от варианта использования вам понадобится еще один отличительный фактор. Добавьте номер экземпляра или ссылку на использование в самом конце.

Мы используем {product} {version} {Development | Test} _ [необязательное описание функции, владелец, дата]

Его длинный, но означает, что каждую базу данных можно отслеживать, и у каждой базы данных есть идентификатор владельца. Итак, основная база данных продукта для версии 4.2 - это, скажем, Product42Development ... и с ней связана база данных однорангового тестирования Product42Test .

База данных однорангового тестирования отделена от основная тестовая база данных (которая находится на другом сервере и используется исключительно командой тестирования): это то место, где разработчики вносят свои исправления, прежде чем вносить их в основное дерево, проверяя ее другими разработчиками (следовательно, равноправный тест), но сохраняя ее вне активной разработки (которая постоянно меняется и нестабильна).

Если существует ветвь базы данных, необходимая из-за того, что кто-то занимается очень разрушительной разработкой, она должна включать имя функции, владельца функции и дату создания. Что-то вроде: Product42Development_NewFeatureName_OwnerName_20090812 ... это гарантирует, что администраторы баз данных не только смогут отслеживать, какие базы данных существуют, но (что более важно) так же могут и все другие разработчики, чтобы они не возились с базой данных без частично информированы о том, для чего существует БД.

Мы используем изоляцию контейнера для запуска различных экземпляров / кратных версий баз данных (postgres и mysql), но проблема схемы именования остается той же. Мы следуем следующему:

Имя клиента + идентификатор продукта + тип задачи (продукт, постановка, тест, учет и т. Д.)

например: nuxil_erp_test, nuxil_erp_prod, nuxil_erp_accountingTraining.

Однако мы, вероятно, позволим отказаться от этой схемы именования, потому что у клиентов есть возможность создавать новые базы данных, и у всех есть свои собственные идеи по именованию баз данных.

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).

В одной из крупных компаний, с которыми я работал в прошлом году, внедряя набор инструментов, проданный моим работодателем, мы следовали их региональным соглашениям об именах :

US

• {p | d} , где p для производства, а d для разработки

UK + HK

• {p | d}

Это работает для них. Лично я также называю свои экземпляры базы данных по имени приложения и использованию.