Questions tagged «database-design»

数据库设计是指定数据库的结构以及逻辑方面的过程。数据库设计的目的是代表某种“话语世界”-事实的类型，业务规则和数据库要建模的其他要求。

6
推荐的用于标记或标记的SQL数据库设计[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引文回答。 4年前关闭。 改善这个问题 我听说过几种实现标记的方法。使用TagID和ItemID之间的映射表（对我来说有意义，但是可以缩放吗？），向ItemID添加固定数量的可能的TagID列（似乎是个坏主意），将标签保留在逗号分隔的文本列中（声音疯狂但可以工作）。我什至听说有人建议使用稀疏矩阵，但是标记名称又如何优雅地增长呢？ 我是否错过了标签的最佳做法？
6
关系数据库设计模式？[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 2个月前关闭。 改善这个问题 设计模式通常与面向对象的设计有关。 有用于创建和编程关系数据库的设计模式吗？ 当然，许多问题必须具有可重用的解决方案。 示例包括表设计，存储过程，触发器等的模式。 是否存在类似于martinfowler.com的此类模式的在线存储库？ 模式可以解决的问题示例： 存储分层数据（例如，具有类型的单个表与具有1：1密钥和差异的多个表...） 存储具有可变结构的数据（例如，通用列vs xml vs分隔列...） 对数据进行非规范化（如何在影响最小的情况下进行处理等）
4
什么是数据库范式，您可以举一些例子吗？[关闭]
按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意测验或进一步的讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 在关系数据库设计中，存在数据库规范化或简单规范化的概念，该概念是组织列（属性）和表（关系）以减少数据冗余并提高数据完整性的过程。（如Wikipedia所写）。 由于大多数文章都是技术性文章，因此较难理解，我要求有人根据有关1NF，2NF，3NF甚至3.5NF（Boyce-Codd）含义的示例，写一个更容易理解的解释。
3
关联的主要终点在实体框架中以1：1关系表示什么
public class Foo { public string FooId{get;set;} public Boo Boo{get;set;} } public class Boo { public string BooId{get;set;} public Foo Foo{get;set;} } 当我收到错误消息时，我正在尝试在Entity Framework中执行此操作： 无法确定类型'ConsoleApplication5.Boo'和'ConsoleApplication5.Foo'之间的关联的主要终点。必须使用关系流利的API或数据注释显式配置此关联的主要端。 我已经在StackOverflow上看到了有关此错误的解决方案的问题，但我想了解术语“主要目的”的含义。
30
外键怎么了？
我记得在播客014中听到乔尔·斯波尔斯基（Joel Spolsky）提到他几乎从未使用过外键（如果我没记错的话）。但是，对我来说，它们对于避免整个数据库中的重复和后续数据完整性问题至关重要。 人们为什么会有一些扎实的理由（避免按照堆栈溢出原则进行讨论）？ 编辑： “我还没有创建外键的理由，所以这可能是我真正设置外键的第一个理由。”
5
“防止保存需要重新创建表的更改”的负面影响
前言 我今天修改了SQL Server 2008中的一列，将数据类型从currency（18,0）更改为（19,2）。 我从SQL Server中收到错误消息“所做的更改要求删除并重新创建下表”。 在争夺答案之前，请阅读以下内容： 我已经知道在“ 工具”►“选项”►“设计器”►“表和数据库设计器”►取消选中 “防止保存需要重新创建表的更改” 框，这是一个选项。 ...所以不要回答！ 实际问题 我的实际问题是其他问题，如下所示： 这样做有没有负面影响/可能的弊端？ 取消选中此框后，实际上是否会自动删除并重新创建表？ 如果是这样，该表副本是否是源表的100％精确副本？
4
使用空列创建唯一约束
我有一个具有这种布局的表： CREATE TABLE Favorites ( FavoriteId uuid NOT NULL PRIMARY KEY, UserId uuid NOT NULL, RecipeId uuid NOT NULL, MenuId uuid ) 我想创建一个类似于以下的唯一约束： ALTER TABLE Favorites ADD CONSTRAINT Favorites_UniqueFavorite UNIQUE(UserId, MenuId, RecipeId); 但是，这将允许多行具有相同的(UserId, RecipeId)if MenuId IS NULL。我想允许NULL在MenuId存储不具有关联菜单中的最爱，但我只希望每个用户/食谱对这些行中最多只有一个。 到目前为止，我的想法是： 使用一些硬编码的UUID（例如全零）而不是null。 但是，MenuId每个用户的菜单都有FK约束，因此我不得不为每个用户创建一个特殊的“空”菜单，这很麻烦。 而是使用触发器检查是否存在空条目。 我认为这很麻烦，我喜欢尽可能避免触发事件。另外，我不信任他们以确保我的数据永远不会处于错误状态。 只需忘记它，然后检查中间件或插入函数中以前是否存在空条目，并且没有此约束。 我正在使用Postgres 9.0。 我有什么方法可以忽略吗？
11
初次数据库设计：我是否过度设计？[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引文回答。 2年前关闭。 改善这个问题 背景 我是CS大学一年级的学生，我做兼职工作是我父亲的小生意。我没有在现实世界中进行应用程序开发的经验。我用Python编写了脚本，用C编写了一些课程，但没有这样的东西。 我父亲的培训业务不多，目前所有课程都通过外部网络应用程序进行计划，记录和跟进。有导出/“报告”功能，但是它非常通用，我们需要特定的报告。我们无权访问实际数据库来运行查询。我被要求设置一个自定义报告系统。 我的想法是创建通用的CSV导出，并将其导入（可能是使用Python）（每天晚上）到办公室中托管的MySQL数据库中，从那里我可以运行所需的特定查询。我没有数据库方面的经验，但了解非常基础的知识。我已经阅读了一些有关数据库创建和常规表单的信息。 我们可能很快就会有国际客户，因此如果发生这种情况，我希望数据库不会爆炸。我们目前也有几个大公司作为客户，分别设有不同的部门（例如ACME母公司，ACME医疗保健部门，ACME身体护理部门） 我提出的架构如下： 从客户的角度来看： 客户是主表 客户链接到他们工作的部门 部门可以分散在一个国家/地区：伦敦的HR，斯旺西的市场营销等。 部门与公司的部门联系在一起 部门链接到母公司 从类的角度来看： 会话是主表 老师链接到每个会话 每个会话均会获得一个statusid。例如0-已完成，1-已取消 会话被分组为任意大小的“包” 每个包装都分配给一个客户 我在一张纸上“设计”（更像是乱涂乱画）该架构，试图使其标准化为第三种形式。然后我把电源插头插上到MySQL Workbench和它使人们都非常适合我：（点击查看全尺寸图片） （来源：maian.org） 我将要运行的示例查询 哪些客户的信用额仍处于闲置状态（将来未安排课程的客户） 每个客户/部门/部门的出勤率是多少（由每个会话中的状态ID衡量） 一个月一个老师上了几节课 标记出勤率低的客户 针对人力资源部门的自定义报告以及部门人员的出勤率 问题 这是工程过度还是我朝着正确的方向前进？ 对于大多数查询，需要联接多个表是否会对性能造成重大影响？ 我已经向客户端添加了一个“ lastsession”列，因为它可能将是一个常见的查询。这是个好主意还是应该严格规范化数据库？ 谢谢你的时间
4
ON [PRIMARY]是什么意思？
我正在创建一个SQL安装脚本，并以其他人的脚本为例。这是脚本的示例： SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TABLE [dbo].[be_Categories]( [CategoryID] [uniqueidentifier] ROWGUIDCOL NOT NULL CONSTRAINT [DF_be_Categories_CategoryID] DEFAULT (newid()), [CategoryName] [nvarchar](50) NULL, [Description] [nvarchar](200) NULL, [ParentID] [uniqueidentifier] NULL, CONSTRAINT [PK_be_Categories] PRIMARY KEY CLUSTERED ( [CategoryID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = …
8
您如何在数据库中表示继承？
我正在考虑如何在SQL Server数据库中表示复杂的结构。 考虑一个需要存储一系列对象的详细信息的应用程序，这些对象共享一些属性，但还有许多其他不常见的属性。例如，商业保险一揽子计划可能在同一份保单记录中包括责任险，汽车险，财产险和赔偿险。 在C＃等中实现此功能很简单，因为您可以创建一个带有Sections集合的Policy，其中Section是根据各种封面类型的要求继承的。但是，关系数据库似乎不允许这样做。 我可以看到有两个主要选择： 创建一个Policy表，然后创建一个Sections表，其中包含所有可能的变体所需的所有字段，其中大多数都是null。 创建一个Policy表和许多Section表，每种表一个。 这两种选择似乎都不令人满意，尤其是因为有必要在所有节中编写查询时，这将涉及大量联接或大量空检查。 这种情况下的最佳做法是什么？
11
多语言数据库的架构
我正在开发一种多语言软件。就应用程序代码而言，可本地化性不是问题。我们可以使用特定于语言的资源，并拥有与之配合使用的各种工具。 但是，定义多语言数据库架构的最佳方法是什么？假设我们有很多表（100个或更多），每个表可以有多个可以本地化的列（大多数nvarchar列应该可以本地化）。例如，其中一个表可能包含产品信息： CREATE TABLE T_PRODUCT ( NAME NVARCHAR(50), DESCRIPTION NTEXT, PRICE NUMBER(18, 2) ) 我可以想到三种方法来支持“名称”和“ DESCRIPTION”列中的多语言文本： 每种语言的单独列 当我们向系统添加新语言时，我们必须创建其他列来存储翻译后的文本，如下所示： CREATE TABLE T_PRODUCT ( NAME_EN NVARCHAR(50), NAME_DE NVARCHAR(50), NAME_SP NVARCHAR(50), DESCRIPTION_EN NTEXT, DESCRIPTION_DE NTEXT, DESCRIPTION_SP NTEXT, PRICE NUMBER(18,2) ) 带有每种语言列的翻译表 代替存储翻译的文本，仅存储翻译表的外键。翻译表包含每种语言的列。 CREATE TABLE T_PRODUCT ( NAME_FK int, DESCRIPTION_FK int, PRICE NUMBER(18, 2) …
25
使用电子邮件地址作为主键？
与自动递增的数字相比，电子邮件地址是否是主要的候选地址？ 我们的Web应用程序需要电子邮件地址在系统中唯一。因此，我想到了使用电子邮件地址作为主键。但是我的同事建议，字符串比较将比整数比较慢。 不使用电子邮件作为主键是正确的理由吗？ 我们正在使用PostgreSQL。
30
每个开发人员应该对数据库了解什么？[关闭]
按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意测验或进一步的讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 无论我们是否喜欢，我们中的大多数（如果不是大多数）开发人员要么定期使用数据库，要么可能有一天需要使用数据库。考虑到野外滥用和滥用的数量以及每天与数据库相关的问题的数量，可以公平地说，开发人员应该知道某些概念，即使他们没有设计或使用它们今天的数据库。所以： 对于数据库，开发人员和其他软件专业人员应了解哪些重要概念？ 回应准则： 保持简短。 每个答案一个概念是最好的。 要具体。 “数据建模”可能是一项重要技能，但这究竟意味着什么？ 解释你的理由。 为什么您的概念很重要？不要只说“使用索引”。不要陷入“最佳实践”中。说服您的听众去学习更多。 支持您同意的答案。 首先阅读别人的答案。一个高等级的答案比两个低等级的答案更有效。如果还有更多要添加的内容，请添加评论或引用原始内容。 不要仅仅因为它不适用于您而拒绝投票。 我们都在不同的领域工作。此处的目的是为数据库新手提供指导，以使他们对数据库设计和数据库驱动的开发有充分的基础和全面的了解，而不是争夺最重要的头衔。
4
我应该在SQL的varchar（length）电话中考虑的最长的全球电话号码是多少
我应该在SQL varchar(length)电话中考虑的最长的全球电话号码是什么。 注意事项： +国家代码 （）用于区号 x + 6个数字作为扩展名扩展名（因此请使其为8 {space}） 组之间的空格（即，在美国电话中+ x xxx xxx xxxx = 3个空格） 这是我需要您帮助的地方，我希望它能遍布全球 考虑到在我现在的特殊情况下，我不需要卡等。号码以国家代码开头，以分机号结尾，不需要传真/电话等注释，也不需要电话卡东西。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.