Questions tagged «database»

在我的一位雇主中，我们开发了REST（但也适用于SOAP）API。客户端即应用程序UI，将通过Web（在典型的生产部署中为LAN）对API进行调用。API将调用数据库。 在我们的讨论中反复出现的一个主题是性能：团队中的某些人认为，由于性能，您不应从单个API调用中进行多个数据库调用（通常是读取）。您应该对其进行优化，以便每个API调用仅（完全）一个数据库调用。 但这真的很重要吗？考虑到UI必须对API进行网络调用；相当大（毫秒级）。数据库经过优化，可以将内容保存在内存中并非常非常快地执行读取操作（例如，SQL Server可以将所有内容加载并保存在RAM中，如果可以的话，将消耗几乎所有的可用RAM）。 TLDR：当我们已经通过LAN进行网络调用时，担心多个数据库调用真的很重要吗？如果是这样，为什么？ 明确地说，我说的是数量级-我知道这取决于具体情况（机器硬件，API和DB的选择等）。如果我有一个调用需要O（毫秒），那么是否会针对DB进行优化呼叫数量少一个数量级，实际上重要吗？还是这个问题比这还重要？ 编辑：对于后代，我认为宣称在这种情况下我们需要通过组合数据库调用来提高性能是非常荒谬的，尤其是缺乏概要分析时。但是，是否执行此操作不是我的决定；我想知道认为这是优化Web API调用的正确方法的基本原理。

16 database  performance  web-services 

我对应该采取的方法感到有些困惑，正在研究购物车的设计，我需要将购物车存储在会话中或数据库中，但不确定哪种方法是最佳方法。 用户未登录并将产品添加到购物车（匿名用户） 用户已登录并将产品添加到购物车。 第一种情况对我来说更令人困惑，因为在许多情况下，用户只是访问网上商店并在没有登录的情况下添加产品，很可能他可能不会进行结帐流程。 但是我们仍然需要为此用户创建一个购物车，为了创建和保存购物车，我有两个选择。 当用户添加产品时，请在数据库中创建一个购物车并将该购物车与该用户相关联，当他登录时将其移动到登录用户。 当用户登录数据库中的创建购物车并将该登录购物车的用户与用户相关联时，创建购物车，向其中添加产品并将其保存到会话中。 我知道无论是数据库驱动的Cart系统还是基于Session的方面都可能有积极的方面也有消极的方面，但是我不确定哪一个是考虑以下几点的最佳方法 可扩展性 灵活性 可扩展性 应用程序应注意速度 寻找有关此方面的信息以决定路径。

16 database  session  design  web-applications 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 4年前关闭。 我最近一直在学习SQL，并在MySQL / Postgres和Oracle DB上进行练习。我还在网络上搜索数据库的“路线图”研究，但不幸的是找不到。 我想了解特定数据库概念在何处以及为何从初学者到中级和高级的规模。我大部分时间都在考虑关系数据库。 请说明在初学者->中级->高级过程中如何布置以下所列技能，以使开发人员应该了解这些技能的水平： Where子句 更新语法 加入 修改和创建语句 临时表 游标 指标 外键 约束条件 交易次数 子查询 枢轴 汇总功能 剖析 OLAP和OLTP 扳机 执行计划 执行提示 绩效柜台 正常化

16 learning  database  skills 

我继承了在MySQL数据库之上用PHP编写的大量旧代码。我注意到的是该应用程序doubles用于存储和处理数据。 现在，我遇到了许多帖子，提到double由于四舍五入的错误，它们不适合货币操作。但是，对于如何在PHP代码中处理货币值并将其存储在MySQL数据库中，我尚未找到完整的解决方案。 在专门用PHP处理资金时，是否有最佳实践？ 我正在寻找的东西是： 数据应如何存储在数据库中？列类型？尺寸？ 正常的加，减数据应如何处理。乘法还是除法？ 我应该什么时候取整值？舍入多少舍入（如果有）？ 处理大货币值和低货币值之间有区别吗？ 注意： 一个非常简化的示例代码，说明了我在日常生活中可能会遇到的货币价值（为简化起见，忽略了各种安全问题。当然，在现实生活中，我永远不会像这样使用我的代码）： $a= $_POST['price_in_dollars']; //-->(ex: 25.06) will be read as a string should it be cast to double? $b= $_POST['discount_rate'];//-->(ex: 0.35) value will always be less than 1 $valueToBeStored= $a * $b; //--> any hint here is welcomed $valueFromDatabase= $row['price']; //--> price …

16 web-development  design  php  database  mysql 

在过去的六年中，我一直是一名程序员。在我的整个职业生涯中，我从事许多Web应用程序的工作。 在大多数情况下，当需要数据库时，将数据库交给我们（程序员），或者我们有一些旧数据库可以处理。如果不是那样，我们就必须自己创建和设计数据库，这并不是那么困难。 但是，作为程序员，我们是否应该从头开始创建整个数据库，而我们必须构建新的应用程序，其中数据是如此重要，并且对复杂的数据模型有混乱的要求？ 由专家来完成应用程序不是对应用程序和公司的最大利益吗？ 我并不是想逃避设计数据库的努力，但是正确地做这件事是如此重要。

16 database  web-applications  database-design 

只需阅读这些行- 如果您的数据本质上是对象，则使用对象存储（“ NoSQL”）。它们将比关系数据库快得多。 如果您的数据本质上是关系型的，那么关系数据库的开销是值得的。 从- http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern 那么，我怎么知道我的数据是关系型的还是面向对象的呢？

16 object-oriented  database  relational-database 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 5年前关闭。 因此，我曾在许多不同的工作场所担任过开发人员，而我对数据库的访问级别也有所不同。我通常没有生产数据库访问权限。 大多数情况下，我可以访问测试数据库，但是它有所不同。有时我可以随意更改数据库和数据，但是通常还有其他安排。就像我可能只对数据具有读取权限。 我在一个由DBA团队管理数据库的地方工作，除非我们提交了带有sql脚本的表格以供他们“检查”，否则我们根本无法进行任何更改。他们通常与项目本身没有多大关系，因此在大多数情况下，只是按F5键即可。 老实说，我可以理解为什么需要锁定prod，但是我更喜欢在开发和测试环境中具有尽可能多的数据库访问权限。我认为大多数开发人员都有能力了解数据库周围的情况。但是我想听听意见吗？开发人员应具有多少数据库访问权限？我们可以信任不破坏任何东西吗？

16 database  security  access 

使用数据库但保持单元可测试性的一些OOP策略是什么？假设我有一个User类，并且我的生产环境适用于MySQL。我看到了两种可能的方法，如下所示使用PHP： 通过在与接口$ DATA_SOURCE load()和save()，抽象数据的后端源。测试时，请传递其他数据存储。 $ user =新用户（$ mysql_data_source）; $ user-> load（'bob'）; $ user-> setNickname（'Robby'）; $ user-> save（）; 使用访问数据库并将结果行传递给用户的构造函数的工厂。测试时，手动生成$ row参数，或在UserFactory :: $ data_source中模拟对象。（如何保存对记录的更改？） class UserFactory { static $data_source; public static function fetch( $username ) { $row = self::$data_source->get( [params] ); $user = new User( $row ); return $user; } } 我旁边有设计模式和简洁代码，但我一直在努力寻找适用的概念。

16 architecture  unit-testing  object-oriented  database 

说我有以下ER图： 现在，如果我使用Schoolin 的外键表示关系Student，则可以具有NULL值（因为a Student 不需要属于a School），例如： 因此，正确的方法（基于我所读的内容）是创建一个交集表来表示这种关系，例如： 这样，NULL表格中就不会出现任何值School_has_Student。 但是，使用可为空的外键而不是创建交集表的缺点是什么？ 编辑： 我误选了（school_id，student_id）是用于主键School_has_Student表，这使得许多关系到多。正确的主键应该是student_id：

15 database  database-design  relational-database 

我正在尝试使用PHP，MySQL，Jquery模板和JSON创建一个非常简单的待办事项列表应用程序。但是，我的架构似乎使JSON变得复杂。 最好的方法是什么？ 每个列表的新表，其中包含项目。 要么 一个用于列表的表，以及一个以某种方式连接的项目的表？因为我已经尝试过了，这似乎不是正确的方法？范例http://jsfiddle.net/Lto3xuhe/

15 database  database-design 

对于ElasticSearch和图数据库之间的比较，我在网络上找不到任何深入的解释。 两者均经过优化以遍历数据。 ElasticSearch似乎已针对分析进行了优化。 但是Neo4j也基于Lucene来管理索引和一些全文功能。 如果已经使用图形数据库，为什么还要使用ElasticSearch？ 就我而言，我正在使用Neo4j建立社交网络。 ElasticSearch可以带来什么真正的好处？ 更新---------- 我刚刚找到了这一段： 在无数情况下，elasticsearch是有用的。一些用例比其他用例更明确地要求它。下面列出了一些特别适合Elasticsearch的任务。 在大量产品说明中搜索特定词组（例如“厨师的刀”）的最佳匹配，并返回最佳结果 以前面的示例为例，分解出现“厨师的刀”的各个部门（请参阅本书后面的分面） 在文本中搜索听起来像“季节”的单词 在考虑到拼写错误的情况下，根据先前发布的搜索结果，根据部分键入的单词自动完成搜索框 以分布式方式存储大量的半结构化（JSON）数据，并在整个计算机集群中具有指定级别的冗余 但是，应该注意的是，尽管Elasticsearch在解决上述问题方面很出色，但对于其他人来说并不是最佳选择。解决关系数据库已优化的问题尤其困难。问题如下。 计算库存中剩余多少物品 计算给定月份发出的所有发票上所有行项目的总和 通过回滚支持以事务方式执行两个操作 创建保证在多个给定条件下唯一的记录，例如电话号码和分机号 Elasticsearch通常非常擅长提供数据的近似答案，例如按质量对结果进行评分。虽然Elasticsearch可以执行精确的匹配和统计计算，但其主要搜索任务是固有的近似任务。 查找近似答案是一种将Elasticsearch与更多传统数据库区分开的属性。话虽这么说，传统的关系数据库在精度和数据完整性方面都非常出色，而Elasticsearch和Lucene对此几乎没有规定。 我是否可以断言，如果我不需要近似答案，那么与已经使用的图形数据库相比，ElasticSearch会毫无用处吗？

15 database  query  graph-databases  elasticsearch 

据我所知，大多数关系数据库不提供任何用于查询的驱动程序级API，只有query将SQL字符串作为参数的函数除外。 我在想，如果可以做的话，会变得多么容易： var result = mysql.select('article', {id: 3}) 对于联接的表，它会稍微复杂一些，但仍然可能。例如： var tables = mysql.join({tables: ['article', 'category'], on: 'categoryID'}); mysql.select(tables, {'article.id': 3}, ['article.title', 'article.body', 'category.categoryID']) 代码更简洁，没有字符串解析开销，没有注入问题，更易于重用查询元素...我可以看到很多优点。 为什么选择仅通过SQL提供对查询的访问有特定原因吗？

15 database  sql 

如今，许多（也许是最多？）数据库应用程序都使用B树和变体来存储数据，因为这种数据结构优化了硬盘上的读取，写入和查找操作（这些操作反过来在硬盘的整体效率中起着重要的作用。数据库）。 但是，固态驱动器（SSD）是否应该完全取代传统硬盘（HDD），我们是否可以说B树和变体将变得过时，从而为在直接访问内存上更有效地运行的数据结构留出空间？如果是这样，这些结构将是什么？（例如，哈希表，AVL树）

15 database  data-structures 

按照目前的情况，这个问题并不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 8年前关闭。 在提出问题之前，让我首先描述一下我对SQLite的看法。 我碰巧喜欢小型，快速且更重要的是仅具有真正必要功能的工具。这就是为什么我喜欢SQLite而不喜欢MS-SQL的原因。 例如：MS-SQL可能具有更多的功能，可伸缩性等，但是如果您不走运，安装它也会很麻烦。当然，我并不是说安装困难是不选择特定数据库的原因。 不能误解我的意思：MS-SQL是优质产品。我对MS-SQL很有经验；我非常了解产品。我只是不太喜欢它，而在某些情况下并不需要它（=没有多少用户，<10-15）。 您实际上使用了多少数据库功能？以我的经验，它通常只是普通的SQL（SELECT，INSERT和UPDATE）。 我喜欢SQLite。快速着迷。“安装”非常容易。我认为SQLite可以做的比声明的要多。为什么只将其用于单进程/单个用户应用程序？毕竟：没有多少应用程序会不断访问数据库。 例如：考虑一个有15个用户的ERP应用程序。为什么不能使用SQLite？让我们面对现实吧：以我的专业经验，大多数时间，此类应用程序的用户访问数据库的时间将占他们使用该应用程序的总时间的5-10％。在另外90-95％的区域中，他们只是看着屏幕上的信息，以表格/表格形式输入数据，并且保存输入的时间不超过数据库时间的1秒。铁：1.5分钟的输入时间与1秒的保存时间。 如果SQLite数据库文件在“节省时间”期间被锁定，则需要访问数据库的其他用户只会等待，但他们不会注意到，因为等待时间会非常短（不明显）。在代码中，您只需要处理数据库可能的“繁忙”时间，以避免出现异常，但这并不难做到。 有些人必须像我一样思考，甚至​​为SQLite构建了一个客户端-服务器解决方案：SQLitening。这使我更加相信自己可能不会自欺欺人。 当然，有些数据库密集型应用程序不适合使用SQLite。但是，正如我现在考虑的那样，许多多用户应用程序（如果它们不超过15个用户）应该可以很好地使用SQLite。 我们的许多客户在硬件上的花费并不多，因此我经常遇到一台服务器，上面有所有东西（Exchange，SQL，客户端等），因此几乎“气喘吁吁”。如果我可以提供对系统要求不高的产品，那么我的客户将很高兴。SQLite不会增加任何权重（至少不会增加多少），​​MS-SQL会增加。因此，我不会选择SQLite，因为它是免费，便宜或易于安装的。我出于实际/技术原因会选择它。 仅供参考：根据我的专业，我们向客户销售产品（自定义和标准产品，主要是与ERP相关的产品），平均而言，使用该产品的客户不超过5-6人。有一些例外，但用户数不能超过10-15。 问题是：我是否认为可以将SQLite用于某些多用户应用程序（如我所描述的示例）正确吗？我应该知道什么技术上的缺点吗？您有哪些经验（负面或正面）可以帮助我做出正确的选择？ 更新：请不要将此视为对其他数据库的负面判断。它们大多都是优质产品。只是在这里分享我的想法并对您对此的看法感兴趣。

15 database  database-development 

在了解yield关键字的工作原理的同时，我遇到了StackOverflow 上的link1和link2，它主张yield return在DataReader 上进行迭代时使用它，它也适合我的需求。但是，这使我感到奇怪，如果发生如下情况，如果我yield return按如下所示使用，并且如果我不遍历整个DataReader，那么数据库连接会永远保持打开状态吗？ IEnumerable<IDataRecord> GetRecords() { SqlConnection myConnection = new SqlConnection(@"..."); SqlCommand myCommand = new SqlCommand(@"...", myConnection); myCommand.CommandType = System.Data.CommandType.Text; myConnection.Open(); myReader = myCommand.ExecuteReader(CommandBehavior.CloseConnection); try { while (myReader.Read()) { yield return myReader; } } finally { myReader.Close(); } } void AnotherMethod() { foreach(var rec in GetRecords()) { i++; …

15 c#  database  .net  resources