Questions tagged «database-design»

有关在数据库中构造数据的问题。如何布置表格，是否使用关系数据库，等等。

9
如何存储记录状态（如待定，完成，草稿，已取消…）
很多应用程序要求其表中的记录具有状态，例如“完成”，“草稿”，“已取消”。存储这些状态的最佳方法是什么？为了说明我在这里得到的是一个（非常简短的）示例。 我有一个简单的Blog应用程序，每个帖子的状态之一是：已发布，草稿或待审核。 我看到的方式有两种在数据库中建模的方式。 “发布”表的文本字段包含状态文本。 Post表的状态字段包含PostStatus表中记录的ID 这里的Blog示例是一个非常简单的示例。枚举（如果支持）可能就足够了。但是，我希望对此问题的回答要考虑到状态列表可以随时更改，因此可以添加或删除更多状态。 谁能解释每个优点/缺点？ 干杯! 我最初的选择是，最好使用另一个表并查找状态以使其更适合进行规范化，而且我一直被教导规范化对数据库有好处
4
允许用户定义字段是不好的做法吗？
一般来说，允许用户在Webapp数据库中创建用户创建的字段是否被认为是不好的做法？ 例如，我正在为妻子制作一个房屋库存网络应用程序，而她将要为不同的项目定义自己的字段。我打算允许她创建商品类别，并在这些类别中添加“功能”。功能只是将键/值存储为字符串。这样，例如，如果她有一个名为“音频CD”的类别，则可以为“艺术家”，“曲目”等内容添加功能。但是在另一个“家具”类别中，她可以为诸如“材料”之类添加功能”（木材，塑料等）。然后，任何项目都可以属于一个（或多个）类别，将那些功能添加到该项目中。 我看到的问题是，通过这些功能进行搜索需要字符串比较，没有数据验证等。按照敏捷的方法，也许最好是让她提出新的类别和属性，而我只需要创建新表当我们去。在我的示例中，这是一个很小的用户群（我们当中有2个），并且创建的记录量很小，因此也不错。 一般来说，人们在“现实生活”中如何处理这样的事情？
7
客户信息记录的事实标准[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 5年前关闭。 我目前正在评估一个潜在的新项目，该项目涉及为典型的客户信息（用户名，密码，姓氏和姓氏，电子邮件，地址，telfnr等）创建数据库。此时，仅对需求进行了粗略的定义。 预期客户数据库的记录为O（数百万）。为了计算数据库大小和评估潜在的数据库选项和体系结构的一些背景数据，我正在寻找此类记录的实际标准。特别是，每个字段的标准大小（名字，姓氏，地址等）或简单客户记录的平均平均值都是很好的信息。 在拥有如此众多的电子商务网站的情况下，应该有某种可以重复使用的典型配置，并且可以避免重新发明轮子。 有任何想法吗？ ----编辑---- 答案似乎是要采用标准的客户记录而不是设计自己的记录。我想强调的是，这个问题的重点是为客户对象的字段大小确定参考，并避免自己搞清楚（我在原始文本中强调了这一部分，现在以粗体显示）。
7
数据库索引遵循的最佳实践
按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 6年前关闭。 有哪些DO和DONT使用索引来提高数据库性能？ DO应该是应该创建索引的情况，或者是与索引相关的，可以提高性能的技巧。 如果不应该创建索引，或者其他可能影响性能的索引相关操作，则不要使用DONT。
5
版本控制数据库的内容
我正在开发一个涉及用户可编辑内容的Web项目，并且我希望能够对存在于数据库中的实际内容进行版本跟踪。基本上，我想实现Wiki样式的更改历史记录。 做一些背景研究，我看到了很多有关如何对数据库模式进行版本控制的文档（实际上已经控制了我的数据库），但是关于模式跟踪数据库内容变化的任何现有策略都至少在模式版本控制方面大失所望。在我的搜索中。 我可以想到几种实现我自己的变更跟踪的方法，但它们似乎都非常粗糙： 保存每次更改的整个行，并使用主键将行与源ID相关联（这是我目前最倾向于的方法，这是最简单的方法）。但是，许多小的更改可能会导致很多桌子膨胀。 保存每个更改之前/之后/用户/时间戳记，并使用列名称将更改关联回相关列。 用每列的表保存之前/之后/用户/时间戳（会导致表过多）。 使用列将每个更改的差异/用户/时间戳记保存起来（这意味着您必须遍历整个干预更改历史记录才能返回到特定日期）。 最好的方法是什么？自己动手似乎是在重塑别人的（更好）代码库。 PostgreSQL的加分点。
5
设计数据库是程序员的工作吗？
在过去的六年中，我一直是一名程序员。在我的整个职业生涯中，我从事许多Web应用程序的工作。 在大多数情况下，当需要数据库时，将数据库交给我们（程序员），或者我们有一些旧数据库可以处理。如果不是那样，我们就必须自己创建和设计数据库，这并不是那么困难。 但是，作为程序员，我们是否应该从头开始创建整个数据库，而我们必须构建新的应用程序，其中数据是如此重要，并且对复杂的数据模型有混乱的要求？ 由专家来完成应用程序不是对应用程序和公司的最大利益吗？ 我并不是想逃避设计数据库的努力，但是正确地做这件事是如此重要。
5
我的多服务器RDBMS或我的应用程序应该处理数据库参照完整性吗？
是否应由数据库管理系统（在这种情况下为MS SQL 2005）或应用程序处理外键，约束，默认值等项？我听取了双方的意见，老实说，我不确定该走哪条路。 我们有机会跨越多个服务器/数据库，而且我认为外键不能在链接的服务器之间使用。除此之外，数据库设计中还有一些循环引用，这使我无法ON UPDATE CASCADE在所有内容上使用。 该数据库是MS SQL 2005（可能是2008），与数据库的所有交互都应通过应用程序进行。
7
使用可为空的外键代替创建交集表的缺点
说我有以下ER图： 现在，如果我使用Schoolin 的外键表示关系Student，则可以具有NULL值（因为a Student 不需要属于a School），例如： 因此，正确的方法（基于我所读的内容）是创建一个交集表来表示这种关系，例如： 这样，NULL表格中就不会出现任何值School_has_Student。 但是，使用可为空的外键而不是创建交集表的缺点是什么？ 编辑： 我误选了（school_id，student_id）是用于主键School_has_Student表，这使得许多关系到多。正确的主键应该是student_id：
3
待办事项列表的数据库架构
我正在尝试使用PHP，MySQL，Jquery模板和JSON创建一个非常简单的待办事项列表应用程序。但是，我的架构似乎使JSON变得复杂。 最好的方法是什么？ 每个列表的新表，其中包含项目。 要么 一个用于列表的表，以及一个以某种方式连接的项目的表？因为我已经尝试过了，这似乎不是正确的方法？范例http://jsfiddle.net/Lto3xuhe/
7
设计用于保存财务记录的数据库时，需要哪些特殊注意事项？
我希望这个问题不会太广泛。将来，我可能需要向某些应用程序（主要是基于Web的应用程序，但我的问题也涉及台式机应用程序）中添加一些会计和财务跟踪系统。 现在，从理论上讲，创建金融交易的简单记录很容易。一个带有几列的数据库表可以完成这项工作。甚至MS Access，Excel，甚至只是纯ASCII文本文件都可以用于存储交易日期，帐户ID和美元金额。但是，我认为，即使是具有事务完整性的频繁备份的SQL表也可能不足以进行严重的财务跟踪。 我听到诸如“两次进入记帐”之类的术语，并且我感到大多数财务跟踪应用程序（例如Mint.com或GnuCash）都具有更复杂的数据结构或流程来确保一切完全合乎要求，完美地相加，并且不会丢失或破坏任何数据。 我的问题是：在设计用于跟踪财务交易的应用程序时，应考虑哪些特殊的设计注意事项？似乎可能存在很多潜在的问题...舍入精度，奇偶校验，某种审核过程，特殊备份，安全性/加密，在数据输入中间出现崩溃的情况下保护数据的其他方式等问题。 ...我真的不知道我应该具体询问什么，但是我感到编程行业有一些我一无所知的最佳实践。这些是什么？ 编辑： 看来我打开了比预期更大的蠕虫罐。为了明确起见，我正在特别考虑两种类型的应用程序： “检查注册表”类型的应用程序（例如GnuCash或Quicken）会保留个人交易记录供自己使用。 跟踪与公司打交道的供应商和客户的发票/贷项/或“积分”的应用程序。 我可能不会进行任何直接银行业务或（AFAIK）附带大量与金融相关的政府法规的工作。
9
我应该使用多列主键还是添加新列？
我当前的数据库设计使用多列主键来使用现有数据（无论如何都是唯一的），而不是创建为每个条目分配任意键的附加列。我知道这是允许的，但我想知道这是否是我可能要谨慎使用并可能避免的做法（就像C中的goto）。 那么，我可能会在这种方法中看到哪些缺点，或者是我想要一个单列键的原因呢？
2
如何设计基于角色的访问控制？
我试图遵循基于角色的访问控制模型来限制用户在系统中可以执行或不能执行的操作。 到目前为止，我具有以下实体： 用户 -将使用该系统的人员。这里有用户名和密码。 角色 -用户可以拥有的角色的集合。诸如经理，管理员等 资源之类的东西-用户可以操纵的东西。像合同，用户，合同草稿等 操作 -用户可以使用资源执行的操作。像创建，读取，更新或删除。 现在，我在图中有这样关系的地方对此表示怀疑： 操作（0 .. *）在 资源（0 .. *）上执行，该资源生成一个名为权限的表，该表将存储该操作和资源。 权限表如下所示（它的一行）： ID： 1，操作：创建，资源：合同。 这意味着许可，以创建一个合同。 我这样做是因为我觉得某些资源可能无法进行各种操作。例如，对于注册合同，用户可以上传文件，但是此操作不适用于注册提供商。 所以，现在当管理员将被赋予权限的角色，他不会有资源的清单，在系统中注册的每一个操作。 我认为每种资源都有自己的可以在他身上执行的操作的集合。 我可以澄清一下某些事情是无法理解的。 这是实施rbac的正确方法吗？ 编辑 我的意思是，通过拥有一个包含操作和资源的权限表，我有了两个额外的表，因为我想将资源与操作相关联。我本来也可以完成资源具有权限的权限，权限表将存储这些权限。 但是然后发生的是，当管理员分配资源时，某些权限甚至对于某些资源都不存在。 因此，我想从数据库设计的角度来了解具有一个列操作和另一个资源的表权限是否正确？如果这样下去我会遇到问题吗？
6
淘汰过时的数据库列的最佳实践是什么？[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 2年前关闭。 我正在设计一个应用程序，它将在早期阶段从客户端收集数据A，B和C，但稍后将收集数据A，B和D。 A，B，C和D非常相关，现在作为单个数据库PostgreSQL表T的列存在。 一旦不再需要C，我想从我的应用程序中删除它的引用（我使用Django ORM），但是我想保留已经输入的数据。最好的方法是什么？ 我曾考虑过为ABD创建一个新表，但这意味着可能会导致引用表T的任何行出现问题。 我可以只保留C列，并删除代码中对它的引用，以使现有数据得以保留。 有没有我看不到的更好的选择？ 一些额外的细节： 行数不会很大，很可能每个用户1-2行。这是一个大众市场应用程序，但是当我从C切换到D时，用户群还不会很大。尽管有可能，但C和D可能不会同时收集。C和D可能分别代表多个列，而不仅仅是每个列。
7
代理密钥是否应该向用户公开？
通常，在没有自然键的表中，对于用户来说，拥有唯一生成的标识符仍然很有用。如果表具有代理主键（在这种情况下，您一定会希望它具有），该键应该向用户公开还是应将另一个字段用于该目的？ 不公开代理键的原因之一是，现在您不能执行保留记录之间关系的操作，而只能更改键值，例如某些类型的删除/重新插入，将数据从一个数据库复制到数据库的许多方法。另一个等等 公开代理键的主要优点是使用您拥有的字段非常简单。 在什么情况下最好直接向用户公开代理密钥？
3
“您将如何构建此网站/应用程序”面试问题的一般思考过程[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我收集了许多面试问题，例如“描述如何设计相册应用程序”，“描述如何设计此特定网站的特定功能”（例如在Facebook上喜欢，在亚马逊上推荐，购物车，游戏黑色杰克）。那么，如果有成千上万的东西呢？你会改变什么？ 看起来这是在期待数据库架构还是一堆类定义（或两者都在？）。我在学校里已经学习过数据库，但是我以前从未真正设计过一个应用程序，并且很难知道从哪里开始，我提出的设计是否“好”以及我可以进行哪些更改以使其可扩展。 设计这些系统时是否有一般的方法或思考过程？我应该设法避免的一般问题/设计中出现的很多问题？有人可以指导我讲解其中的一个（或最好是全部，同时比较每个人的需求）并解释一下： 1）您如何提出需要哪些实体？2）您如何决定一切将拥有什么关系？3）您如何将性能优化纳入设计？4）我使用类或数据库吗？会有所不同吗（例如，我是否有一个不能真正转换为数据库表的类？） 我问的主要原因是因为我正在经历“破解编码面试”，我的答案与作者的答案完全不同-我对重要的类有不同的看法。 我的尝试： 使用照片共享应用程序，我将获得以下课程/表格：可以肯定的是照片和用户。 然后，我认为如果我们尝试创建模式，那么如果我们假设照片中的每个人都链接到照片，那么将存在一个链接照片和用户的表格（此表格是否必要？如果不是，是否仍然是惯例？是否有用于多对多关系的单独表格？）。 但是，如果我们尝试采用一种面向对象的方法，也许我们会拥有一个名为Album的类，它可以完成所有工作并具有来自其他两个表/类的所有信息。这是我在书中注意到的一件事-有一堆类，然后一个类基本上具有所有信息并连接了其他类-这是常见的吗？例如，在我上面的示例中，这似乎适用吗？ 我只是希望遵循一些通用规则/准则，因为现在我还不知道如何判断大型系统的良好架构是什么样的。
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.