Questions tagged «database»

在接触了众多数据库抽象层之后，我开始怀疑每个库发明自己的不同范例来访问数据的意义何在。选择一种新的DAL感觉就像是在重新学习一种新的语言，通常我要做的只是说服该层输出我已经写在脑海中的SQL查询。 事实上，这甚至没有涉及可读性： # Exhibit A: A typical DAL rows = db(db.ips_x_users.ip_addr == '127.0.0.1') .inner_join(db.ips_x_users.user_id == db.users.id) .select(order=(db.ips_x_users.last_seen, 'desc'), limit=10) # Exhibit B: Another typical DAL rows = db.ips_x_users .join(db.users, on=db.ips_x_users.user_id == db.users.id) .filter(db.ips_x_users.ip_addr == '127.0.0.1') .select(sort=~db.ips_x_users, limit=10) # Exhibit C: A hypothetical DAL based on standard SQL syntax rows = …

18 database  sql  api-design  dsl 

我的团队正在从单一的ASP.NET应用程序迁移到.NET Core和Kubernetes。代码更改似乎正在进行中，并且可以预期，但是我的团队遇到的很多问题都围绕数据库进行。 当前，我们有一个相当大的SQL Server数据库，其中包含了整个业务的所有数据。我提议我们以与拆分代码类似的方式拆分数据库-一个逻辑数据库中的目录数据，另一个数据库中的库存数据，另一个数据库中的订单等-每个微服务都将成为其数据库的关守者。 这就意味着跨微服务边界的外键将必须被删除，跨边界的程序和视图将被禁止。所有数据模型可能会或可能不会驻留在同一个物理数据库中，但是即使它们存在，它们也不应直接相互交互。订单可能仍按ID引用目录项，但不会在数据库级别严格执行数据完整性，并且必须将数据以代码而不是SQL形式联接。 我认为这些损失是迁移到微服务并获得随之而来的可伸缩性优势时的必要折衷。只要我们明智地选择接缝并围绕它们发展，那应该没问题。其他团队成员坚持认为，所有内容都必须保留在同一个整体数据库中，以便所有内容都可以是ACID并在各处保留引用完整性。 这使我想到了我的问题。首先，我对外键约束和加入的立场是否合理？如果是这样，有人知道我可以提供给同事的任何可靠的阅读材料吗？他们的立场几乎是宗教性的，他们似乎不会因马丁·福勒本人告诉他们自己的错而受到任何影响。

18 architecture  database  refactoring  microservices 

对我来说，一个长期存在的问题是：何时将数据（实际值）存储在数据库表中，何时将其正确存储在代码中？ 无法达成共识的通常是这样的（*）： 如果它是单个变量或简单结构，或者是几个值的数组，则将数据放在代码中。 [* 共识已在评论和答案中进行了辩论，但基本上我希望有一个前提来启动这个问题，因此随时可以提出挑战并加以改进 ] 例： $number = 44; $colors = array("blue", "yellow", ... "mauve"); 如果它具有数百行以上相同类型的数据，请使用数据库。 但是似乎有一个灰色地带。那么不清楚的情况又如何呢？做出决定时需要注意哪些注意事项和因素？ 示例： 假设您的公司使用10-15种不同类型的电机框架，它们可以表示为“ 412T”。您大约有30个，并且它们很少更改。您可以为这些数据库创建数据库表，也可以在数据库中对其进行硬编码。在这种情况下，电动机是静态的，物理的东西，不太可能经常改变。 将它们保留在代码中会使它们受到源代码控制，而在数据库中，通常不会跟踪数据库更改。但是将它们保存在数据库中可以从数据中释放（分离）代码。 我可以使用的另一个（实际）示例是我的这个问题：https : //stackoverflow.com/questions/26169751/how-to-best-get-the-data-out-of-a-lookup-table（当前为48行选项数据）。

17 database  source-code  separation-of-concerns 

假设我有一个关系数据库应用程序，一个“用户”对象和一个“消息”对象。现在，我想向该用户显示未读邮件的数量。 存档的最佳方法是什么？我是否在用户中引入一个字段并在用户收到消息时对其进行计数，并在他阅读消息时减少计数？还是我每次都执行查询以计算标记为未读的用户消息数？ 我认为第一种方法更复杂且容易出错，但是会比第二种方法表现更好。 这通常是如何完成的，或者有什么更好的方法？

17 database  performance 

我正在为Android编写我的第一个应用程序，它将使用SQLite数据库，因此将尝试尽可能限制大小，但是我认为这个问题通常适用于数据库设计。 我打算存储将包含文本和创建日期的记录。该应用程序是一个独立的应用程序，即它不会链接到互联网，只有一个用户将对其进行更新，因此，在给定的日期，将不会有多个条目。 我的表格还需要一个ID列吗？如果是这样，使用ID作为记录标识符而不是日期有什么好处？

17 database 

我可能无法为该问题提供正确的标题。但这是 我们正在开发财富管理的金融门户。我们期望超过10000个客户端使用该应用程序。门户根据股票市场的技术分析计算各种绩效分析。 我们通过存储过程，用户定义的函数，触发器等通过数据库开发了许多功能。我们认为，与通过C＃代码相比，直接在数据库中执行操作可以大大提高性能。实际上，我们确实获得了巨大的性能提升。 当我试图向我们的CTO吹牛时，他反驳了我决定在数据库中而不是代码中实现功能的决定。据他介绍，此类应用程序存在可伸缩性问题。用他的话说：“如今，这些东西都保存在内存/缓存中。随着时间的推移，很难管理集群数据。Facebook，Google在数据库中什么也没有。这是瘦服务器和胖客户端的时代。DB仅用于存储纯数据并且功能应该与数据库完全分离。” 你们能给我一些关于他说的是否正确的建议。如何进行架构师这样的应用程序？

17 architecture  database  application-design 

我想问您，关于实施过滤后的搜索表单的意见。让我们想象以下情况： 1个有很多列的大表 可能很重要的一点是，此SQL Server 您需要实现一个表单来搜索此表中的数据，并且在此表单中，您将具有几个复选框，可用于汇总此搜索。 现在，我的问题是，以下哪一项应该是实现搜索的最佳方法？ 创建一个内部带有查询的存储过程。此存储过程将检查应用程序是否提供了参数，如果未提供参数，则将在查询中放入通配符。 创建一个动态查询，该查询将根据应用程序给出的内容进行构建。 我之所以这样问，是因为我知道SQL Server在创建存储过程时会创建执行计划，以优化其性能，但是通过在存储过程内部创建动态查询，我们会牺牲执行计划获得的优化吗？ 请告诉我，您认为最好的方法是什么。

17 database  sql  sql-server  methodology  development-approach 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 5年前关闭。 我目前正在评估一个潜在的新项目，该项目涉及为典型的客户信息（用户名，密码，姓氏和姓氏，电子邮件，地址，telfnr等）创建数据库。此时，仅对需求进行了粗略的定义。 预期客户数据库的记录为O（数百万）。为了计算数据库大小和评估潜在的数据库选项和体系结构的一些背景数据，我正在寻找此类记录的实际标准。特别是，每个字段的标准大小（名字，姓氏，地址等）或简单客户记录的平均平均值都是很好的信息。 在拥有如此众多的电子商务网站的情况下，应该有某种可以重复使用的典型配置，并且可以避免重新发明轮子。 有任何想法吗？ ----编辑---- 答案似乎是要采用标准的客户记录而不是设计自己的记录。我想强调的是，这个问题的重点是为客户对象的字段大小确定参考，并避免自己搞清楚（我在原始文本中强调了这一部分，现在以粗体显示）。

17 database  database-design  enterprise-architecture 

在繁重的开发期间，数据库架构会快速且连续地发生变化，并且随着我们每周对beta版本的推动而来，架构已发生了如此大的变化，以至于唯一明智的选择是删除所有我可以并且可以从我的开发数据库中复制新版本。显然，一旦启动，这是行不通的，因为破坏生产数据是灾难的根源，所以我想知道那里有什么策略来管理从一个版本/修订到另一个版本的数据库模式更改？ 我发现或经历过的一些： 直接从一个数据库到另一个数据库的nuke-and-dump（我现在在做什么） 使用通过脚本或手动运行的SQL语句维护UPDATE.sql文件。 在活动数据库中维护具有相应“ db-schema-version”值的update.php文件 第三种选择似乎是最明智的选择，但是仍然存在构造错误的SQL查询使中间脚本失败的可能性，从而使数据库处于半更新状态，因此需要还原备份。 看来这是没有问题的，但是确实发生了，因为我们作为一个团队，我们使用phpMyAdmin，我什至不能依靠自己记住复制执行的SQL语句以粘贴到update.php文件中。导航到另一页后，我必须手动重新编写SQL语句，或者撤消更改并再次执行。 我想我希望找到一种不会影响我们已建立的开发工作流程的解决方案？

17 database  versioning  push 

这是我本人和我的一些同事所进行的讨论，并认为我会来到这里，看看是否对此达成了普遍共识。 关于数据库调用，基本上可以归结为以下两种观点：1.进行一次大型调用以获取减少数据库调用数量所需的一切信息。2.根据请求的尺寸进行较小的单独调用以减小数据库的大小。数据库调用 这在通用代码中特别有用。我们将使用Employee类的示例，因为这很简单。 假设您的Employee类具有10个值属性（名字，姓氏，雇用日期等），然后具有2个类属性... 1个指向Department类，然后1个主管指向另一个Employee对象。 在心态1中，您将进行一次调用，以返回Employee数据以及填充Department和Supervisor属性所需的字段……或者至少返回那些子对象中最常使用的字段。 在思维方式2中，首先只填充Employee对象，然后仅在实际需要时以及在实际需要时才填充Department和Supervisor对象。 2的态度非常简单明了...最小化请求的大小以及每次发出这些请求中的一个时都要命中多少个数据库对象。＃1的立场是，即使可以正确实施，代码必须进行多个连接的纯粹事实也将导致Web服务器和数据库之间的连接受到更大的压力，而不是减少连接。 研究此问题的推动力是我们的Web服务器和数据库服务器之间的通信量已失控。

17 database  coding-style 

我的服务具有大量正在进行的用户事件，因此我们想做一些事情，例如“ 从日期D开始计数事件类型T的发生”。 我们正在尝试做出两个基本决定： 存储什么？存储每个事件与仅存储聚合 （事件日志样式）记录每个事件并在以后对它们进行计数。 （时间序列样式）每天存储一个汇总的“ 日期D的事件E数” 数据存储在哪里 在关系数据库（尤其是MySQL）中 在非关系（NoSQL）数据库中 在平面日志文件中（通过，通过网络集中收集syslog-ng） 什么是标准做法？在哪里可以找到有关比较不同类型系统的更多信息？ 额外细节： 事件流总数很大，每天可能有数十万个条目 但是我们目前的需求只是计算其中的某些类型的事件 我们不一定需要实时访问原始数据或聚合结果 恕我直言，“将所有事件记录到文件中，稍后对其进行爬网以过滤和聚合流”是一种非常标准的UNIX方式，但是我的Rails-y同胞似乎认为除非在MySQL中，否则什么都不是真实的。

17 architecture  database  metrics 

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 6年前关闭。 有哪些DO和DONT使用索引来提高数据库性能？ DO应该是应该创建索引的情况，或者是与索引相关的，可以提高性能的技巧。 如果不应该创建索引，或者其他可能影响性能的索引相关操作，则不要使用DONT。

17 database  performance  mysql  database-design 

我正在寻求有关消息队列的建议。我们要求将“职位”发布到消息队列中。 最初的建议只是使用SQL Server实例并处理来自该实例的消息。我在互联网上阅读的所有内容都表明，将数据库用于Message Queue并不是可扩展的解决方案。因此，建议使用RabbitMQ或其他第三方的MQ。 要考虑的另一件事是“作业处理”的要求不会低于30秒，因此执行作业的过程将每30秒轮询一次数据库。在我看来，这似乎还不错，并且在不向数据库中添加大量负载的情况下可以正常工作。 我们已经在客户端上建立了一个数据库，我们可以为此使用它，因此它不会为客户端增加太多额外的支持，而如果我们添加了一个第三方MQ，则会对网络配置等提供额外的支持。考虑到有很多用户，这相当可观。 我正在考虑的另一个选项是允许用户在两​​者之间进行选择。如果他们是小用户，则可以使用Sql Server解决方案，但如果他们是大用户，则可以允许他们配置第三方MQ解决方案。 我没有出售任何解决方案，我想知道是否有人有我应该考虑或建议的东西。

17 database  message-queue 

MongoDB是一个NoSQL数据库，我发现它非常易于使用。最近，我不得不开发一个简单的应用程序，该应用程序需要使用HTTP请求收集一些数据并在处理数据后存储一些结果，然后我尝试使用MongoDB。 通过这种经验，我发现使用它比使用传统的关系数据库要好得多，并且由于我是开发人员而不是DBA，因此极大地简化了我的工作。 不过，有时我不确定何时应该使用MongoDB代替传统的关系数据库（如SQL Server或MySQL）。 在那种情况下，何时可以使用MongoDB代替关系数据库？是否有关于MongoDB的重大警告，使其在某些情况下不合适？

17 database  nosql  mongodb 

什么是更快的性能明智的选择？创建REST API并让您的Web应用使用REST API来与数据库进行所有交互，或者直接查询数据库（即使用您的语言用来查询数据库的任何典型对象，例如Java的JDBC）？ 我使用REST的方式： 您在代码中创建一个对象以调用REST方法 调用http方法 REST API中的代码查询数据库 数据库返回一些数据 REST API代码将数据打包到Json中并将其发送到您的客户端 客户端收到Json / XML响应 将响应映射到代码中的对象 另一方面，直接查询数据库： 使用查询字符串创建对象以查询数据库 数据库返回一些数据 将响应映射到代码中的对象 因此，这是否意味着使用REST API会更慢？也许取决于数据库的类型（SQL vs NoSQL）？

16 database  rest  sql