Questions tagged «schema»

我已经对关系数据库做了很多工作，并且认为我对良好模式设计的基本概念非常了解。我最近的任务是接管一个由高薪顾问设计数据库的项目。请让我知道我的直觉是否是“ WTF ??！？” -是必要的，还是这个人真是个天才，以至于他超出了我的领域？ 有问题的数据库是一个内部应用程序，用于输入员工的请求。仅查看其中的一小部分，您就可以获得有关用户的信息以及有关所提出的请求的信息。我会这样设计： 用户表： UserID (primary Key, indexed, no dupes) FirstName LastName Department 要求表 RequestID (primary Key, indexed, no dupes) <...> various data fields containing request details UserID -- foreign key associated with User table 简单吧？ 顾问是这样设计的（带有示例数据）： 用户表 UserID FirstName LastName 234 John Doe 516 Jane Doe 123 …

61 database  sql  schema 

根据我的经验，我过去阅读的许多项目在数据库中都没有关系定义，而是仅在源代码中定义了它们。因此，我想知道在数据库和源代码中定义表之间的关系的优缺点是什么？而更广泛的问题是关于现代数据库中的其他高级功能，例如级联，触发器，过程...我的想法有几点： 在数据库中： 从设计中纠正数据。防止可能导致无效数据的应用程序错误。 在插入/更新数据时减少网络与应用程序的往返路程，因为应用程序必须进行更多查询以检查数据完整性。 在源代码中： 更灵活。 在扩展到多个数据库时更好，因为有时该关系可以是跨数据库的。 更好地控制数据完整性。数据库不必每次应用程序修改数据时都要检查一次（复杂度可以是O（n）或O（n log n）（？））。而是将其委托给应用程序。而且我认为，与使用数据库相比，在应用程序中处理数据完整性将导致更多详细的错误消息。例如：创建API服务器时，如果您在数据库中定义了关系，并且出了一些问题（例如所引用的实体不存在），则会收到一条带有消息的SQL异常。简单的方法是将500返还给客户端一个“内部服务器错误”，并且客户端不知道出了什么问题。或者服务器可以解析消息以找出问题所在，我认为这是一种难看且容易出错的方式。如果您让应用程序处理此问题， 还有别的事吗？ 编辑：正如Kilian指出的那样，关于性能和数据完整性的观点非常误导。所以我编辑来纠正我的观点。我完全理解让数据库处理将是一种更有效，更可靠的方法。请检查更新的问题，并对此进行一些思考。 编辑：谢谢大家。我收到的所有答案都指出，约束/关系应在数据库中定义。:)。我还有一个问题，因为它超出了此问题的范围，我将其发布为一个单独的问题：处理API服务器的数据库错误。请留下一些见解。

60 mysql  relational-database  schema  rdbms 

考虑到Google逐渐将重点放在页面标记数据上，Schema.org中使用的数据格式如何与微格式一起使用？这些（和其他规范）如何相互补充，在不同情况下应优先使用？ 编辑： 从关于该主题的既定内容看来，意见似乎在认为Schema.org是厄运，地狱和硫磺的人之间以及在无论采用哪种方式最终都将是好事的人之间存在分歧。 这两篇文章至少都同意，不同的格式可以愉快地共存，而不会引起搜索引擎的不满。但是，在特定情况下如何使用不同选项的问题仍然存在。

19 html  data  search  schema 

实现零停机时间部署也涉及到同一问题，但我需要一些有关正在考虑的策略的建议。 语境 一个基于Web的应用程序，其中Apache / PHP用于服务器端处理，而MySQL DB /文件系统用于持久性。 我们目前正在建设基础设施。所有网络硬件都将具有冗余，并且所有主网络电缆都将在绑定对中使用以实现容错。服务器被配置为具有硬件容错能力的高可用性对，并且将为虚拟机容错能力和总体性能进行负载平衡。 我的目的是我们能够在不停机的情况下将更新应用到应用程序。在设计基础架构以确保可以提供100％的正常运行时间时，我付出了极大的努力。每次应用更新会有10-15分钟的停机时间，这将是非常令人失望的。这一点特别重要，因为我们打算有一个非常快速的发布周期（有时每天可能达到一个或多个发布）。 网络拓扑结构 这是网络的摘要： Load Balancer |----------------------------| / / \ \ / / \ \ | Web Server | DB Server | Web Server | DB Server | |-------------------------|-------------------------| | Host-1 | Host-2 | Host-1 | Host-2 | |-------------------------|-------------------------| Node A \ / …

14 deployment  schema  strategy  downtime 

在关于NoSQL和SQL数据库的讨论中，我有时听到公司更喜欢使用无模式的NoSQL数据库，因为将模式迁移到新版本是有问题的。但这在升级时真的是一个大问题吗？关系数据库是否对此类操作有害？ 我在MongoDB博客上阅读了该博客文章：为什么使用Schemaless？

13 database  nosql  relational-database  schema 

我正在为一家公司提供新的销售点，该公司根据产品组合提供不同的价格。 所有产品都有底价。 为了解释我的问题，我将使用以下信息： Product Category Price A 1 45 B 1 70 Q 2 20 R 2 27 S 2 15 X 3 17 Y 3 22 Z 3 16 该公司有Packages，例如Package“ Combo”：对于产品A或B，如果选择Q或R中的1个以及X，Y或Z中的1个，则可享受$ 20的折扣。 案例A：有时客户在下订单时会添加基本产品，例如：他们不使用产品A，而是在其中添加产品Q和产品P以创建打折的包装。然后，他们可能会补充说，他们想要1个具有1 R和1 Z的乘积B。 情况B：有时客户会添加1 A和2 B，2 Q，1 S，2 X和1Z。根据“组合”程序包规定的规则，由于S不是组合项目，因此仅适用2个组合。 其他促销取决于数量，因此，如果您购买2件B，您将获得20％的折扣和/或取决于时间，该促销仅在下午5点之后有效，或者如果在上午10点之前折扣10％之前有效。另一个促销活动可能取决于您上次购买的时间或您在Y时间范围内的购买金额是否超过$ X。 我的问题： 1）如何构造表，以便以非常灵活的方式创建不同的包装或促销以添加具有不同要求的不同类型的促销？ 2）当他们像案例B（或案例A和案例B的混合商品）那样订购时，如何构造查询，以便测试订单中有哪些商品组合，并相应地更新价格/说明？最终，此查询的最佳结果将返回满足要求的包装和促销，从而给客户带来最大的利益（即，他们订购的产品满足促销1和促销3的要求，但是促销3的价格更低。必须与多个促销一起使用）。 先谢谢您的帮助！ 更新1 为了更好地描述手头的问题并更新迄今为止为解决这些问题而完成的工作，我将产品模型的ERD限于影响该问题的实体和属性（即，此处没有库存，因此没有库存）实体存在）。 …

11 web-development  database  database-design  schema  relationships 

我想知道RDFS / OWL的本体语言相对于使用标记/标记系统（例如http://www.schema.org/）来管理和创建元数据有什么优势？

10 schema  tagging  semantic-web 

针对数据库模式问题的一些回答，建议使用一个附加表来规范不属于当前要求的功能的数据库（UserDepartment表允许员工/用户与他们可能在不同部门之间建立多对多关系属于。）。 不反对规范化。似乎在进行数据库设计时，大力推动包含他们“确定”某人将来会想要的功能。将表/字段添加到数据库以适应功能是否是如此困难，以至于过度工程化的趋势？如果需要，它们是否会像应用程序的其余部分那样进行重构或升级？重做从来都不是一件有趣的事，但是可以将数据从一个表转移到一个新表。只是不确定这种思路会在哪里结束。 编辑：对此有很大的反感，我想知道有多少项目最终没有添加需要进行重大数据库更改的功能，或者是否采取了非规范化的方法（例如添加DepartmentID2字段而不是新表）。员工需要多个部门是一个常见的领域问题。我只是没有注意到许多杂乱无章的数据库模式。

9 design  database  refactoring  schema 

我管理一些K-12学校和一些大学使用的开源PHP / MySQL Web应用程序。我也是该项目的唯一开发人员。虽然它过去只不过是我老板托管的应用程序的源代码下载，但在过去的一年中，我一直致力于将其变成一个“真正的”开源项目，其中包含文档，带编号的发行版，公共变更日志等。 我正在寻求改善升级过程，其中一个潜在的难题（尤其是对于IT专业人员匮乏的学校而言）是在两个发行版之间对数据库架构的更改。它们不经常发生或变化不大，但我希望您对此过程提出建议。 当前，我维护一个基本的SQL安装脚本，以在新安装中设置数据库。这包括当前版本的完整架构；全新安装不需要任何进一步的操作。版本之间发生的更改存储在upgrade-$releasever.sql脚本中，对于所有被跳过的版本，有必要增量运行所有升级脚本。 Shell脚本不合适，因为我们很多用户都在没有Shell访问权限的主机上运行。由于其他优先事项，不太可能实现基于PHP浏览器的复杂安装程序/升级脚本。但是，我想使用基于浏览器的PHP脚本来简化升级。关于如何处理的建议？

9 database  release  upgrade  schema