如果我们必须存储公司的可用职位(即经理,团队负责人等).存储它的最佳做法是什么？我有两个评论意见......"当然,欢迎你的"
将其存储为包含列ID和名称的DB表,并使用查询和连接处理它.
将其存储为枚举并忘记数据库表.
在我看来,如果我有更改项目,我会选择第一个解决方案.因此,我不会将这些选项硬编码为Enum.
如果我毫不怀疑数据不会改变(例如,性别:男性,女性),我可以选择Enum解决方案.
注意:我用英语编码,UI文化可能是阿拉伯语.如果我将使用Enum解决方案,我将在表示层中对基于文化的字符串进行硬编码,从最佳实践角度来看是否可以!
我想知道你的意见,如果我的想法符合最推荐的"最佳实践"？
通常,您应该只使用枚举,其中有一组明确的项目不会更改,例如原色或大陆名称.否则,具有适当实现的外键的查找表几乎总是最佳选择.
查找表选项可能存在差异,您可能会为简单的ID /值关系提供大量查找表.域/查找表对可以显着减少所需的表的数量,尽管具有一些额外的编码复杂性.在这种情况下,您将拥有一个域表
DomainID int identity Domain varchar(255)
和一个键/值表
DomainID int ID int identity Value varchar(255)
因此,对应于您将使用的每个查找表的域表中添加一行,并将所有(键 - 域)/值对添加到值表中.除了简化数据库结构之外,这种方法还具有可以在应用程序代码中动态创建"查找表"的优点,这在某些应用程序中非常有用.
选项1:将其存储为具有列ID和名称的DB表,并使用查询和连接处理它是您应该做的最小值.
从" 你应该避免的五个简单的数据库设计错误 ":
虽然应用程序强制完整性有时受到开发人员的青睐,但DBMS仍然必须仍然是所有完整性的集中执行者.
建议的最佳实践是实现数据库,就好像它对用户界面一无所知.也就是说,数据库应该执行与数据有关的所有规则; 在这种情况下,数据库应该强制执行适当的值.要枚举适当的值,通常可以使用每种查找值的查找表.很多时候,应用程序来来往往,但数据库仍然存在并被重用.
如果要在应用程序中强制执行枚举,您当然可以这样做,但无论您做什么,请确保数据库作为数据库完成其工作并保持数据的完整性.如果麻烦,请经历麻烦; 你正在奠定基础.在" 数据库设计和比萨斜塔 "中,作者强调为什么在数据库中正确地奠定基础非常重要.
我希望这有帮助.
我倾向于使用数据库选项,因为这样可以轻松查询有意义的数据(即名称而不是ID).
如果我相信这些值不会改变,那么我将在应用程序中枚举它们,因为当你不必记住项目的ID并使代码更具可读性时,它使开发更容易.
这种方法允许我选择是否在查询中包含查找表.例如,我将它包含在报表查询中,我想显示查找值但在我的应用程序中加载数据时可能不包括它,如果我可以从枚举中推断它.
显然,如果值可能会发生变化或修改,则可能无法进行枚举.
只有你可以判断UI文化的影响,我100%肯定我的用户的文化,所以不必太担心它:).
我总是选择数据库选项，因为它具有多个优点，主要优点之一是您可以更改查找列表中项目的名称/说明，而无需更改任何代码。还同意拥有一个表而不是很多小表，这样您就可以编写一个例程来从数据库中检索值，从而降低了维护成本。拥有一个常规程序意味着您可以投入更多的精力来使其表现良好。
除了上述Cruachan的答复之外，如果您具有父子关系，而没有父行的行描述了域，则可以不用一个表。属于域的所有记录都以域行作为其父级。
ID int autonumber -- integer primary key for performance DomainID int -- null for domains Name varchar(100) -- Name of the item Description varchar(255)
因此，例如货币列表可以包含：
ID DomainID Name Description 100 NULL ISO Currencies List of ISO Currency codes 101 100 BHD Bahrain Dinar 102 100 GBP British Pound 103 100 EUR Euro 104 100 USD US Dollar
京公网安备 11010802040832号 | 京ICP备19059560号-6 