抱歉,是否有人在其他地方问过这个问题,但我在任何地方都找不到清晰的答案。
我决定开始多学习使用关系数据库,即SQL。这是一个初学者的主要问题,但可能对于上手来说是必不可少的。
基本上,我对如何利用SQL(或其他)的最佳做法感到困惑。在大学里,我已经访问了用于移动应用程序之类的数据库(使用JSON字符串),但是我从来没有亲自设计和构建过数据库,因为我的导师制作了上述数据库供我们访问。
可以说我有一个C#应用程序来保存家谱信息(即家庭及其成员),我想将每个人存储在数据库中。我是否会简单地使用已经拥有的结构,但将其保存到数据库中的字段而不是xml或文本文档中?还是以其他方式工作,即我是否创建具有必填字段的数据库,然后仅从aC#应用程序中的数据库中检索该数据并按我希望的方式操作数据,因此该应用程序将完全不同(因此C#应用程序基本上真的不保存/存储任何数据,而只能用于数据库提供的数据吗?
令我困扰的是,通常我将C#对象存储在字典或列表中的地方,我会直接从数据库中检索吗?还是从中检索数据并将其存储到正常结构中并从那里进行工作(当然,这样做会击败从数据库中快速搜索的观点)?
我可能对此略有思考。希望这是有道理的。提前致谢
最佳答案
或者
我认为这是您问题的症结所在。
从数据库开始
对我来说,在构建使用后端数据库的应用程序时,实体关系图非常关键。我在这里为您找到了一个不错的小教程:http://www.sum-it.nl/cursus/dbdesign/english/index.php3,但是您可以轻松地找到一个适合您的学习风格的教程。关键点在于,您正在尝试以某种方式可以捕获应用程序的方式对问题域(需要应用程序的现实世界)进行建模。一旦有了相关表的E-R图,就可以更轻松地弄清细节。使用用于SQL Server 2008的SQL Management Studio(快速版),您可以创建一些基本表并在那里建立E-R图,并为您生成关系。然后,您可以在闲暇时检查用于实现该目标的SQL并相应地进行优化。
就个人而言,我总是从检查问题域开始,然后构建E-R图,然后构建数据库。当我相当有信心数据库可以反射(reflect)问题域时,我便开始构建C#应用程序。
从您的C#应用程序开始
但是,真正重要的是您以一种有意义且有效的方式对现实世界进行建模。在您的情况下,您已经在C#中创建的结构中有了一个起点,并且可以使用它们为您构建E-R图提供一个起点。如果发现使C#应用程序运行起来更容易,然后构建一个反射(reflect)它的数据库,那应该没问题。也许您已经有一种方法可以帮助您有效地捕获问题域。无论您做什么,都是一个反复的过程:构建C#代码可能会揭示底层数据库设计的问题,反之亦然。
图表-E-R还是UML?
我个人坚信整个业务是如此复杂,以至于您确实需要一些图表。
当您进入正在运行的应用程序时,您将看到这两个图如何开始匹配或至少紧密地反射(reflect)了其他形式。在这两种情况下,(实体或类)了解对象之间的关系在查询数据库时都非常重要,因为了解表之间的关系(尤其是使用一对多关系来解决复杂的多对多关系尤其重要)关系)和用于在查询中联接表的各种技术(INNER或OUTER联接等),无论您的C#应用程序多么聪明,您都将至少需要了解SQL语言的某些复杂性,如果您可以引用ER图。
存放在哪里?
在数据库中,毫无疑问。名为Family的AC#类具有内置的setter方法的FamilyName属性。如果发现拼写错误并想要更改名称,则setter方法将打开与数据库的连接,并使用指定家族名称(可能还有家族ID)作为参数,并相应地更新基础字段。检索数据将涉及运行SELECT查询等。
结论
做一些有关如何检查问题域,创建实体关系图并基于该图构建一组相关表的教程。我坚信,通过这种方式,您会发现跟踪与后端数据库进行通信而构建的C#类要容易得多。
这是一个针对家庭及其成员的简单E-R图的示例:
首先,您可能会认为成员和家庭可能在一个表中,但是随后发现创建了很多重复项,因此您以一对多的关系将其分离为家庭表和成员表,但随后您意识到,例如,通过婚姻,人们可以属于多个家庭,您需要建立多对多关系。我认为E-R图是解决这种复杂性的最佳位置。