首先编写数据库脚本，而不是通过SQLServerManagementStudio构建数据库，然后生成脚本

前几天，我与我的首席开发人员进行了一次（友好但激烈的）争论，因为我们的项目有TSQL脚本，我直接将其编码到SQL文件中，然后针对数据库运行。我发现，当我这样做的时候，不需要精确地指向和单击就可以很容易地预先计算出模式，然后就没有机会忘记生成一个脚本以将其放入源代码管理，因为生成脚本不再是事后必须做的一件琐事，而是过程中一个隐含的部分（还可以生成更干净的脚本，而不需要SQLServerManagementStudio在生成的脚本中插入额外的垃圾）

我的首席开发人员坚持认为，必须手动编写脚本是一件痛苦的事情，而且他绝对拒绝手工编写脚本，因为有非常好的工具可以不用编码就完成。我注意到，将他的更改复制到实际脚本中往往会因此而延迟一点

---

您对这种方式与另一种方式的优缺点有何看法？我是否过于死板/老派地坚持手工编写模式脚本，还是他过于依赖第三方工具并在编写过程中失去了一些东西？

我发现编写脚本和使用SQLMS一样快。您仍然必须在SQL中键入名称MS，并且从键盘和鼠标移动所花费的时间也可以用来编写合适的脚本。

由于我通常在架构设计期间与同事协作，我倾向于使用GUI工具设计架构，因为在您面前的表的图表中更容易讨论它。然后我生成脚本，并小心地进行选择选择我希望避免在导出后进行手动更改的确切选项。

我认为在决定这两种方法的相对优点时，可能会考虑以下因素：

• 架构更改的频率
• 需要将更改传播到其他模式（测试、用户接受、生产、客户机*n等）的频率
• 模式在不同开发分支之间的变化程度
• 您的各种更改可以提前安排的广为人知程度
• 是否可以在架构之间生成SQL“diff”脚本

总的来说，我倾向于为每一个变更（或“迁移”）使用一个脚本。它允许我在优先级发生变化时对变更发布重新排序

---

仅仅因为你可以用图形工具创建表并不一定意味着你应该这样做。

你们两个几乎都在使用两组代码。一致性似乎是这些决策类型的关键因素。在你的情况下，如果你创建脚本，你的老板会使用gui添加一个字段，你如何保持同步？你不能使用script在不编辑表格的情况下重建表格（可能出错）

---

也许他应该让你按照GUI创建脚本的方式来设置脚本的格式，这只是开玩笑。

我总是自己编写脚本，因为向导有时不会以我喜欢的方式编写脚本，而且会给默认值起一个古怪的名字

---

如果你被解雇了，你必须去面试，面试时他们会让你在白板上写DDL脚本，你自己编写脚本也很好。我想你应该把它翻过来………

我也是这样工作的，无论是在我自己（或我自己的项目）工作时，还是在为客户（与其他开发人员）工作时。当我们快速确定范围时，我使用GUI工具，然后在事情形成后使用脚本。从那时起，由于版本控制和可复制性等原因，其他一切都使用脚本：-）嘿，“我的首席开发人员”，我指的是我雇佣的高级开发人员。我想我用词不当；我实际上是首席开发人员，他是我的高级开发人员，也在和我一起做这个项目。我们也有一个初级和中级开发人员，但他们只是做他们被告知的事情。建议他发布他的方法的基本原理，看看他得到了什么回应。