如果这个问题已经被问过了，我很抱歉，但我无法在任何地方找到清晰的答案。
我决定开始学习如何更好地使用关系型数据库，特别是SQL。这是一个初学者的问题，但对于入门来说可能至关重要。
我有些困惑，关于如何最好地利用SQL（或其他）。在大学里，我使用JSON字符串访问数据库（用于移动应用程序等），但我从未设计和构建过自己的数据库，因为我的导师为我们提供了所需的数据库。
假设我有一个C#应用程序，保存家谱信息（即家庭及其成员），我想将每个人存储在数据库中。我是否可以简单地使用已有的结构，但将其保存到数据库的字段中，而不是XML或文本文件？还是反过来，我需要创建一个具有所需字段的数据库，然后只需从C#应用程序中检索此数据，并随意操作数据，使应用程序完全不同（因此C#应用程序基本上不会保存/存储任何数据，而只是从数据库中获取数据）？
令我困扰的是，通常情况下，我会将C#对象存储在字典或列表中，那么我是否应该直接从数据库检索？还是从数据库中检索并将数据存储到普通结构中，然后从那里进行操作（这肯定会破坏从数据库中快速搜索的目的）？
我可能有点过于思考了。希望这有意义。提前致谢。
我应该只使用我已经创建的结构来建立应用程序，或者要创建一个带有所需字段的数据库？我认为这是你问题的关键。
对我而言，在构建使用后端数据库的应用程序时，实体关系图非常重要。我在这里找到了一个相当不错的教程：http://www.sum-it.nl/cursus/dbdesign/english/index.php3，但你可以轻松找到适合你学习风格的教程。关键点是你正在尝试以某种方式捕捉问题领域（需要你的应用程序的那个真实世界），以便你的应用程序能够进行建模。一旦有了相关表的E-R图，就更容易理清细节。在SQL Server 2008（Express版本）中使用SQL Management Studio，您可以创建一些基本表并在那里构建E-R图，并让它为您生成关系。然后，你可以随意检查所用的SQL并进行细化。
就我个人而言，我总是从问题域入手，然后构建E-R图，再构建数据库。当我相信数据库反映了问题领域时，我开始构建C#应用程序。
但是，真正重要的是以有意义和有效的方式对现实世界进行建模。在你的情况下，你已经拥有了C#中创建的结构作为起点，可以使用它们作为起点来构建E-R图。如果你发现通过启动C#应用程序并构建反映它的数据库更容易，那也没问题。也许你已经有了一个帮助你有效捕捉问题领域的方法。无论你做什么，都是迭代的过程：构建C#代码可能会揭示底层数据库设计的问题，反之亦然。
我个人相信这整个业务如此复杂，以至于你真的需要一些图表。
当你朝着一个工作的应用程序前进时，你会看到这两个图表开始相匹配或至少相互反映得非常紧密。在这两种情况下（实体或类），了解对象之间的关系将在查询数据库时非常重要，因为理解表之间的关系至关重要（特别是使用1对多关系来解决复杂的多对多关系）以及连接表的各种技术在查询中（INNER或OUTER join等）。无论你的C#应用程序有多聪明，你在某个时候都需要至少了解一些SQL语言的复杂性-如果可以参考E-R图，那就更容易了。
不知道你的结构长什么样子或者你的数据库将如何设计，这很难回答。但是你应该能够使用现有的数据结构，只需从数据库中导入数据而不是XML文件即可。
研究一下Linq-to-XML，C#有一个强大的库与SQL交互。起初可能有点困惑，但一旦学会了就非常强大。
如果我没理解错的话，您也在询问是否应该从数据库中检索所有记录并将它们存储为集合中的对象，还是从数据库中检索选定的记录并使用数据集结果而不将其放置在特定结构中。
我倾向于从数据库中选择我想要的记录，然后将结果加载到我的特定类/结构中。这样，您可以将操作方法添加到持有记录结果的类中等等，而无需将数据集结果传递给每个方法。但是，当批量更新更有效时，您会发现自己一直在进行单个更新...如果这有意义的话。
看一下实体框架的代码优先。如果你的数据结构是应用程序中的类，那么有技巧可以使用它来从中创建数据库模式。至于数据，将其存储在数据库中，并用它填充列表和字典。或者用它填充个人家谱类别的列表。
