Questions tagged «rdbms»

有什么工程上的原因为什么会这样？在RDBMS的情况下，我想知道它与性能有关，因为“ YEAR”比“ MONTH”更具体，例如：您只有2000年，而每年都有“ January”，这样可以更轻松，更快捷地按年份过滤/排序某些内容，这就是为什么年份第一的原因。 但是我不知道这真的有道理吗？有什么理由吗？

118 sql  engineering  rdbms  date-format 

根据我的经验，我过去阅读的许多项目在数据库中都没有关系定义，而是仅在源代码中定义了它们。因此，我想知道在数据库和源代码中定义表之间的关系的优缺点是什么？而更广泛的问题是关于现代数据库中的其他高级功能，例如级联，触发器，过程...我的想法有几点： 在数据库中： 从设计中纠正数据。防止可能导致无效数据的应用程序错误。 在插入/更新数据时减少网络与应用程序的往返路程，因为应用程序必须进行更多查询以检查数据完整性。 在源代码中： 更灵活。 在扩展到多个数据库时更好，因为有时该关系可以是跨数据库的。 更好地控制数据完整性。数据库不必每次应用程序修改数据时都要检查一次（复杂度可以是O（n）或O（n log n）（？））。而是将其委托给应用程序。而且我认为，与使用数据库相比，在应用程序中处理数据完整性将导致更多详细的错误消息。例如：创建API服务器时，如果您在数据库中定义了关系，并且出了一些问题（例如所引用的实体不存在），则会收到一条带有消息的SQL异常。简单的方法是将500返还给客户端一个“内部服务器错误”，并且客户端不知道出了什么问题。或者服务器可以解析消息以找出问题所在，我认为这是一种难看且容易出错的方式。如果您让应用程序处理此问题， 还有别的事吗？ 编辑：正如Kilian指出的那样，关于性能和数据完整性的观点非常误导。所以我编辑来纠正我的观点。我完全理解让数据库处理将是一种更有效，更可靠的方法。请检查更新的问题，并对此进行一些思考。 编辑：谢谢大家。我收到的所有答案都指出，约束/关系应在数据库中定义。:)。我还有一个问题，因为它超出了此问题的范围，我将其发布为一个单独的问题：处理API服务器的数据库错误。请留下一些见解。

60 mysql  relational-database  schema  rdbms 

假设我正在建立一个博客，希望发布和发表评论。因此，我创建了两个表，一个具有自动递增整数“ id”列的“ posts”表，以及一个具有外键“ post_id”的“ comments”表。 然后，我想运行可能是我最常见的查询，即检索帖子及其所有评论。对于关系数据库而言，它是相当新的东西，对我而言，最明显的方法是编写看起来像这样的查询： SELECT id, content, (SELECT * FROM comments WHERE post_id = 7) AS comments FROM posts WHERE id = 7 这会给我我想要的帖子的ID和内容，以及所有相关的注释行，它们整齐地打包在一个数组中（嵌套表示形式，就像您在JSON中使用的一样）。当然，SQL和关系数据库不是这样工作的，它们可以得到的最接近的结果是在“帖子”和“注释”之间进行联接，这将返回很多不必要的数据重复（重复相同的帖子信息）在每一行中），这意味着要花费大量的时间在数据库上以将它们放在一起，也需要花费我的ORM来解析和撤消所有内容。 即使我指示我的ORM急切地加载帖子的评论，最好的办法是调度一个对该帖子的查询，然后进行第二个查询以检索所有评论，然后将它们放到客户端，效率也不高。 我知道关系数据库是经过验证的技术（地狱，它们比我还旧），并且在过去的几十年中，对它们进行了大量研究，我敢肯定，它们（以及SQL标准）旨在按其功能运行，但我不确定为什么上面概述的方法不可行。在我看来，这是实现记录之间最基本关系之一的最简单，最明显的方法。为什么关系数据库不提供这样的功能？ （免责声明：我主要使用Rails和NoSQL数据存储来编写Web应用程序，但是最近我一直在尝试Postgres，我实际上非常喜欢它。我并不是要攻击关系数据库，只是感到困惑。） 我不是在问如何优化Rails应用程序，或如何在特定数据库中解决此问题。我在问为什么SQL标准在我看来违反直觉和浪费时会以这种方式工作。SQL的原始设计者希望他们的结果看起来像这样有一定的历史原因。

46 database  sql  rdbms  query 

从标题可以清楚地看出问题。例如，无论使用何种规模，Apache都将其访问和错误日​​志保存在文件中而不是RDBMS中。 对于RDMS，我们只需要编写SQL查询，它将完成工作，而对于文件，我们必须确定特定的格式，然后编写正则表达式，或者可能是解析器来操纵它们。如果没有给予足够的照顾，在某些情况下甚至可能失败。 但是，每个人似乎都更喜欢使用文件系统来维护日志。我对这些方法都不抱有偏见，但我想知道为什么要这样进行。是速度还是可维护性或其他？

44 sql  history  rdbms  file-systems  rdms 

想要改善这篇文章吗？提供此问题的详细答案，包括引文和答案正确的解释。答案不够详细的答案可能会被编辑或删除。 我看到很多设计都认为标准化不是决策阶段的首要考虑。 在许多情况下，这些设计包括超过30列，主要方法是“将所有内容放置在同一位置” 根据我记得，归一化是最重要的第一件事，那么为什么有时它这么容易掉下来？ 编辑： 好的建筑师和专家选择非规范化的设计，而没有经验的开发人员选择相反的设计，这是真的吗？反对着手规范化设计的观点是什么？

23 design  sql  database-design  relational-database  rdbms 

SQL注入是一个非常严重的安全性问题，很大程度上是因为它很容易弄错：显而易见的，直观的方法来构建包含用户输入的查询，这使您容易受到攻击，而减轻它的正确方法则需要您了解参数化查询和SQL注入优先。 在我看来，解决此问题的显而易见的方法是关闭一个显而易见的（但错误的）选项：修复数据库引擎，以便接收到的所有在其WHERE子句中使用硬编码值而不是参数的查询都返回一个漂亮的，描述性的错误消息，指示您改为使用参数。显然，这需要有一个退出选项，这样管理工具中的临时查询之类的东西仍然可以轻松运行，但是默认情况下应启用它。 这样做将关闭SQL注入冷服务，几乎在一夜之间，但是据我所知，实际上没有RDBMS这样做。有什么理由不这样做吗？

22 security  sql  rdbms 

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 我遇到过许多关系数据库管理系统（RDBMS）。但是最近我使用了休眠模式，这使我开始怀疑为什么面向对象的数据库没有那么流行。 如果像Java或C＃这样的面向对象语言如此流行，那么为什么面向对象的数据库管理系统（OODBMS）也不那么流行呢？

18 object-oriented  database  rdbms 

例如，假设我要获取一个用户及其所有电话号码和电子邮件地址。电话号码和电子邮件存储在单独的表中，多个电话/电子邮件的一位用户。我可以很容易地做到这一点： SELECT * FROM users user LEFT JOIN emails email ON email.user_id=user.id LEFT JOIN phones phone ON phone.user_id=user.id 问题在于，它会为每条记录（用户通过电子邮件发送电话记录）一遍又一遍地返回用户名，DOB，最喜欢的颜色以及存储在用户表中的所有其他信息，这可能会占用带宽并减慢速度降低结果。 那岂不是更好，如果它返回一个单列为每个用户，而该纪录内有一个列表的电子邮件和列表的手机？这也将使数据更容易使用。 我知道您可以使用LINQ或其他框架来获得类似的结果，但这似乎是关系数据库的基础设计中的一个弱点。 我们可以通过使用NoSQL解决此问题，但是不应该有一些中间立场吗？ 我想念什么吗？为什么不存在？ *是的，它是按照这种方式设计的。我知道了。我想知道为什么没有替代方法更容易使用。SQL可以继续做它在做的事情，但是他们可以添加一个或两个关键字来做一些后期处理，这些后处理以嵌套格式而不是笛卡尔乘积返回数据。 我知道可以使用您选择的脚本语言来完成此操作，但是它要求SQL Server发送冗余数据（下面的示例），或者发出多个查询，例如SELECT email FROM emails WHERE user_id IN (/* result of first query */)。 而不是让MySQL返回类似于此的内容： [ { "name": "John Smith", "dob": "1945-05-13", "fav_color": "red", "email": "johnsmith45@gmail.com", …

14 design  sql  rdbms 

通常，在没有自然键的表中，对于用户来说，拥有唯一生成的标识符仍然很有用。如果表具有代理主键（在这种情况下，您一定会希望它具有），该键应该向用户公开还是应将另一个字段用于该目的？ 不公开代理键的原因之一是，现在您不能执行保留记录之间关系的操作，而只能更改键值，例如某些类型的删除/重新插入，将数据从一个数据库复制到数据库的许多方法。另一个等等 公开代理键的主要优点是使用您拥有的字段非常简单。 在什么情况下最好直接向用户公开代理密钥？

14 design  database-design  relational-database  rdbms  surrogate-keys 

背景 我有这张桌子 +-------------------------+ +------------------------+ |Airport | |Country | |-------------------------| |------------------------| |airport_code string (PK) | |country_code string (PK)| |address string | |name string | |name string | +------------------------+ +-------------------------+ +-------------------------+ |Currency | |-------------------------| |currency_code string (PK)| |name string | +-------------------------+ airport_code是IATA（国际航空运输协会）的 机场代码，乘飞机旅行时，您可以在行李标签中看到它们。 country_code是ISO 3166-1 A3标准国家/地区代码，您可以在奥运会上查看它们。 currency_code是IS0 417标准的3个字符的货币代码，您可以在国际货币兑换显示板上看到它们。 问题 这些自然PK是否足够好？ 是否使用世界公认的标准，而整个行业都接受了PK的标准？ 这张桌子是否需要代孕品？

13 design  database-design  relational-database  rdbms  surrogate-keys 

我正在使用PetaPoco微型ORM。使用ORM工具处理数据库确实非常容易且安全，但是我唯一讨厌的是额外的代码。我曾经将大多数代码放在数据库本身中，并使用了所有RDBMS功能（如存储过程，触发器等），这些功能旨在更好地处理。 我想知道何时不对存储过程/触发器使用ORM，反之亦然。

13 orm  rdbms  stored-procedures 

一位程序员正在测试和比较使用相同数据库结构和相同数据的同一应用程序，仅在两个单独的数据库中进行比较，一个数据库使用Oracle 8，一个数据库使用Oracle 9。 该应用程序运行不带 ORDER BY子句的查询。 他声称，ORDER-BY-less查询应在两个数据库中以相同顺序返回行。 我告诉他，除非您明确提供ORDER BY子句，否则不能保证同一行顺序。 该数据库具有相同的索引和键。但是解释计划表明，在其中一个数据库中，引擎使用的是连接表之一的键，而在另一个数据库中，引擎使用的是另一个表的键。 他暗示这两个数据库环境不相等，这是因为它们具有不同的统计信息，不同的rdbms引擎等，但不是因为我未能复制原始数据库具有的每个索引。 我告诉他，ORDER BY如果命令真的那么重要，他必须明确提供一个条款。 问题 所以我可以更好地向他解释： 当您不显式提供ORDER BY子句时，查询以什么顺序获取行，为什么该查询不按相同顺序返回行？

11 sql  oracle  rdbms