#sql-server-2005 #sql-server-2000 #versioning
#sql-server-2005 #sql-server-2000 #управление версиями
Вопрос:
Простая ситуация. Я создал приложение, которое использует SQL Server в качестве базы данных. Я мог бы добавить в эту базу данных таблицу, содержащую номер версии моего приложения, чтобы мое приложение могло проверить, взаимодействует ли оно с правильной версией базы данных. Но поскольку внутри базы данных нет других настроек, которые я сохраняю, это означало бы, что я бы добавил единственную таблицу с единственным полем, которое содержит только одну запись.
Какая пустая трата хорошего ресурса…
Есть ли другой wat, который я могу сообщить базе данных SQL Server о версии продукта, с которой он связан?
Меня интересует не версия самого SQL Server, а версия базы данных, которую он использует.
(Кстати, это относится как к SQL Server 2000, так и к 2005.)
Комментарии:
1. В вашем приложении нет таблицы конфигурации?
2. Нет, параметры конфигурации устанавливаются в клиенте, таким образом, несколько конфигураций могут работать с одной базой данных. Единственная часть, которая может вызвать проблемы, — это другая структура базы данных, которая была бы вызвана более новой версией структуры.
Ответ №1:
Если вы используете SQL 2005 и выше, вы можете сохранить информацию о версии как расширенное свойство самой базы данных и запросить представление sys.extended_properties для получения информации, например :
sys.sp_addextendedproperty @name=N'CurrentDBVersion', @value=N'1.4.2'
SELECT Value FROM sys.extended_properties WHERE name = 'CurrentDBVersion' AND class_desc = 'DATABASE'
Если SQL 2000, я думаю, что ваш единственный вариант — это ваша собственная таблица с одной строкой. Накладных расходов практически не существует.
Комментарии:
1. Похоже, это тот трюк, который я искал! Жаль, что это не работает для SQL Server 2000…
2. В SQL 2000 вы можете добавлять расширенные свойства практически ко всем объектам, кроме самой базы данных.
Ответ №2:
Я бы пошел с огромными накладными расходами на поле varchar(5) с tinyint PK. Это имеет наибольший смысл, если вы говорите о продукте, который уже использует базу данных SQL Server.
Вы беспокоитесь о накладных расходах на такую маленькую часть системы, что они становятся незначительными.
Комментарии:
1. Кроме того, вы можете найти дополнительное применение таблице конфигурации для других частей вашей системы.
2. На самом деле, поскольку в будущем эта база данных будет использоваться другими разработчиками, я беспокоюсь, что они будут злоупотреблять ею для хранения всевозможных опций приложения, в то время как я предпочитаю сохранять эти настройки на стороне клиента.
3. Справедливое замечание. Расширенное свойство, предложенное CodeByMoonlight, является наиболее разумным решением в этом случае. Я даже не думал об этом 🙂
Ответ №3:
Я бы поместил настройки подключения в приложение или конфигурационный файл, который считывает приложение. Попросите приложение проверить номер версии в настройках подключения.
Комментарии:
1. Печально, что вы почувствовали необходимость проголосовать против ответа только потому, что вы не «заинтересованы» в том, чтобы сделать это одним способом. Я всего лишь пытался помочь, и я чувствую, что дал правильный ответ, просто не тот, который вы хотите.
2. Я проголосовал против, потому что ваш ответ никоим образом не связан с вопросом. Я спрашиваю о номере версии продукта, а вы ссылаетесь на строку подключения к базе данных. Это не может быть номер версии на стороне приложения. Она должна быть привязана к структуре базы данных!
Ответ №4:
Даже если бы в SQL Server была такая функция, я бы не стал ее использовать. Почему?
- Добавление новой таблицы для хранения информации незначительно по сравнению с размером и скоростью приложения и базы данных
- В новой таблице могут храниться другие данные конфигурации, относящиеся к приложению, и у вас уже есть механизм для этого (и если ваше приложение настолько велико, у вас будут другие данные конфигурации)
- Привязка приложения к определенному ядру базы данных (особенно таким образом) очень редко бывает полезной
- Не стандартная практика и не очевидна для тех, кто впервые знакомится с системой
Комментарии:
1. Предполагается, что проектом не должен заниматься кто-то новый и неопытный. Существует большой технический документ, в котором объясняется, как он создан и почему были приняты определенные решения. Никому не разрешается что-либо изменять, пока он не прочитает и не поймет этот документ.
Ответ №5:
Я настоятельно рекомендую записать версию базы данных в базу данных. В приложении, которое мы поддерживали более десяти лет или около того, мы обновляли схему базы данных в каждом выпуске. Когда пользователь запускал приложение после установки обновления, оно могло определить, устарела ли база данных, и преобразовать ее в более новую схему. На самом деле мы выполнили инкрементное обновление: чтобы перейти с 7 на 10, мы сделали 7 -> 8, 8->9, 9->10. Также представьте сценарий, когда кто-то восстанавливает базу данных в более старое состояние из резервной копии.
Даже не думайте о добавлении отдельной таблицы, просто сделайте это (и подумайте о вариантах использования).
Комментарии:
1. Это то, что я бы сделал, если бы не было другого решения. Но я хочу знать альтернативы, чтобы я мог проверить, добавят ли эти альтернативы некоторые практические преимущества.