Questions tagged «database»

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

5
对于支持数据验证的ORM，是否也应在数据库中强制执行约束？
除了（ActiveRecord）模型外，我还始终在数据库级别应用约束。但是我一直在想这是否真的必要吗？ 一点背景 最近，我不得不对模型的基本自动时间戳生成方法进行单元测试。通常，测试会创建模型的实例并保存而不进行验证。但是表定义中还有其他必填字段不能为空，这意味着即使我跳过ActiveRecord验证，也无法保存实例。因此，我在考虑是否应该从数据库本身中删除此类约束，并让ORM处理它们？ 如果我跳过db，imo中的约束，可能的优点 - 可以修改模型中的验证规则，而不必迁移数据库。 可以跳过测试中的验证。 可能的缺点？ 如果可能ORM验证失败或被旁路，则数据库不会检查约束。 你怎么看？ 编辑在这种情况下，我使用的是Yii Framework，它从数据库生成模型，因此也生成了数据库规则（尽管我总是可以自己在生成后编写它们）。
13 database  orm  validation  dry 
7
确定何时使用数据库的最佳方法是什么？
我开始使用PHP和MySQL进行网络开发的编程生涯。我已经习惯了使用db来存储大多数动态数据以及一些设置/参数数据。有时会有很多数据，而其他时候表中的条目会很少。在我看来，这似乎很自然，据我所知，这或多或少是Web开发中可接受的方法。（如果我错了，请纠正我...） 我现在正在研究桌面应用程序，我的自然倾向是再次利用数据库来存储大量信息，这些信息将通过使用该应用程序而生成。 但是，据我所知，我看不到应用程序（我使用的）经常使用db。 [编辑：自那以来，有人指出这是一个错误的假设，因为许多应用程序确实使用嵌入程序本身的轻量级数据库。] 这是什么原因？在什么时候使用数据库是合适的？关于这件事有什么标准吗？还有什么原因不使用数据库来开发桌面应用程序呢？
2
您如何处理数据库更改部署？
今天，我们一直在讨论数据库部署技术，在当前的过程中最近发生了几次失败，并且看到了一些情况，在这些情况下我们希望回滚部署，但是从未对旧版本的应用程序进行过测试。数据库。 一方面，存在迁移样式的部署，其中您具有版本上升指令和版本下降指令（无论是用SQL还是用您的应用程序语言编写的），并且您的应用程序知道需要获取哪个版本。 这些很简单，而且由于我们不会经常回滚，因此开发人员热衷于简单。但是，当您添加字段/表并在回滚之前填充该字段时，存在风险。或更糟糕的是，您删除了与先前版本相关的数据。 另一方面，我们可以考虑使用升级，回滚，前滚方法，其中回滚不像迁移那样剧烈。例如，升级可能会添加一个不可为空的字段；回滚使它可以为空，以便旧应用程序不在乎；前滚会填充空字段，并使它再次不可为空。 这样可以保留数据，但是代码和测试都很复杂（遗憾的是，我们几乎不存在自动集成测试，而在我们进行纠正的同时，我们也遇到了问题）。 有安全的方法来缓解这些问题吗？我还应该考虑其他选择吗？您是否想分享一些不好的经验，这些经验可以在以后帮助我减轻痛苦？
13 database 
5
我的团队害怕带有外键关系的关系数据库实体，我不明白为什么
我刚从大学毕业，所以对关系数据库的熟悉程度大部分来自于我的数据库课程，在该课程中，BCNF或3NF以外的任何事物都是荒唐的。当然，这是极端的目的，但是我的工作团队似乎确实将其推向了另一端。 在我们的微服务数据库架构中，实体很少有多个表。您通常会标准化到另一个表的所有内容都存储在json列中。如果以后发现需要查询此json中的属性之一，则会添加一个新列，并将数据存储在两个位置（是的，在同一表的两个不同列中）。 在许多情况下，这些json列绝对具有优势。如果您不需要查询数据，也不必单方面更改数据（这显然是您无法预测的），那么这不是一个坏主意。再加上我们的许多服务都看不到服务器，或者托管在具有淫秽磁盘空间的计算机上，无法满足他们的需求，因此数据复制不是一个大问题。（尽管我通常会出于哲学目的避免这种情况） 当前，我们正在构建一个服务，该服务根据规则所拥有的一组条件匹配规则，然后在规则为真（例如，所有条件都为真）时执行与这些规则关联的一组操作。我的最直接构建此服务的小组认为，从架构规则中规范动作和条件有很大的好处。显然，这些表与规则ID保持外键关系。从我们的角度来看，我们可以避免条件上的数据重复，这使我们能够确保仅对它们进行一次评估，并且在需要它们时很容易找到我们需要的条件和规则，而无需提取每个规则并在内存中进行搜索。 今天，他与我们的一位首席工程师交谈，试图使我远离这种模式。试图以各种方式争辩我们实际上并不需要它，这将在将来引起性能问题，并引用了我们拥有的旧单片，这是设计上的麻烦。他将我们正在做的事情称为“旧方法”，将带有json的平面表称为“新方法”。他争辩说，在我想要原子性的地方，我们不需要它，而不是查询，我们应该在内存中做更多的事情。这是我们许多服务现在遵循的设计原则。我们预计数据量不会大幅增长，这将使我们的查询保持快速。我们确实期望在规则评估和执行操作上花费大量时间。 我知道非关系数据库近年来已经变得越来越流行，但是即使在积极地搜索有关外键关系对性能的影响的信息时，我也看不到很多信息可以证明他的观点。我想他们可能会倾向于引入可能导致问题的大型事务，但这似乎是一个独立于外键本身的问题。 这是我的天真吗？还是我和我的子团队确实缺少某些东西？我没有明确提供有关我们问题的详细信息，因为我不一定正在寻找解决方案。考虑到这是我们大型团队的共同趋势，我真的很好奇他们是否对此有所帮助。
2
当用户编辑行时，是否应该将行锁定在云数据库中？
我正在创建一个桌面应用程序，将数据持久存储在云中。我关心的一个问题是开始在应用程序中编辑项目，并将其保留一段时间会导致数据过时。如果两个人同时尝试编辑同一项目，则显然也会发生这种情况。当他们完成编辑并要保存数据时，我要么需要覆盖数据库中当前存在的内容，要么检查他们在上一次更改之后是否开始编辑，或者迫使他们放弃更改，或者给他们选择冒险的选择覆盖他人的更改。 我想增加一个字段is_locked和lock_timestampdb表。当用户开始编辑项目时，该行将is_locked变为true并将锁定时间戳记设置为当前时间。然后，我将拥有一段时间的锁定时间（例如5分钟）。如果其他任何人尝试编辑该项目，他们将收到一条消息，指出该项目已被锁定，并且锁定自动失效。如果用户在编辑时走开，则锁会在相对较短的时间后自动过期，一旦这样做，将警告用户锁已过期，并在刷新数据后被迫重新开始编辑。 这是防止覆盖陈旧数据的好方法吗？是不是太过分了（我不希望单个帐户同时使用多个应用程序）。 （我还要担心的是，有2个人为同一物品锁上了锁，但是我认为这是我可以接受的比赛条件。）
5
如何避免在管理缓存的类中违反SRP？
注意：代码示例是用c＃编写的，但这无关紧要。我将c＃用作标签，因为找不到更合适的标签。这是关于代码结构的。 我正在阅读Clean Code，并试图成为一个更好的程序员。 我经常发现自己难以遵循“单一责任原则”（类和功能只能做一件事），尤其是在功能方面。也许我的问题是“一件事”的定义不明确，但仍然... 一个例子：我在数据库中有一个Fluffies列表。我们不在乎什么是蓬松。我想上课恢复蓬松。但是，蓬松可以根据某些逻辑进行更改。根据某些逻辑，此类将从缓存中返回数据或从数据库中获取最新数据。我们可以说它管理蓬松，这是一回事。为了简单起见，假设加载的数据可以使用一个小时，然后必须重新加载。 class FluffiesManager { private Fluffies m_Cache; private DateTime m_NextReload = DateTime.MinValue; // ... public Fluffies GetFluffies() { if (NeedsReload()) LoadFluffies(); return m_Cache; } private NeedsReload() { return (m_NextReload < DateTime.Now); } private void LoadFluffies() { GetFluffiesFromDb(); UpdateNextLoad(); } private void UpdateNextLoad() { m_NextReload = DatTime.Now …
2
如何编写抽象数据库接口以支持多种数据库类型？
如何开始在其较大的应用程序中设计一个抽象类，该类可以与多种类型的数据库（例如MySQL，SQLLite，MSSQL等）接口？ 这个设计模式叫什么，它从哪里开始呢？ 假设您需要编写一个具有以下方法的类 public class Database { public DatabaseType databaseType; public Database (DatabaseType databaseType){ this.databaseType = databaseType; } public void SaveToDatabase(){ // Save some data to the db } public void ReadFromDatabase(){ // Read some data from db } } //Application public class Foo { public Database db = new …
12 c#  database 
1
登录到文件还是数据库表？
我正在开发一个使用MS SQL来处理各种数据的Web应用程序：包括用户，用户帐户，用户许可证，许可证价格，发票。 我需要记录用户对系统的实时使用情况，并将其用于每月计费：例如，每当用户获得特定页面/ URL时就记录一次，并在月底根据所获取的页面数向用户计费。 是否应该将这些日志事件写入MS SQL数据库的表中？ 是否应将这些日志事件写入非SQL的仅追加日志文件？ 我应该为每个用户将这些日志事件写入不同的日志文件吗？ 这不是一个特别庞大的网站：例如，最多10,000个用户，每个用户平均每天进行5个可记录事件=> 50,000个事件/天= 30个事件/分钟= 18,000,000个事件/年。 我问是因为这两种选择似乎都是可行的，而且我看不出是否有明显的优势。 与计费事件相关的数据很简单，例如： 用户ID（SQL中与Users表的外键关系） 日期和时间 计费页面的URL 我对这个问题的回答如下： 将日志写入数据库表的一些好处： 关系完整性：例如，记录的事件与有效的用户ID相关联（通过将用户ID定义为表之间的外键） 易于阅读的账单：例如SELECT COUNT GROUP BY，获得每个用户的日志事件数的计数 写入日志文件的一些好处： 性能更容易：SQL较少使用，例如仅用于用户登录事件，而大多数仅用于读取 易于管理：通过移动旧日志文件而不是通过从数据库中删除/存档，例如在年底时更易于归档旧数据 如果我的答案有误，请告诉我；或夸大某事的重要性；或忘记了一些重要的考虑。 和/或，如果与我的答案不同，请告诉我您的答案是什么。
4
C＃最小SQL数据库
我正在做一个小项目（而不是生产项目），在这里我需要存储足够的数据，以至于像CSV这样的处理效率低下，而SQL / MySQL服务器则太多了。.Net是否有任何方法可以有效地存储多个数据条目，并且具有查询的能力，而无需管理和连接到服务器，而只需加载和处理单个文件。
12 c#  database  sql 
4
在对数据库建模时，何时应使用弱实体？
这基本上是一个关于弱实体是什么的问题？我们什么时候应该使用它们？应该如何建模？ 普通实体和弱实体之间的主要区别是什么？在进行域驱动设计时，弱实体是否对应于值对象？ 为了使问题始终保持话题，这里是一个来自维基百科的示例，人们可以用来回答以下问题： 在此示例中OrderItem，我们将其建模为弱实体，但我不明白为什么不能将其建模为普通实体。 另一个问题是，如果我想跟踪订单历史记录（即订单状态的变化），那将是正常实体还是弱实体？
2
坚持自然语言处理解析数据
我最近开始使用斯坦福大学的CoreNLP进行自然语言处理（NLP）的实验，并且想知道为文本挖掘应用程序之类的东西存储NLP解析数据的一些标准方法是什么？ 我认为可能有趣的一种方法是将子级存储为邻接列表，并充分利用递归查询（Postgres支持此功能，我发现它确实很好用）。 但我认为，根据多年来从事该领域工作的人员所进行的分析类型，可能有许多标准方法可以执行此操作。那么NLP解析数据的标准持久性策略是什么？如何使用它们？
12
使用XML作为数据存储[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我在考虑XML格式和以下引号： “ XML不是数据库。它从来都不是一个数据库。它永远不会成为数据库。关系数据库是经过验证的技术，具有20多年的实施经验。它们是坚固，稳定，有用的产品。他们不会消失。XML是在不同数据库之间或数据库与其他程序之间移动数据的非常有用的技术。但是，它本身不是数据库。“不要像以前一样使用它。”- Elliotte Rusty Harold着，有效的XML：50种改进XML的特定方法（第230页，第4部分，第41项，第二段） 这似乎确实强调了XML不应该用于数据存储，而应该仅用于程序之间的互操作性。 我个人不同意，app.config用于存储程序设置的.NET 文件是XML文件中数据存储的一个示例。但是，对于数据库而不是配置等，不应使用XML。 为了 阐明我的观点，我将使用两个示例：A）有关客户的数据全部都在一个级别上，即，有许多字段都与一位没有子 级的客户有关B）有关应用程序配置的数据，其中嵌套字段和属性很有意义 所以我的问题是，这仍然是有效的语句吗？现在可以接受使用XML存储数据了吗？ 编辑：我已经给该报价的作者发送了一封电子邮件，要求他提供输入/其他上下文。
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.