在部署时将大量数据存入SQL Server（Express）数据库

对于我工作过的大多数数据库支持的项目，在部署项目之前需要“启动”或testing数据到数据库中。启动数据的示例：列出世界上所有国家的表格或列出将用于填充调色板的一堆颜色的表格。

我一直在使用一个系统，我所有的启动数据存储在一个Excel电子表格（每个工作表一个表），然后我有一个在SQL中的实用程序脚本（1）创build数据库，（2）创build模式，（ 3）创build表（包括主键和外键），（4）作为链接服务器连接到电子表格，以及（5）将所有数据插入到表格中。

我最喜欢这个系统。我发现在Excel中布置列，使用简单的查找函数validation外键关系，执行连接操作，从Web表格或其他电子表格中复制数据等是非常容易的。该系统的一个主要缺点是需要同步任何时候我改变一个表格定义的时候，

我已经通过一些教程来学习新的.NET技术或devise模式，我注意到这些通常涉及使用Visual Studio来创build数据库和添加表（而不是脚本），并且数据通常使用内置的devise师。这让我想知道，如果我做这件事的方式不是最有效或可维护的。

问题

一般来说，你觉得最好是通过脚本或GUIdevise器（如SSMSE或Visual Studio）来构build整个数据库吗？
你推荐什么方法来填充启动或testing数据的数据库，为什么？

澄清

从目前的答案来看，我想我应该澄清一些事情。假设我有大量的数据（数百或数千行）需要find数据库。这些数据可以来自不同的地方，比如文本文件，电子表格，networking表格等等。我已经收到了一些使用INSERT语句编写脚本的build议，但是当您谈论大量数据？

这导致我…

新的问题

你将如何编写一个SQL脚本来获取该页面上的国家数据并将其插入到数据库中？

有了Excel，我只需将表格复制/粘贴到工作表中，然后运行我的实用程序脚本，基本上就可以完成了。
如果你后来意识到你需要一个新的专栏，CapitalCity？

使用Excel，我可以从这个页面获取这些信息，将其粘贴到Excel中，通过快速的文本到列的操作，我可以获得所需格式的数据。

老实说，我没有写这个问题来辩护Excel是最好的方式，或者甚至是将数据存入数据库的好方法，但是到目前为止，答案似乎并没有解决我主要关心的问题 – 如何获取所有这些数据进入你的数据库。手动编写含有数百个INSERT语句的脚本将非常耗时且容易出错。不知何故，这个脚本需要机器生成 ，但是如何？

我认为你现在的stream程对于初始数据的种子数据库来说没问题。它很简单，易于维护，并为您工作。如果你有足够的约束有一个好的数据库devise，那么你如何种子初始数据并不重要。你可以使用一个中间工具来生成脚本，但为什么要麻烦？

SSIS有一个陡峭的学习曲线，不能很好地与源代码pipe理（不可能知道什么版本之间的变化），是非常挑剔从Excel的types转换。还有一个问题，它提前读取多less行以确定数据types – 如果第一个x行包含以文本forms存储的数字，则会遇到很大的麻烦。

1）我更喜欢使用脚本有几个原因。

•脚本很容易修改，而且，当我准备将应用程序部署到生产环境时，我已经编写了脚本，以便全部设置。

•如果我需要将数据库部署到不同的平台（如Oracle或MySQL），那么很容易对目标数据库上的脚本进行较小的修改。

•使用脚本，我不依赖像Visual Studio这样的工具来构build和维护数据库。

2）我喜欢使用脚本的老式插入语句。同样，在部署时脚本是你最好的朋友。在我们的商店里，当我们部署我们的应用程序时，我们必须准备好供DBA运行的脚本，这就是他们所期望的。

我发现脚本很简单，容易维护，而且在创build数据库和加载数据时，它们是“最不共同的部分”。至less，我的意思是，大多数人（即DBA，你店里的其他人可能没有视觉工作室）将能够毫无困难地使用它们。

另一个对于脚本来说很重要的事情是，它强制你学习SQL和更具体的DDL（数据定义语言）。虽然手持GUI的工具很好，但是没有什么可以花时间学习SQL和DDL的。我发现这些技能几乎在任何商店都是非常宝贵的。

坦率地说，我觉得在这里使用Excel的概念有点吓人。它显然是有效的 ，但它创build了一个特别的数据源的依赖，直到很晚才解决。最后一件事情就是疯狂地部署一个数据库，发现Excel文件被损坏，甚至完全丢失。我认为这个问题的严重程度会随着风险承受能力而变化，但是我会积极地寻求从等式中删除Excel，或者至less把它作为一个永久性的东西去除。

我总是使用脚本来创build数据库，因为脚本是可移植且可重复的 – 您可以使用（几乎）相同的脚本来创build开发数据库，质量保证数据库，UAT数据库和生产数据库。出于这个原因，使用脚本修改现有数据库同样重要。

我也经常使用脚本来创build引导数据（AKA启动数据），这里有一个非常重要的原因：之后通常会有更多的脚本。或者至less应该有。 Bootstrap数据几乎总是只读的，因此，您应该将其放在只读文件组上，以提高性能并防止意外更改。所以你通常需要首先编写数据脚本，然后使文件组为只读。

然而，在更哲学的层面上，如果数据库需要启动数据才能正常工作 – 而且大多数情况下是这样 – 那么你真的应该把它看作是数据定义本身的元数据的一部分。出于这个原因，我认为不应该在任何地方定义数据，而是使用相同的脚本或一组脚本来创build数据库本身。

testing数据有点不一样，但以我的经验来看，您通常会尝试以某种方式自动生成数据，这使得使用脚本变得更加重要。您不希望为了testing目的而手动维护一个包含数百万行的特定数据库。

如果您的问题是testing或启动数据来自外部来源 – 网页，CSV文件等 – 那么我会用一个实际的“configuration数据库”来处理这个问题。这样，您不必像在Excel中一样validationVLOOKUPS的引用，您可以实际执行它们。

使用SQL Server Integration Services（以前称为DTS）将外部数据从CSV，Excel或任何地方拖到configuration数据库中 – 如果需要定期刷新数据，则可以保存SSIS包，使其仅仅是一对的点击次数。
如果您需要使用Excel作为中介，即格式化或重构网页中的某些数据，那没问题，但重要的事情是IMO尽快将其从Excel中移出 ，而configuration数据库的SSIS是这样做的优秀可重复的方法。
当准备将数据从configuration数据库迁移到应用程序数据库时，可以使用SQL Server Management Studio为数据生成脚本（如果您还不知道的话 – 右键单击数据库时，任务“，”生成脚本“以及在”脚本选项“中打开”脚本数据“）。如果你真的是硬核，你实际上可以脚本化脚本过程，但是我发现这通常不到一分钟。

这可能听起来像是一个很大的开销，但是实际上这个努力是微不足道的。你build立你的configuration数据库一次，创build一个SSIS包一次，刷新configuration数据可能每隔几个月或者可能永远不会（这是你已经做的部分，这部分将变得更less的工作）。一旦这个“设置”完成，那么生成脚本真的只需要几分钟，然后就可以在主数据库的所有副本上使用了。

由于我使用了一个对象关系映射器（Hibernate，也有一个.NET版本），我更喜欢用我的编程语言来生成这样的数据。然后，ORM负责将事情写入数据库。我不必担心要更改数据中的列名，因为我需要修改映射。如果涉及到重构，它通常也会负责启动/testing数据。

Excel是这个过程中不必要的组成部分。

脚本当前版本的数据库组件，您要重用，并将脚本添加到您的源代码pipe理系统。当将来需要进行更改时，可以修改数据库中的实体并重新生成脚本，也可以修改脚本并重新生成数据库。

避免混合使用Visual Studio的数据库devise器和Excel，因为它们只会增加复杂性。脚本和SQL Management Studio是你的朋友。