我对微软堆栈中的编码相对较新，而我新工作场所的一些实践与我之前看到的不同。也就是说，我已经看到了一种做法，其中只读表（应用程序无法插入/编辑/删除的表）以“lkp.EmailType”，“lkp.Gender”，“lkp.Prefix为前缀” “等等。
然而，当我开始使用Entity Framework和Database-First方法开发一些MVC5应用程序时 - 在调试我的代码时，我注意到它试图复数表名并更改架构 - 所以“lkp.Gender”查询接受关于“dbo.Genders”的选择声明。在查看复数功能之后，似乎最好的做法是倾向于复制表名，所以我继续为此应用程序做了这个（这是一个新的应用程序，但我们使用类似的DB结构，而不是先前的，但不必保持它一样）。
我需要做的最后一件事 - 将这些表模式更改为“dbo”而不是“lkp”。在与其他项目的同事交谈时，他们发现，虽然只读查找表可能会将DBO模式用于他们的项目，但他们可能会以不同的名称命名，例如“dbo.LkpGenders”等。
使用这些LKP表等删除对其他表的约束需要做一些工作，我想在我为这个改变付出太多努力之前先询问社区，如果它甚至是个好主意并且没有花时间使LKP表工作或取消它们。
简而言之 - 对于只读表使用LKP模式是一种古老的做法，还是这仍然是一个好主意，我只是在其他工作场所和项目中做了“错误”？作为一个额外的好处，推断为什么MVC5 / EF可能正在使用DBO模式创建一个EDMX精细的东西将是很好的知道。我是否应该为这种只读查找数据使用命名约定，DB视图或LKP模式？
答案 0 :(得分：1)
一些想法：
我喜欢多个表名。一行可以包含一个实体;一个表可以包含许多实体。但是，命名惯例应该是指导原则，而不是刻在石头上的规则。任何一条规则都不可能成为所有情况下的最佳选择。所以允许一些灵活性。
我最后一个警告的唯一例外是相同地命名表和视图。也就是说，数据库对象 Employees 可以是表或视图。使用它的应用程序不知道它是（或关心）哪个应用程序，数据库开发人员可以快速找到（如果它是相关的）。绝对没有理由按名称区分表和视图以及将表和视图抽象为数据源的许多充分理由＆＃34;。
将重要表保留在自己的数据库/模式中的做法是有效的。这些表（只读）有一些内容可以将它们组织在一起，因此将它们组合在一起是有意义的。当存在其他此类属性时，问题可能是：只读员工数据，只读财务数据等。如果员工和财务数据也被隔离到他们自己的数据库/模式中，这是更重要的属性，将决定在哪里他们位于：只读或员工/财务？
在您的特定情况下，我不认为＆＃34;只读＆＃34;足以对隔离进行评级。首先，只读不是通用约束 - 某人必须能够维护数据。所以它是＆＃34;只读这里，可写那里＆＃34;。其次，几乎任何数据分组都可以包含一些通常只读的数据。收集仅用于应用程序X的只读数据和仅用于同一位置的应用程序Y的只读数据是否有意义只是因为它们都是只读的？并且假设应用程序X现在需要查看（当然只读）一些应用程序Y的数据来实现新功能？该数据是否可以重新定位到只读数据库？
更好的选择是将仅X数据放在其自己的位置，将Y-only数据放在其自己的位置等等。公司范围内的数据将以dbo格式显示。每个位置对相同的公共数据可能有不同的要求 - 对某些人来说是只读的，对其他人来说是可写的。这些不同的要求可以通过本地观点来实现。什么都不做＆＃34;而不是＆＃34;视图上的触发器将使其完全只读，但具有工作触发器的视图将使其与基础表无法区分。每个应用程序在其自己的空间中都有自己的视图，并在适当时使用触发器因此每个人都看到相同的数据，但只有一个人可以操纵这些数据。
通过本地视图从另一个位置访问公共（dbo）数据或共享数据的另一个好处是每个应用程序，即使它们正在查看相同的数据，也可能需要不同格式和/或不同字段名称的数据。视图允许您按照应用程序想要的方式向每个应用程序提供数据。
这还可以极大地提高物理数据的可维护性。如果需要对表进行规范化或非规范化，或者对某个字段进行重命名，完全添加或删除，请继续执行。只需重写视图，即使不能完全消除使其返回应用程序的差异，也可以最小化。可能根本不需要更改应用程序代码。如何冷静？