我可以简单地使用我已经...的结构吗?
或者
我要创建一个包含必填字段的数据库...
我认为这是你问题的症结所在。
从数据库开始
对我来说,在构建使用后端数据库的应用程序时,实体关系图非常重要。我在这里为您找到了一个不错的小教程:http: //www.sum-it.nl/cursus/dbdesign/english/index.php3但您可以轻松找到适合您学习风格的教程。关键是您正在尝试以您的应用程序可以以某种方式捕获的方式对问题域(需要您的应用程序的现实世界)进行建模。一旦你有了相关表的 ER 图,就更容易弄清楚细节。使用 SQL Management Studio for SQL Server 2008(Express 版),您可以创建一些基本表并在此处构建 ER 图并让它为您生成关系。然后,您可以在闲暇时检查用于实现该目标的 SQL 并进行相应的改进。
就个人而言,我总是从检查问题域开始,然后构建 ER 图,然后构建数据库。当我有理由确信数据库反映了问题域时,我开始构建 C# 应用程序。
从您的 C# 应用程序开始
然而,真正重要的是你以一种有意义且有效的方式对现实世界进行建模。在您的情况下,您已经在 C# 中创建的结构中有一个起点,您可以使用它们为您提供构建 ER 图的起点。如果您发现让 C# 应用程序运行起来更容易,然后构建一个反映它的数据库,那应该没问题。也许您已经有一种方法可以帮助您有效地捕获问题域。无论您做什么,这都是一个迭代过程:构建 C# 代码可能会揭示底层数据库设计的问题,反之亦然。
图表 - ER 还是 UML?
我个人确信整个业务是如此复杂,以至于您确实需要一些图表。
- 要可视化您的数据库,请使用 ER 图
- 使用 UML 类图可视化您的 C# 应用程序
当你走向一个工作的应用程序时,你会看到这两个图是如何开始匹配的,或者至少是非常接近地反映了彼此。在这两种情况下,(实体或类)在查询数据库时了解对象之间的关系非常重要,因为了解表之间的关系至关重要(尤其是使用一对多关系来解决复杂的多对多关系)和在查询中连接表的各种技术(INNER 或 OUTER 连接等)无论您的 C# 应用程序多么聪明,在某些时候您都需要至少了解 SQL 语言的一些复杂性——如果你可以参考ER图。
在哪里存放?
令我困扰的是,通常我会将我的 c# 对象存储在字典或列表中,我会直接从数据库中检索吗?
在数据库中,毫无疑问。名为 Family 的 AC# 类将有一个属性 FamilyName,例如,内置一个 setter 方法。如果您发现拼写错误并想更改名称,setter 方法将打开与数据库的连接,使用指定家族名称(可能还有家族 id)作为参数,并相应地更新基础字段。检索数据将涉及运行 SELECT 查询等。
结论
做一些关于如何检查问题域、创建实体关系图并基于该图构建一组相关表的教程。我相信通过这种方式,您会发现跟踪您为与后端数据库通信而构建的 C# 类会容易得多。
以下是家庭及其成员的简单 ER 图示例:
一开始你可能会认为成员和家庭可能在一个表中,但随后你发现这会产生很多重复,因此你将其分离为具有一对多关系的家庭和成员表,但随后你意识到,例如,通过婚姻,人们可以属于多个家庭,您需要建立多对多的关系。我认为 ER 图是解决这种复杂性的最佳场所。