假设有一个应用程序应该在主数据库中创建自己的表(如果它们丢失了)(例如应用程序第一次运行)。这样做的方式更灵活,可扩展,更适合商业产品?
如果我对其进行编码,则不需要其他文件(脚本)。用户将无法使用它们做出愚蠢的事情,然后抱怨应用程序不起作用。但是当db结构中的某些内容发生变化时,我必须编写补丁部分,用户必须安装新的二进制文件(或者只是替换旧的二进制文件)。
脚本解决方案将是几行代码,只需从一些目录和一堆脚本运行所有脚本。二进制可以是相同的,修补将自动应用。但是,新的脚本也必须在某个时候部署到用户。
那么,你会推荐什么?
应用程序将以c#编码,目前数据库将在SQLServer 2005下,但将来可能会发生变化。当然,绘图应用程序和数据库处理部分可以分成两个二进制文件/程序集,但它不能解决我的代码与脚本困境。
答案 0 :(得分:2)
检查Wizardby:它提供了一种特殊语言(有点接近SQL DDL)来表达对数据库模式的更改:
migration "Blog" revision => 1:
type-aliases:
type-alias N type => String, length => 200, nullable => false, default => ""
defaults:
default-primary-key ID type => Int32, nullable => false, identity => true
version 20090226100407:
add table Author: /* Primary Key is added automatically */
FirstName type => N /* “add” can be omitted */
LastName type => N
EmailAddress type => N, unique => true /* "unique => true" will create UQ_EmailAddress index */
Login type => N, unique => true
Password type => Binary, length => 64, nullable => true
index UQ_LoginEmailAddress unique => true, columns => [[Login, asc], EmailAddress]
add table Tag:
Name type => N
add table Blog:
Name type => N
Description type => String, nullable => false
add table BlogPost:
Title type => N
Slug type => N
BlogID references => Blog /* Column type is inferred automatically */
AuthorID:
reference pk-table => Author
这些version
块基本上是您希望应用于数据库架构的更改。
Wizardby也可以集成到您的构建过程以及应用程序中:每次启动时都可以尝试将数据库升级到最新版本。因此,您的应用程序将始终使用最新的架构版本。
它也可以集成到您的设置过程中:Wizardby可以生成SQL脚本来更改数据库架构,这些可以作为设置过程的一部分运行。
答案 1 :(得分:0)
我通常希望将我的安装代码与我的应用程序代码分开。您肯定希望您的应用程序对数据库执行某种版本检查,以确保它在运行之前具有所需的正确结构。我将遵循的基本设置是:
使用每个已发布的脚本 用于进行架构更改的版本 部署的数据库。
在您的数据库中有一些东西可以跟踪当前版本 数据库,也许是简单的版本 跟踪哪些脚本的表 一直反对它。它更简单 寻找版本脚本比 每次检查架构 搜索所有表格和字段 你需要。
让您的应用程序检查数据库版本标记以确保它 符合应用程序的版本。 记录一个允许用户的错误 知道他们必须更新他们的 数据库脚本的数据库。
这应该保持应用程序代码干净,但要确保数据库和应用程序保持同步。
答案 2 :(得分:0)
然后使用像DBGhost或DVC这样的版本控制工具可以帮助您维护数据库更新,并且可以进行修改以无缝地适应您的应用程序。