假设您有一个管理某个库并拥有自己的数据的应用。数据必须存储在某个地方。数据应该存储在哪里？
我的意思是：您打算在客户端机器上安装 MySQL 还是 SQL Server？这似乎是用大炮射击苍蝇。另一种方法是使用 SQLite 之类的东西，它不需要运行服务器，但使用它很痛苦（只是我个人的喜好）。也有XML，不过用SQLite更痛苦。
您将数据保存在哪里？安装 SQL 服务器？使用自己的数据格式？还有其他方法吗？
【问题讨论】：
标签： .net database winforms serialization
我最初将我的想法作为评论发布，因为我不确定是否提供了足够的信息来说明您要存储的数据的类型、数量和未来需求。更不用说我不是一个数据库专家，所以有人可能会接受我的建议，并使用你最终最喜欢设计和维护的任何东西。
话虽如此，我永远不会梦想使用任何类型的数据库来存储简单的客户数据。复杂性和开销似乎是不合理的，特别是当 SQL 数据库的优势几乎完全丧失在应用程序类型上时。如果您的数据集可以完全加载到 RAM 中，或者从保存的文件中按需加载数据对性能的影响可以忽略不计，那么您最好探索其他选项。我会考虑存储到客户端数据库中的唯一情况是，如果绝对需要更快的数据检索时间，而这无法通过更智能/更高效的代码设计来实现，或者应用程序是否可以从某些东西的索引和搜索功能中受益就像 MySQL 可以提供的一样。
相反，我发现我自然倾向于在树中构建数据。对于速度不是最重要的应用程序，或者我没有处理特别复杂的数据类型，我会选择XML serialization。不仅查询和修改 XML 文件比具有相当小的数据集的数据库快得多，标准的 Microsoft DOM 库还使处理 XML 数据源变得非常简单。对类的实例进行序列化是内置在 .NET Framework 中的，这让我希望在几年前我花所有时间编写数据存储和检索代码时就拥有这个功能。 XML 的其他优点是它几乎可以消除应用程序未来版本的版本控制问题，即使添加了功能，并且可以在必要时手动查看/编辑数据文件。可移植性也很好，允许其他程序轻松读取和导入您的数据，如果发生这种情况，您不会冒因多个同时读取/写入而损坏数据库的风险。最后，值得一提的是，我发现将自定义数据集序列化为 XML 文件在调试中非常有用：我可以保存状态，然后打开 XML 文件以查看到底存储了哪些数据。
在 XML 不太符合要求的应用程序中（通常是因为我试图欺骗并保留加载到内存中的数据管理类的状态），我选择binary serialization。如果您正在寻找更快的访问时间并且数据/数据结构的复杂性不适合 XML 的分层格式，那么这也是 XML 的一个很好的替代方案。这也内置于 .NET Framework 中，而且可能比 XML 序列化更容易设置（如果可能的话）。这种类型的数据存储的两个主要缺点是几乎不可能实现无缝版本控制，并且您的数据以用户或其他应用程序无法访问的专有格式存储。如果版本控制不是您的应用程序的问题，那么这里可能没什么好担心的。但是，在我编写的几个数据管理应用程序中，我在返回并添加功能后没有采取预防措施来读取在以前版本中创建的数据文件，因此我被咬了。
无论是二进制还是 XML 序列化，我都喜欢作为开发人员为文档提供多个离散文件的灵活性。我可以在 shell 中将某些文件扩展名与我的应用程序相关联，用户体验对于备份等事情变得更加直观，并且用户可以轻松地与其他拥有我的应用程序的人交换在我的应用程序中创建的文件。您认为 Microsoft Word 是如何变得如此受欢迎的？
【讨论】：
csv 文件？它有缺点，但您不需要使用库来解析它。而且速度很快。
【讨论】：
如果数据真的很简单，请使用Serialization
【讨论】：
我会投票支持可以保存在用户主目录中的 SQLite 数据库。
【讨论】：
我会选择db4o 或 SQL Server Compact Edition。
【讨论】：
如果存储的数据相当简单，我可能会选择 XML。
否则，这将是 SQL Server Compact Edition 的完美用途。
【讨论】：
我过去曾使用 XML 来管理简单的数据结构...效果很好。
您还可以使用设置存储数据
http://msdn.microsoft.com/en-us/library/aa730869(VS.80).aspx
【讨论】：