修改共享主机上的 SQL 数据库

发布于 2024-07-27 19:31:58 字数 661 浏览 7 评论 0 原文

我在共享托管服务器上有一个实时数据库。 我正在对我的网站代码进行一些重大更改,并且我想修复我在最初设计数据库时犯的一些愚蠢错误。 这些更改涉及更改大量字段的大小,以及正确执行表之间的引用完整性。 如果可能的话,我想在本地测试服务器和远程服务器上进行更改。

我应该指出,虽然我对编写复杂的查询来处理数据相当满意,但我在没有图形界面的情况下修改数据库结构的经验很少。

我可以在 Visual Studio 数据库资源管理器中访问远程数据库,但除了数据操作之外不能将其用于任何其他用途。 我昨晚安装了 Sql Management Studio Express,在 40 多次崩溃之后我放弃了 - 我什至无法修补这个该死的东西。

远程服务器是 SQL 2005 / MyLittleAdmin Web 界面可用。 所以我的问题是完成这些改变的最佳方法是什么。 我可以在远程服务器上使用图形界面吗? 如果没有,是否有一种简单的方法可以将数据库复制到本地计算机,修复它,然后重新上传? 最后,如果以上都不可行,是否有人有关于通过查询修复引用完整性的不错信息的链接?

抱歉,这个问题有些笼统——我觉得我让这件事变得比应有的困难得多,但经过整晚的搜索/尝试,我什么也没得到。 先谢谢您的帮助。 对此,我真的非常感激。

……还有谁有时间机器可以借给我吗——我需要为此痛斥过去的自己。

I have a live database on a shared hosting server. I am making some major changes to my site's code and I would like to fix some stupid mistakes I made in initially designing the database. These changes involve altering the size of a large number of fields, and enforcing referential integrity between tables properly. I would like to make the changes on both my local test server and the remote server if possible.

I should note that while I'm fairly comfortable with writing complex queries to handle data, I have very little experience modifying database structure without a graphical interface.

I can access the remote database in the visual studio database explorer but I can not use that for anything other than data manipulation. I installed Sql Management Studio express last night and after 40+ crashes I gave up - I couldn't even patch the damn thing.

The remote server is SQL 2005 / The MyLittleAdmin web interface is available.
So my question is what is the best way to accomplish these changes. Is there a graphical interface I can use on the remote server? If not is there an easy way to copy the database to my local machine, fix it, and re upload? Finally if none of the above are viable does anyone have links to a decent info on fixing referential integrity via query?

Sorry for the somewhat general question - I feel like I am making this far harder than it should be but after searching / trying all night i haven't gotten anywhere. Thanks in advance for the help. I really appreciate it.

...Also does anyone have a time machine I can borrow- I need to go kick my past self's ass for this.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

始终不够 2024-08-03 19:31:58

通常托管提供商允许您备份和恢复数据库,因此完成移动的最简单方法是备份实时数据库,下载备份文件,在本地恢复,执行所有更改,备份本地数据库,上传然后在实时服务中恢复它。 在此期间,您的站点应处于管理关闭状态,以便在您执行此操作时它不会继续更新数据。 您必须确保您的本地 SQL 实例与托管提供商完全相同的构建版本 (@@version),否则您的本地 SQL 可能会升级数据库结构,并且您将无法将其恢复回托管提供商 (否则,如果您的版本早于主机,您将无法在本地服务器上恢复)。 MSDN BOL 有关于如何使用备份/恢复复制数据库

备份/恢复的替代方法是分离/附加数据库,但我不建议这样做,因为您需要移动两个 MDF和 LDF 同步,而且它们的大小也比备份大。

这假设您可以以向导的方式对本地副本进行所有架构更改,即。 快速且正确。 当然,这并不容易。 推荐的方法是及时准备一个脚本,该脚本应用达到新模式所需的所有转换。 有一些工具,例如 SQL DiffSQL 比较, SQL Delta 等可以生成这样的脚本。 Visual Studio 数据库版也可以做到这一点。

我将如何执行此操作,如下所示:

  1. 确保我的开发计算机上的架构与实时主机上的架构完全相同。 如果不确定,我可以备份实时服务器并在本地恢复。 这将是我的参考,v1。 架构。
  2. 保留 v1 的备份。 供参考
  3. 开始开发一个脚本,将架构更改为我的目标。 有时我需要自己刷新对脚本语法的记忆,我所做的就是转到 SQL Server Management Studio 向导进行我想要执行的操作,选择 UI 中的所有选项,然后选择“显示脚本选项” ,这将准确地显示 SSMS 正在运行的脚本来完成我想要的更改。
  4. 对于我添加到脚本中的每个更改,我可以通过恢复 v1.1 版本来测试它。 参考我从步骤 1 获得的备份并运行脚本。
  5. 继续迭代脚本,一次添加一项更改,直到完成所有所需的架构更改。 每次更改后,我都可以像步骤 4 一样再次测试它。
  6. 您的脚本不仅应该对架构进行 DDL 更改,还应该进行所需的任何 DML 更改(修改参考数据、更改值、在表格之间移动列等)。
  7. 当脚本准备好后,我可以下载更新的备份,应用脚本,上传更新的备份并将其恢复到实时主机上。 或者,您可以简单地在实时主机上运行脚本(当然,在您备份它之后,以防出现严重错误)。

在我的项目中,我总是依赖脚本来部署和升级数据库。 事实上,我使用数据库扩展属性来存储应用程序部署模式的“版本”,并且在我的代码中,我只需前滚将模式带到我的最新版本的所有脚本。 我的博客上有一篇文章描述了这种技术: 版本控制和您的数据库

Usually hosting providers allow you to backup and restore your database, so the easiest way to accomplish the move is to backup your live DB, download the backup file, restore it locally, do all the changes, do a backup of the local db, upload it, then restore it in the live service. Your site should be placed on an administrative shutdown during this time so it does not continue to update the data while you're doing this operations. You have to make sure your local SQL instance is exactly at the same build version (@@version) like the hosting provider, otherwise your local SQL may upgrade the database structure and you'll be unable to restore it back on the hosting provider (or you'll be unable to restore in on your local server if your version is earlier than the host's). The MSDN BOL has a detailed guid on how to Copy Databases using Backup/Restore.

An alternative to backup/restore is to detach/attach the database, but I do not recommend this because you need to move both the MDF and the LDF in sync, and they're also larger in size than a backup.

This assumes you can do all the schema changes on your local copy in a wizardly manner, ie. fast and correct. Of course, that is not easy. The recommended way is to prepare in time a script that applies all the transformations needed to reach the new schema. There are tools like SQL Diff, SQL Compare, SQL Delta and other that can generate such a script. Also Visual Studio Database Edition can do this.

How I would do this would be like this:

  1. Ensure I have exactly the same schema on my dev machine as on the live host. If not sure, I can take a backup of the live server and restore it localy. This would be my reference, v1. schema.
  2. Keep the backup of v1. for reference
  3. Start developing a script that changes the schema to my target. Sometimes I need to refresh my memory on script syntax myself, and what I do is I go to the SQL Server Management Studio wizards for the operation I want to do, select all the options in the UI and then select the 'show script options', that will show me exactly the script SSMS is running to accomplish my desired change.
  4. For each change I add to the script, I can test it by restoring the v1. reference backup I have from step 1 and running the script.
  5. Keep iterating on the script, adding one change at a time, until all the needed schema changes are done. After each change, I can test it again like in step 4.
  6. Yourscript should do not only DDL changes to the schema, but also any DML changes needed (modifying reference data, changing values, moving columns between tabels etc).
  7. When the script is ready, I can download a newer backup, apply the script, and upload the updated backup and restore it on the live host. Alternatively you can simply run the script on the live host (after of course you backed it up in case something goes horribly wrong).

In my projects I always rely on scripts to deploy and upgrade the database. In fact I use the database extended properties to store a 'version' of my application deployed schema and in my code I simply roll forward all the scripts that bring the schema to my last version. I have an article on my blog describing this technique: Version Control and your Database.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文