Questions tagged «database»

该标签用于一般数据库问题。如果您对SQL有疑问，请改用该标记。

4
您采取什么措施来避免在大型数据库中错误地更新数据？
在进行任何生产部署之前，通常的建议是先备份数据库。这样，如果新更新存在一些可能导致潜在数据丢失或逻辑数据损坏的问题，则您仍具有备份以比较和更正旧记录。 但是，这可以很好地工作，直到数据库大小达到几GB。一旦数据库很大，备份就需要很长时间才能完成。在这种情况下应遵循哪些最佳实践，以避免由于代码部署中的逻辑问题而导致逻辑数据损坏？
4
使用平面文件与数据库/ API进行前端和后端之间的传输
我有一个应用程序，在几个开发人员之间引起了相当激烈的讨论。 基本上，它分为Web层和后端层。Web层通过一个简单的Web表单收集信息，并将此数据作为JSON文档（字面上是.json文件）存储到后端使用的watch文件夹中。后端每隔几秒钟轮询一次该文件夹，拾取文件并执行其功能。 文件本身非常简单（即所有字符串数据，无嵌套），最大时约为1-2k，系统大部分时间都处于空闲状态（但在任何给定时间突发多达100条消息）。每个邮件的后端处理步骤大约需要10分钟。 当一个开发人员建议使用文件系统作为消息传递层是一个糟糕的解决方案时，这种说法就出现了，而应改为使用诸如关系数据库（MySQL），noSQL数据库（Redis）甚至是普通的REST API调用之类的东西。 应当注意，Redis用于组织中其他地方的队列消息处理。 我听到的论点如下 支持平面文件： 平面文件比任何其他解决方案都更可靠，因为仅在拾取后将文件从“监视”文件夹移至“处理”文件夹，完成后才移至“完成”文件夹。除非存在非常低级的错误，否则消息消失的风险为零，这无论如何都会破坏其他功能。 平面文件需要较少的技术知识来理解-就是cat这样。无需编写查询，也不会意外将消息从队列中弹出并永久消失。 从编程的角度来看，文件管理代码比数据库API更简单，因为它是每种语言的标准库的一部分。这降低了代码库的整体复杂性以及必须引入的第三方代码的数量。 在YAGNI原则规定，平面文件工作得很好，现在，没有表现出需要更换一个更复杂的解决方案，所以离开它。 支持数据库： 扩展数据库比充满文件的目录更容易 平面文件存在有人将“完成”文件复制回“监视”目录的风险。由于此应用程序（虚拟机管理）的性质，这可能会导致灾难性的数据丢失。 要求T / S应用程序具有更高的技术水平，这意味着未受过教育的员工不太可能仅仅通过戳东西来搞砸。 数据库连接代码，尤其是针对Redis之类的数据库连接代码，至少与标准库文件管理功能一样强大。 从开发人员的角度来看，数据库连接代码明显（如果没有功能）更简单，因为它的级别比文件操作更高。 从我的看到，两个开发人员都有很多有效的观点。 因此，在这两个人中，亲文件开发人员或亲数据库开发人员中，哪一个更符合软件工程最佳实践，为什么？
3
如何在关系数据库中存储订购的信息
我正在尝试了解如何在关系数据库中正确存储有序信息。 一个例子： 假设我有一个由歌曲组成的播放列表。在我的关系数据库中，我有一个的表Playlists，其中包含一些元数据（名称，创建者等）。我还有一个名为的表Songs，其中包含playlist_id和特定于歌曲的信息（名称，艺术家，时长等）。 默认情况下，将新歌曲添加到播放列表时，它将添加到末尾。按Song-ID（升序）订购时，该顺序将为添加顺序。但是，如果用户应该能够对播放列表中的歌曲重新排序，该怎么办？ 我提出了一些想法，每个想法都有其优点和缺点： 称为的列order，它是整数。移动歌曲时，所有歌曲在其旧位置和新位置之间的顺序都会更改，以反映更改。这样做的缺点是，每次移动歌曲时都需要进行很多查询，并且移动算法不像其他选项那样琐碎。 称为的列order，它是一个十进制（NUMERIC）。移动歌曲时，会为其分配两个相邻数字之间的浮点值。缺点：十进制字段会占用更多空间，并且可能会精度不够，除非在每次更改后都注意重新分配范围。 另一种方法是使用previous和next字段引用其他歌曲。（或者，如果现在是播放列表中的第一首和最后一首歌曲，则为NULL；基本上，您将创建一个链表）。缺点：诸如“在列表中找到第X首歌曲”之类的查询不再是固定时间，而是线性时间。 在实践中最常使用以下哪个程序？在大中型数据库上，以下哪个过程最快？还有其他方法可以存档吗？ 编辑：为简单起见，在此示例中，一首歌曲仅属于一个播放列表（多对一关系）。当然，也可以使用Junction Table，因此song⟷playlist是一个多对多关系（并在该表上应用上述策略之一）。
9
关系数据库中的约束-为什么不完全删除它们？
如今，是否有任何理由在表之间（在SQLserver内部）建立约束？如果是这样，什么时候？我所在领域的大多数应用程序都是基于对象原理构建的，并且可以按需将表连接在一起。需求基于应用程序的需求。我不会加载一堆受约束的表来进行简单的查找，而这些查找又又（在执行操作之后）需要进行另一个简单的查找。 诸如EntityContext，Linq2Data，NHibernate之类的ORM工具也可以自己处理约束，至少您知道哪些表需要彼此使用。在服务器内部进行约束仅是对相同的更改进行两次（强制执行）？ 通常这不是要决定的问题，但是此数据库的设计却大不相同。设计看起来很正常，主要是镜像应用程序使用的对象。令我困扰的是在SQLserver内部使用“非级联”配置的所有约束。这意味着在编码新的数据库查询时，您必须扮演“寻找并查找”的角色。在某些情况下，单个订单最多需要10个级别的确切订单。 这让我感到惊讶，我不确定如何处理。 在我的简单世界中，这种设置使约束失去了大部分目的。如果在不了解设计的情况下从主机访问数据库，则单击“确定”。 在这种情况下，您将如何行动？ 为什么不从db中删除所有约束并将它们保持在应用程序级别呢？
4
为什么不使用SQL而不是GraphQL？
最近，我了解了GraphQL，它声称比RESTful更好。但是，我开始怀疑为什么不将SQL语句简单地放入HTTP GET请求中。 例如，在GraphQL中，我将编写 { Movie(id: "cixos5gtq0ogi0126tvekxo27") { id title actors { name } } } 这并不比它的SQL比较简单 SELECT id, title FROM movies WHERE id = cixos5gtq0ogi0126tvekxo27; SELECT actors.name FROM actors, actors_movies WHERE actors.id == movies.actor_id AND movie.id == cixos5gtq0ogi0126tvekxo27; 也许我们可以对查询进行URL编码并发送到服务器 GET endpoint?q=SELECT%20id%2C%20title%20FROM%20movies%20WHERE%20id%20%3D%20cixos5gtq0ogi0126tvekxo27%3B%0ASELECT%20actors.name%20FROM%20actors%2C%20actors_movies%20WHERE%20actors.id%20%3D%3D%20movies.actor_id%20AND%20movie.id%20%3D%3D%20cixos5gtq0ogi0126tvekxo27%3B HTTP/1.1 是的，查询URL可能太长，但是如果您不关心REST遵从性，则可以将其放入POST请求的正文中。（顺便说一句，我认为需要对REST进行HTTP RFC的修订才能有意义：限制查询字符串的长度从一开始就将实现与规范混合在一起） 从客户端直接发出SQL的优势还在于 解析GraphQL不需要服务器端代码/库，从而减少了开发时间。 解析GraphQL不需要服务器端开销，从而减少了运行时间。 SQL语句比GraphQL灵活得多，因为（在大多数情况下）GraphQL无论如何都会简化为SQL。 每个人都知道SQL。 那么，GraphQL与SQL相比有什么优势？
3
关系数据库和迭代开发
在许多软件开发方法中，例如敏捷方法论，领域驱动设计和面向对象的分析与设计，都鼓励我们采用一种迭代方法进行开发。 因此，我们不应该在第一次开始从事该项目时就正确完成我们的领域模型。相反，随着时间的流逝，我们重构模型，因为随着时间的流逝，我们对问题领域有了更深入的了解。 除此之外，即使我们已经尝试过建立一个完美的模型（我已经确信这很困难），需求也可能会发生变化。软件打完已经被部署到生产，最终用户可能会注意到，有一定要求的不完全了解，或者更糟的是，一些要求失踪了。 这里的要点是，在软件部署之后，我们可能最终需要更改模型。如果发生这种情况，我们就会遇到问题：生产数据库中的用户数据很重要，并且已经以旧模型的格式进行了拟合。 如果代码设计不当且系统很大，则更新代码可能是一项艰巨的任务。但这可以随着时间的推移而完成，我们拥有类似Git的工具，可以帮助我们做到这一点，而不会损坏可投入生产的版本。 另一方面，如果模型改变，类的属性消失或其他原因，则数据库也应改变。但是我们有一个问题：已经有不能丢失的数据，已经为旧模型格式化了。 关系数据库似乎是阻碍我们进行迭代开发甚至在最终用户需要时更新软件的障碍。 我已经使用的一种方法是编写一个特殊的类，该类将旧的数据库表映射到新的数据库表。因此，这些类选择旧格式的数据，将其转换为新模型使用的格式，然后保存到新表中。 这种方法似乎不是最好的方法。我在这里的问题是：是否存在任何众所周知的和推荐的方法来协调迭代开发与关系数据库？
4
如何在关系数据库驱动的应用程序中设计不好的数据库中创建更好的OO代码
我正在编写一个Java Web应用程序，该应用程序主要由一堆相似的页面组成，其中每个页面都有多个表和一个适用于这些表的过滤器。这些表上的数据来自SQL数据库。 我将myBatis用作ORM，在我的情况下，这可能不是最佳选择，因为数据库设计不良，而mybatis是面向数据库的工具。 我发现我正在编写很多重复的代码，因为由于数据库的不良设计，我不得不为类似的事情编写不同的查询，因为这些查询可能非常不同。也就是说，我无法轻松地将查询参数化。这会传播到我的代码中，而不是通过一个简单的循环来填充表中列上的行，我将代码改为： 得到一个数据（p1，...，pi）; 得到B数据（p1，...，pi）; 获得C数据（p1，...，pi）; 获得D数据（p1，...，pi）; ... 当我们有带有不同列的不同表时，这很快就会爆炸。 这也增加了我使用“ wicket”的复杂性，实际上是将对象映射到页面中的html元素。因此，我的Java代码成为了数据库和前端之间的适配器，这使我创建了许多布线，样板代码，并在其中混入了一些逻辑。 正确的解决方案是在ORM映射器上包裹一个额外层，该额外层为db提供一个更均匀的接口，还是有更好的方法来处理我正在编写的这些意大利面条式代码？ 编辑：有关数据库的更多信息 该数据库主要保存电话信息。较差的设计包括： 具有人工ID作为主键的表与域知识无关。 没有唯一，触发器，检查或外键。 具有通用名称的字段，这些字段匹配不同记录的不同概念。 只能通过与其他具有不同条件的表交叉才能分类的记录。 应为数字或日期存储为字符串的列。 综上所述，到处都是凌乱/懒惰的设计。
8
处理已删除的用户-单独还是相同的表？
场景是我的用户数量在不断扩大，随着时间的流逝，用户将取消他们的帐户，这些帐户目前在同一表中被我们标记为“已删除”（带有标记）。 如果具有相同电子邮件地址的用户（这就是用户登录的方式）希望创建一个新帐户，则可以再次注册，但是会创建一个新帐户。（我们为每个帐户提供唯一的ID，因此可以在实时和已删除的电子邮件地址之间复制电子邮件地址）。 我注意到的是，在整个系统中，正常情况下，我们会不断查询user表，以检查用户是否被删除，而我在想的是，我们根本不需要这样做。 ！[澄清1：通过'不断查询'，我的意思是我们有这样的查询：'... FROM users WHERE isdeleted =“ 0” AND ...'。例如，我们可能需要提取特定日期所有会议的所有注册用户，因此在该查询中，我们还具有FROM用户WHERE isdeleted =“ 0”-这使我的观点更清楚了吗？] (1) continue keeping deleted users in the 'main' users table (2) keep deleted users in a separate table (mostly required for historical book-keeping) 两种方法的优缺点是什么？
5
跨微服务同步数据的正确方法是什么？
我对微服务架构比较陌生。我们有一个中等大小的Web应用程序，我在权衡将其细分为微服务而不是我们目前正在发展的单片系统的利弊。 据我了解，考虑微服务A，B每个微服务都依赖于另一个服务。如果通过A说某件事已发生更改来发布消息，则B可以使用该消息并复制的信息的本地副本，A并使用该副本执行所需的任何B操作。 但是，如果B出现故障/失败，过一会儿又重新出现，该怎么办。在那段停机时间内，A又发布了两条消息。如何B知道如何更新其本地信息副本A？ 当然，如果B是A队列的唯一使用者，那么一旦它重新联机，它就可以开始读取它，但是如果该队列还有其他使用者并且这些消息被消耗了怎么办？ 作为一个更具体的示例，如果Users服务在Billing微服务关闭时更新了其电子邮件地址，如果Billing微服务又恢复了，它如何知道电子邮件已更新？ 当微服务恢复正常运行时，是否会广播说“嘿，我已经备份了，给我您所有的当前信息？” 通常，什么是数据同步的最佳行业实践？
8
您将如何设计具有自定义字段的用户数据库
这个问题是关于我应该如何设计一个数据库，它可以是关系型/ nosql数据库，这取决于什么是更好的解决方案 根据要求，您需要创建一个系统，该系统将包含一个跟踪“公司”和“用户”的数据库。一个用户总是只属于一个公司 用户只能属于一个公司 一个公司可以有很多用户 “公司”表的设计非常简单。公司将具有以下属性/列：（让我们保持简单） ID, COMPANY_NAME, CREATED_ON 第一种情况 简单明了，用户都具有相同的属性，因此可以通过关系样式，用户表轻松完成此操作： ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CREATED_ON 第二种情况 如果不同的公司想要为其用户存储不同的配置文件属性，会发生什么情况。每个公司将具有一组定义的属性，这些属性将应用于该公司的所有用户。 例如： 公司A要存储：LIKE_MOVIE（布尔值），LIKE_MUSIC（布尔值） 公司B要存储：FAV_CUISINE（字符串） 公司C要存储：OWN_DOG（布尔值），DOG_COUNT（整数） 方法1 暴力方式是为用户提供一个单一的架构，并在不属于公司的情况下让其为空： ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, LIKE_MOVIE, LIKE_MUSIC, FAV_CUISINE, OWN_DOG, DOG_COUNT, CREATED_ON 这有点麻烦，因为您最终会得到很多NULL，并且用户行的列与它们不相关（即，属于公司A的所有用户的FAV_CUISINE，OWN_DOG，DOG_COUNT的值为NULL） 方法2 第二种方法是拥有“自由格式字段”： ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_1, CUSTOM_2, CUSTOM_3, CREATED_ON 由于您不知道什么是自定义字段，因此这本身就很麻烦，数据类型将无法反映所存储的值（例如，我们将int值存储为VARCHAR）。 方法3 …
5
数据库表何时应使用时间戳记？
首先要注意的是，我认为这个问题可能属于数据库交换，但我认为它总体上与编程解决方案有关，而不是与数据库有关。如果人们认为那是最好的，它将转向数据库交换。 我想知道何时在数据库表中添加创建和更新的时间戳？ 第一个明显的答案是，如果任何业务逻辑需要知道什么时候进行了更新（例如事务完成日期等），则必须将其输入。 但是非业务逻辑案例呢？例如，我可以想到这样的场景：了解行更改的日期时间以帮助进行故障查找是非常有用的，例如某些业务逻辑发生故障并查看相关的数据库行，从而有可能在更新之前确定一行正在更新导致错误的另一行。 在这种用例下，给每个表一个更新并创建时间戳是有意义的（也许最琐碎的枚举表可能不会被应用程序的任何部分更新）。 为每个表提供时间戳肯定是快速停顿数据库的好方法（尽管可能是错误的）。 那么什么时候数据库表应该使用创建和更新时间戳？
3
为什么面向对象的数据库没有像关系数据库那样被广泛使用？[关闭]
按照目前的情况，这个问题不适合我们的问答形式。我们希望答案得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 我遇到过许多关系数据库管理系统（RDBMS）。但是最近我使用了休眠模式，这使我开始怀疑为什么面向对象的数据库没有那么流行。 如果像Java或C＃这样的面向对象语言如此流行，那么为什么面向对象的数据库管理系统（OODBMS）也不那么流行呢？
10
我的父亲是一位医生。他坚持要编写一个数据库来存储非关键的患者信息，并且没有编程背景。
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 因此，我父亲目前正在使用FileMaker Pro（一个基于GUI的数据库工具，用于他的小型（4位医生）实践）将数据库“黑客入侵”。该数据库将用于减轻医疗机器报告的负担，简化繁琐的流程。 他没有编程背景，并且似乎正在尽其所能来正确学习事物。他有重复的数据类型，没有数据库强制的关系（外键/主键约束）和许多其他问题。他正在使用Youtube视频通过GUI工具手动完成所有操作。 我的问题是，尽管我希望他能够100％成功，但我认为让他处理这些类型的决策并不恰当。我如何说服他，如果不接受这些主题方面的某种教育，那么一起破解是一个坏主意？他可能很固执，我认为他将这类工作视为“孩子们玩耍” 我应该如何处理？哪怕是个坏主意-还是我想他应该雇用合适的DBA /开发人员来处理这个问题，以免成为维护噩梦，所以我正确吗？ NB：我是4年的开发顾问，并且我看到了痛苦的客户实现中的我的一部分。 更新： 所以是几年后的事，我有时间思考这个问题。我父亲最终使用Google Docs，FileMaker Pro和一些电子邮件挂钩实施了一个解决方案。他自己完成了整个工作，他说他正在从中获得巨大的价值。 如果您是一位经验丰富的开发人员，则可能正在阅读该说明和内容。但实际上，我从整个过程中学到了很好的一课-人们只关心结果，而不关心实现。我父亲唯一关心的就是他不需要手动在纸上输入患者信息，而是可以快速填写Google文档表格。很棒的是，他正在寻找一个初级开发人员来专注于自己实践中的自动化。
18 database 
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.