有一天，我与首席开发人员进行了一次（友好但激烈的）争论，因为我们的项目中有TSQL脚本，我直接将代码写入SQL文件然后我对数据库运行。我发现，当我这样做时，很容易事先制定出架构，而不必费力地指向和点击，然后就没有机会忘记生成脚本以放入源代码管理中，因为生成脚本不再是变得麻烦的事情在事实之后做，但是这个过程是一个隐含的部分（并且还导致没有SQL Server Management Studio插入到它生成的脚本中的额外垃圾的更简洁的脚本）。通过脚本编写数据库，而不是通过SQL Server Management Studio构建数据库，然后生成脚本
我的首席开发人员坚持说，不得不手动编写脚本是一个痛苦的屁股，他完全拒绝用手写出他的脚本，当有完美的工具来做它没有编码。我注意到，将他的更改复制到实际脚本中往往会因此而延迟一点。
对于这种做法的优点和/或缺点，你对此有何看法？在我坚持手工编码模式脚本的过程中，我是否过于僵化/老派？还是他太过依赖第三方工具，并在这个过程中失去了一些东西？
我总是剧本的东西自己，因为奇才有时不中，我喜欢它，并且还将为默认值自己给时髦的名字
脚本事情的方式脚本的东西也是好的情况下，你被解雇和你必须去接受采访，他们问你DDL脚本在白板上
我发现它很快写了一个脚本，因为它是使用SQLMS。您仍然必须在SQLMS中键入名称，并且无论如何都可以使用从键盘和鼠标移动的时间来编写正确的脚本。
正如我通常在模式设计期间与同事合作一样，我倾向于使用GUI工具设计模式，因为它更容易与您前面的表格进行讨论。然后生成脚本，小心选择我想避免在导出后进行手动更改的确切选项。
我认为这两种方法的优劣决定可能会考虑到的因素对架构更改
总而言之，我更倾向于为每个更改（或“迁移”）使用脚本。它让我可以根据优先级的变化重新排列变更发布。
只是因为你可以在图形工具中创建表格并不一定意味着你应该。
你们两个几乎都在处理两组代码。一致性似乎是这些类型决策的关键因素。就你而言，如果你创建了一个脚本，你的老板会用gui来添加一个字段，你会如何保持同步？你不能使用你的脚本来重建表而不编辑它（出错的几率）。
也许他应该拉排名并强迫你用GUI创建它们的方式来格式化你的脚本 - 只是开个玩笑。
Heh，“我的首席开发人员”是指我聘请的高级开发人员。我想我说得很糟糕;我实际上是首席开发人员，他是我的高级开发人员，也正在与我一起开展项目。我们也有初级和中级开发人员，但他们只是按照他们所说的去做。 – 2009-07-07 13:38:59
我想你应该翻转它..........
我的工作也是这样的，无论是工作时（或我自己的项目）或为客户（与其他开发人员）工作时。当我们快速确定事情的范围时，我会使用GUI工具，然后在事情初步形成时转向脚本。从那时起，由于版本控制和可再现性等原因，它是所有其他的脚本.-) – robsoft 2009-07-07 12:39:35