Questions tagged «database-design»

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

4
存储n-gram数据
我希望就存储n- gram数据的问题进行一些讨论。在我的项目中，我正在尝试解决所有我知道（n -1）个数据项的语言问题，并希望在所有适用的n- gram上使用线性插值来统计地猜测我的n。（是的，有一个标记器根据其词典将标记分配给已知单词，还有一个后缀树试图猜测未知单词的单词种类；这里讨论的n -gram组件将负责解决歧义。） 我最初的方法是简单地将所有观察到的n元（对于n = 1..3，即会标，二元组，三元组）数据存储在相应的SQL数据库中，并称之为一天。但是我的项目要求可能会改变，以包括其他向量长度（n），我希望我的应用程序能够适应4克语言而无需进行大量工作（更新架构，更新应用程序代码等）；理想情况下，我只是简单地告诉我的应用程序现在可以处理4克代码，而不必太多（或根本不需要）更改代码并从给定的数据源训练其数据。 总结所有要求： 能够存储n克数据（最初用于n = {1,2,3} 能够更改应使用哪种n- gram（在应用程序运行之间） 能够（重新）训练n- gram数据（在应用程序运行之间） 能够查询数据存储（例如，如果我观察到A，B，C，我想知道使用我训练有素的4、3、2、1克数据集后最常观察到的项目） 该应用程序很可能是读取繁重的，很可能不会经常重新训练数据集 该解决方案采用.NET Framework（最高4.0） 现在，哪种设计更适合此类任务？ 由SQL服务器（MSSQL，MySQL等）为每个n管理的固定表（例如，用于二元语法，三元语法等的专用表） 还是将第一个n -1 存储为文档的键的NoSQL文档数据库解决方案，并且文档本身包含第n个值和观察到的频率？ 还是有所不同？
4
长字符串数据库的最佳方法
我需要将问题和答案存储在数据库中。问题将是一到两个句子，但答案会很长，至少一个段落，甚至可能更多。 我现在知道要做的唯一方法是SQL数据库。但是，我觉得这不是一个好的解决方案，因为据我所知，这些数据库并未用于这种类型或大小的数据。这是正确的方法还是有更好的方法来存储此数据？有没有比存储原始字符串更好的方法？
2
我应该如何在一个宁静的服务中设计一个有序列表资源？
我一遍又一遍地遇到了同样的问题，但我还没有找到我真正认为是最佳的解决方案。 在应用中说，您有一个有序列表，然后让用户通过拖放等方式更改该顺序。您希望顺序中的更改得以保留。您如何建模？ 如何设计有序列表资源的静态服务？ 特别是，我应该如何设计list和item宁静的资源的模型？我见过的最常见的设计是item具有order或position属性的实体。我听到的另一种方法是在商品上使用双链表。 什么是一种方法，它不会向数据库写入太多内容，并且通常可以为客户端快速更新和读取？端点应该如何暴露？
2
处理订阅，余额和定价计划更改
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 序言 我的目的是为多个项目创建可重用的代码（并在github上发布）以管理订阅。我了解条带化和定期计费提供商，但这不是该模块的目标。它应该只是用于计算帐户余额，轻松通知续订订阅以及处理价格计算的包装程序/帮助程序。 在某些国家/地区，您可能无法使用重复计费，因为提供商或付款方式对此支持不佳或没有支持，或者价格太高（小额付款）。而且有些人不想使用循环计费，而是手动支付账单/在年末开具发票。因此，请不要建议贝宝定期计费，递归或类似服务。 情况 假设您有一个可以订阅订阅计划的模型（例如User）。该模型具有一个字段，该字段存储当前正在订阅的订阅计划的标识符。因此，在每次计划更改时，都会记录更改。 有一个模型（例如SubscriptionPlanChanges），其中的以下字段记录了提到的更改： subscriber与订阅模型有关（User在这种情况下） from_plan 定义更改之前模型具有的计划标识符 to_plan 定义模型现在选择的计划标识符 created_at 是存储更改的日期时间字段 valid_until 存储日期，直到实际订阅有效 paid_at 也是一个日期时间字段，用于定义是否（以及何时）订阅已支付 当然，这种布局是可以讨论的。 帐户余额问题 当用户更改其订阅计划时，我需要比较计划字段，获取价格，并根据当前计划valid_until及其价格计算新计划的扣除额。说：您订购了计划A的一年，但是在6个月后，您升级到计划B，因此您可以从计划A的6个月中扣除一半的已付价格。 我想知道的是：如果某个用户（例如）切换到免费计划，那么他有一个积分，如果该用户想要再次切换，则可以扣除该积分。您会在另一个字段中缓存该值，还是每次都计算与该用户相关的所有记录？您会添加/更改有关表格布局的内容吗？ 易于理解的问题 当订阅期结束时，用户会收到通知，并有可能通过再次付费来续订其订阅。最简单的方法是只更新paid_at和valid_until新的订阅选项。但是，我不确定您是否存储了某人可能需要的所有数据，例如付款/订阅历史记录。 另一个选择是为此创建一个附加记录，其中from_plan和to_plan具有相同的标识符（因此表示“无变化”）。但是这不会以某种方式干扰帐户余额的计算吗？ 如果有人能为我指出有关处理此类订阅的逻辑的正确方向，我将非常感激。 更新 感谢您的帮助。我认为我的问题太模糊了，因此我将尝试通过使用较少的抽象来使其更加精确。不幸的是，我还不能解决我的问题。 案例A User可以选择Subscription Plan A。当前，此文件存储了一个SubscriptionPlanChange以进行跟踪。例如5个月后，User将其订阅升级为Subscription Plan B。因此，他为新订阅支付价格，减去未使用的7个月的方案a的价格。 案例B 3个月后，User回滚到他的Subscription Plan A。他不必付款，但会收到一笔余额，因此，在订阅结束时，他将从新订阅中扣除该余额。 案例C User可以为具有独立订阅计划的子服务选择订阅计划。相同Case A，Case B可以申请该子服务订阅。 _Case D_ 用户取消其订阅之一。这导致他的余额增加了。 我的问题（目前至少是）主要取决于如何正确存储数据，以便我可以重现订阅的历史以进行业务分析和计算余额，并根据订阅获得未付款项等。 我也不确定是否应将余额存储在例如用户模型本身中，或者是否未存储但可以根据存储的数据/历史记录随时进行计算。 需要注意一些事项，尽管我认为它们不应该引入问题： …
3
在访问/处理复杂数据时，将其存储为许多小块还是一大块更好？
我正在构建一个处理相当复杂的数据的Web应用程序：吉他标签。 As a reference, guitar tabs look like this: Eb|-------------------------------------------------------------------------| Bb|-------------------------------------------------------------------------| Gb|--5-5-5-5----------------------------------------------------------------| Db|--5-5-5-5--3-3-3-3--7-7-7-7--5-5-5-5--2-2-2-2--3-3-3-3--2-2-2-2--5-5-5-5-| Ab|--3-3-3-3--3-3-3-3--7-7-7-7--5-5-5-5--2-2-2-2--3-3-3-3--2-2-2-2--5-5-5-5-| Eb|-----------1-1-1-1--5-5-5-5--3-3-3-3--0-0-0-0--1-1-1-1--0-0-0-0--3-3-3-3-| 将这些数据作为大块存储，或者将其分解并按“逐个记录”的方式存储，会提高性能吗？ As a use case: User changes first chord from: to: Eb|--- Eb|--- Bb|--- Bb|--- Gb|--5 Gb|--4 Db|--5 Db|--4 Ab|--3 Ab|--2 Eb|--- Eb|--- 如果我将其存储为块，则操作选项卡的代码将必须复杂得多。如果我逐条记录存储，则将需要更多地访问数据库。哪种方法更有效？潜在地，许多用户将修改数据。我想要性能最好的Web应用程序。如果这完全影响答案，我将使用MySQL。
2
将“结果”与“状态”分开的好处是什么
假设您有一些自动化流程，这些流程通常会经历以下状态；预定-启动-验证-执行-完成 最重要的是，由于错误或明确的用户取消，这些过程可能会过早结束。 我的第一个冲动就是简单地将错误添加并取消到可能的状态值列表中，但是我想知道将结果与状态分开的（概念上的）优势（即使在我看来，有人可能会认为错误和取消也是与完成状态完全不同的状态）。
10
RDBMS如何被视为一种时尚？
我于2003年完成了计算机A级学习，并于2007年获得了计算机学位，并且在一家使用大量SQL的公司中学习了自己的交易，因此我想到了将关系数据库用于存储的想法。 因此，尽管相对较不熟悉开发，我还是吃了一惊（在/software//q/89994/12436上）读到的评论说： [一些开发人员]鄙视[SQL]，并认为它和RDBMS是一时的流行 显然，有能力的开发人员将使用正确的工具来完成正确的工作，并且在例如适用于平面文件或其他存储解决方案的情况下，不会创建关系数据库，但是RDBM在很多情况下都非常有用，因此如何被认为是一种时尚？
3
使用用户权限存储菜单项
我正在用PHP和MySQL创建菜单系统。我将有几个不同的菜单，每个菜单都将具有一组与其连接的菜单项。 在该网站上，我还具有不同的用户权限，有些用户可以看到所有菜单项，有些项目对某些用户是隐藏的。我很好奇如何以一种干净的方式处理权限，将来可以轻松添加更多类型的用户。 到目前为止，我有这样的事情： ------------------- |Menus ------------------- |id| |display name| ------------------- ---------------------------------------------------------- |Menu items ---------------------------------------------------------- |id| |menu_id| |label| |link| |parent| |sort| |permission| ---------------------------------------------------------- 我在想该permission列可能是一个逗号分隔的字符串，我可以将其与当前用户的权限ID进行匹配。它也可能是对其他一些表的引用，该表定义了当前现有权限的所有可能组合。 一种解决方案也可以是简单地存储多个菜单项，唯一的区别是权限，尽管这将导致重复存储，并且可能给管理带来麻烦。 我很想听听有关如何组织这个以及什么可以被认为是干净，动态和dynamic脚的思考。 谢谢。
2
定价产品的数据库架构（打包，促销，基于数量，限时提供…）
我正在为一家公司提供新的销售点，该公司根据产品组合提供不同的价格。 所有产品都有底价。 为了解释我的问题，我将使用以下信息： 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限于影响该问题的实体和属性（即，此处没有库存，因此没有库存）实体存在）。 …
5
我是否真的需要关系数据库的触发器，例如PostgreSQL？
我知道触发器可以用来验证存储的数据以保持数据库的一致性。但是，为什么不先在应用程序端对数据进行验证，然后再将其存储到数据库中呢？ 例如，我们存储客户，并且我们想要执行一些在DDL级别上不容易完成的验证。 https://severalnines.com/blog/postgresql-triggers-and-stored-function-basics 另一个例子是审计。 更新资料 触发器和数据库事务如何一起工作。例如，如果我想对插入的数据进行验证。它是在事务内部完成的。之前发生了什么：事务已提交或触发器已执行？
1
2v2游戏的数据库结构
我经常与12个朋友一起玩2v2游戏，我想要一个数据库来跟踪球员，球队，得分和比赛，以创建排名系统。 既然我们定期更换球队，我想出来的表格players，teams并games在那里比赛有两支球队（TEAM1和TEAM2）和队由两名队员（PLAYER1和player2）。 这会引起很多问题-例如，如果我选择两个球员（让他们分别称为A和B）一起玩，我必须检查是否已经存在一个其中Player1为A且Player2为B或Player1为B和Player2的球队是A。 表格和表格中都有列games和wins，但这是因为我既要查看玩家赢得了多少场比赛，又要查看玩家在不同团队中的兼容性（玩家与团队合作获胜的频率）其他特定玩家）。playersteams 排名记分牌（我可能会使用Elo评分系统） 为每个球员提供的统计信息页面，其中包括评分，获胜，比赛，最近的比赛统计信息以及与他最兼容的球员。 我强烈怀疑其中许多内容违反了数据库规范化的某些原则，并且我很乐意就如何实施数据库设计提出一些建议。
2
谁设计Web开发中的数据库？[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 3年前关闭。 在Web开发的背景下，谁设计数据库？尽管有大量的信息将后端Web开发人员与服务器端处理，数据建模等相关联，但方程式的数据库设计方面似乎并不存在。 我不是在说谁设置物理数据库，而是在说谁设计数据库的逻辑模型，进行用户故事采访以获取有关需要哪些字段，这些字段规范是什么等信息。 。 我已经意识到（PROPER数据库）的设计是不小的任务（我在读这 672寻呼机），并可以很容易地是整个行业。但是，在Internet上上下搜索对于预期在Web开发环境中负责此任务的人员而言，收效甚微。
3
哪种数据存储最适合我的情况？
我正在开发一个涉及数据库中更新/选择查询执行非常高的应用程序。 我有一个基本表（A），该表每天将有一个实体约500条记录。对于系统中的每个用户，将根据用户的某些首选项创建此实体的变体，并将它们存储在另一个表（B）中。这是通过每天在午夜运行的Cron作业完成的。 因此，如果表A中有10,000个用户和500条记录，则该天表B中将有500万条记录。我总是将数据保留在这些表中一天，午夜将历史数据存档到HBase。此设置运行良好，到目前为止，我没有任何性能问题。 最近业务需求发生了一些变化，现在基本表A中的某些属性（对于15-20条记录）将每20秒更改一次，因此我必须重新计算表B中所有这些变化记录的某些值，全部用户。即使仅更改20条主记录，我也需要重新计算并更新200,000条用户记录，这花费了20秒钟以上的时间，然后才发生下一次更新，最终导致所有Select查询排队。我从在线用户那里得到3个获取请求/ 5秒，这导致6-9个选择查询。为了响应api请求，我总是使用表B中的字段。 我可以购买更多的处理能力来解决这种情况，但是我对拥有一个可以处理甚至一百万用户的适当缩放的系统感兴趣。 这里有人可以提出更好的选择吗？Nosql +关系数据库对我有帮助吗？是否有任何平台/数据存储可让我频繁地更新数据而不会锁定，同时又使我能够灵活地在实体的各个字段上运行选择查询？
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.