设计问题ASP.NET C＃

Question

我正在一个网站上工作，在该网站上我具有许多查询值，例如城市，州，国家/地区，汽车制造商，车型等。 这些值的ID和Description分别有两个字段。 现在我有一个问题，我应该将它们保留在一个表中，并保留某种区分它们的TypeId类型的字段，还是应该保留在不同的表中。

我的Dataprovider类也将如何，目前我正在考虑拥有一个可以提供所有数据的类。 但是，我觉得此类中有很多方法。

欢迎提出建议。

关于Parminder

Answer 1

相信我，是时候有人说：“嘿，我们可以为城市增加经度/纬度吗？”您会踢自己，因为这些属性对汽车品牌和型号毫无意义。

物理上将不相关，不相交的实体分开实际上不会出错。 因此，我建议使用其他表格。

Answer 2

始终将查找放在自己的表中，以便您可以在相关表上使用有意义的外键以实现关系完整性（即“客户”表中的“国家/地区” ID引用“国家/地区”表中的“国家/地区”）。

您的查找架构也可能在每个实体的基础上与标准ID /描述有所不同，因此“一刀切”就不是最好的开始方式。

另外，每次查找都只有一个存储库/数据提供程序，不要将它们全部混入一个大类中，因为那样会变得笨拙和不可靠。

Answer 3

我已经看到它同时完成了两种工作，但是就可发现性而言，我更喜欢为每个数据单独使用一个表。 维护多个表并不难，并且当您决定需要向其中一个项目添加一两列时，事情变得容易得多。

Answer 4

我希望您将它们放在单独的表中，以便于区分。

至于dataprovider类，我建议您使用ORM，而不要决定如何编写dataprovider类。

Answer 5

确实取决于您是否要出售产品，我会说是的，将它们放在一张桌子中，并具有某种TypeID来区分产品类型。 例如，如果您要出售商品，则TypeID可以是Automotive，Education等。

但是，如果您要处理用于特定目的的不同实体，而每个实体之间并没有真正的联系，那么分离是不错的选择。 我们需要更多信息来帮助您：)。

Dataprovider可以是一类，即您的数据访问层，并且您可以有很多方法都没关系。 那是很正常的。

Answer 6

城市，州，国家似乎是不同的实体。

因此最好将这些详细信息保留为单独的主表。

如果存在任何关系，则使用外键将它们关联。

如果将要进行任何更改或更新，这将减少将来的开销，并且如果这些开销都在一个表中，那么还将减少对数据库的负载。

编写一个单独的DBProvider来执行SP，即席查询

并且还创建了单独的BusinessModel来表示每个表，这些表就与DBProvider和客户端的前端进行交互。

那应该是好的，完美的设计策略。

Answer 7

这取决于这些实体的方案和域。 可以说在设计时，如果您不知道要使用的实体类型，那么TypeId方法会更好，这样，当添加新类型时，您不必为其创建另一个实体。 但是，如果在设计时确定了实体域（您将拥有哪些实体），则将它们保存在单独的表中，以便可以更有效地优化搜索。

但是，请考虑是否需要更新实体的属性（添加，编辑，删除等），因此，如果将它们保留在一个表中，则更新可能会影响所有其他属性。 如果以后需要与表添加关系，该怎么办？ 所有不相关的实体也可以继承关系。

Answer 8

关于您的Dataprovider类-如果它太大，则可以将其视为代码异味 ，通常认为这是一种不好的做法。 确定多大太大有点主观。

从文章：

大班：已经变得太大的班，请看上帝的对象 。

Answer 9

如果您认为随着时间的推移，不同类型的数据将获得不同的属性，则将它们分别放在自己的表中。 但是，如果您认为它们始终都将仅作为Id和Description保留，那么为简单起见，请将它们全部与TypeId放在同一表中。

我同意其他建议使用第三方数据访问或OR / M组件的答案，例如LINQ-to-SQL，NHibernate，SubSonic，LLBLGen Pro等。