数据库设计 - 只读表的 LKP 模式？最佳实践？ [关闭]答案

【问题标题】：Database Design - LKP Schemas for Read-Only Tables? Best Practices? [closed]数据库设计 - 只读表的 LKP 模式？最佳实践？ [关闭]
【发布时间】：2016-04-02 08:32:50
【问题描述】：

我对 Microsoft 堆栈中的编码相对较新，我在新工作场所的一些做法与我以前见过的不同。即，我见过一种做法，其中只读表（应用程序不能插入/编辑/删除的表）以“lkp.EmailType”、“lkp.Gender”、“lkp.Prefix”为前缀"等等。

但是，当我开始使用 Entity Framework 和 Database-First 方法开发一些 MVC5 应用程序时 - 在调试我的代码时，我注意到它尝试将表名复数并更改架构 - 所以“lkp.Gender”查询出现关于“dbo.Genders”的选择语句。在研究了复数功能之后，似乎最佳实践倾向于表名复数，所以我继续为这个应用程序做了这个（这是一个新应用程序，但我们使用与以前的数据库结构类似的数据库结构，但不必保留一样）。

我需要做的最后一件事是将这些表模式更改为“dbo”而不是“lkp”。在与其他项目的一些同事交谈时，他们发现虽然只读查找表可能在他们的项目中使用 DBO 模式，但他们可能会以不同的方式命名它，例如“dbo.LkpGenders”等。

这需要一些工作来消除使用这些 LKP 表等对其他表的限制，我想在我为这个改变付出太多努力之前询问社区，这是否是一个好主意，并花时间要么使 LKP 表工作或取消它们。

简而言之 - 将 LKP 模式用于只读表是一种古老的做法，还是这仍然是一个好主意，而我只是在其他工作场所和项目中“错误”地做这件事？作为一个额外的好处，为什么 MVC5/EF 可能会在创建 EDMX 罚款的东西上使用 DBO 模式的原因很高兴知道。我应该为这种只读查找数据使用命名约定、数据库视图还是 LKP 模式？

【问题讨论】：

改变了我的搜索，我确实找到了一些关于这个主题的讨论——尽管我仍然想听听其他专家关于这个主题的意见。 sqlservercentral.com/Forums/Topic1664238-373-1.aspx 看来这里的共识是“它解决了什么问题？”有一个 LKP 模式，并且只是取消这种做法。
我目前不使用此约定，但认为它可能非常有用。我通常在 SSDT 和源代码控制的部署后脚本中查找数据。使用此约定并在内部公开它可以非常清楚地表明不应在表本身中手动编辑数据，以避免在下次发布时覆盖更改。
一组只读表将具有与一组更新表不同的备份和重组计划（或没有备份或重组计划）。这就是将只读表放在单独的架构/数据库中的原因之一。
这里有两个问题：从 DB 角度来看的最佳实践，以及从 EF 角度来看的最佳实践。从数据库方面来看，这是可能是最佳实践，但 EF 将无法利用这样的表，所以什么是最佳实践和不是最佳实践变得没有实际意义。但是，有一些方法可以让 EF 将实体视为只读，即使它没有在数据库级别强制执行：stackoverflow.com/questions/10437058/…

标签： sql-server database entity-framework database-design asp.net-mvc-5

【解决方案1】：

一些想法：

我喜欢复数表名。一行可以包含一个实体；一个表可以包含许多实体。但是，命名约定应该是指导方针，而不是刻在石头上的规则。在所有情况下，任何一条规则都不可能是最佳选择。所以请允许一些灵活性。

我对最后一个警告的唯一例外是对表和视图进行相同的命名。也就是说，数据库对象Employees 可以是表或视图。使用它的应用程序不知道它是（或关心）哪一个，并且数据库开发人员可以很快找到（如果它是相关的）。绝对没有理由按名称区分表和视图，并且有许多充分的理由将表和视图抽象为“数据源”。

在自己的数据库/架构中保留重要表的做法是一种有效的做法。这些表（只读）在组织上将它们组合在一起，因此在物理上将它们组合在一起是有意义的。问题可能出在存在其他此类属性时：只读员工数据、只读财务数据等。如果员工和财务数据也被隔离到它们自己的数据库/模式中，这是更重要的属性，它将决定哪里它们位于：只读或员工/财务？

在您的特定情况下，我认为“只读”不足以评估隔离。首先，只读不是一个普遍的约束——必须有人能够维护数据。所以它是“只读here，可写there”。其次，几乎任何数据分组都可以包含一些通常是只读的数据。仅仅因为它们都是只读的，就在同一个地方收集只对应用程序 X 有用的只读数据和只对应用程序 Y 有用的只读数据是否有意义？假设应用程序 X 现在需要查看（当然是只读的）应用程序 Y 的一些数据来实现新功能？该数据是否会重新定位到只读数据库？

更好的选择是将仅 X 的数据放置在其自己的位置，将仅 Y 的数据放置在其自己的位置等等。公司范围的数据将进入 dbo。每个位置可能对相同的公共数据有不同的要求——一些是只读的，另一些是可写的。这些不同的要求可以通过本地视图来实现。视图上的“什么都不做”触发器将使其完全只读，但具有工作触发器的视图将使其与基础表无法区分。每个应用程序将在其自己的空间中拥有自己的视图，并酌情使用触发器。因此，每个人都看到相同的数据，但只有一个人可以操作该数据。

通过本地视图从另一个位置访问通用 (dbo) 数据或共享数据的另一个优点是，每个应用程序，即使它们正在查看相同的数据，也可能需要不同格式和/或不同字段名称的数据。视图允许您以应用程序希望看到的方式向每个应用程序提供数据。

这也可以大大提高物理数据的可维护性。如果需要对表进行规范化或非规范化，或者完全重命名、添加或删除字段，请继续执行。只需重写视图以最小化（如果不能完全消除）使其返回应用程序的差异。应用程序代码可能根本不需要更改。怎么这么酷？

【讨论】：