Questions tagged «sql»

我真的不喜欢“ NoSQL”这个名字，因为它不是很具描述性。它告诉我数据库不是什么，我对数据库是什么更感兴趣。我真的认为该类别实际上包含数据库的几个类别。我只是想大致了解每个特定数据库最适合的工作。 我想做出的一些假设（并要求您做出）： 假设您有能力雇用任何数量的优秀工程师，这些工程师对已经存在的每种数据库技术都具有同等的经验。 假设您具有支持任何给定数据库（包括可以支持该数据库的可用服务器和系统管理员）的技术基础架构。 假设每个数据库都免费提供最佳支持。 假设您有100％来自管理层的支持。 假设您有无数金钱可以解决这个问题。 现在，我意识到上述假设消除了选择数据库时涉及的许多有效考虑因素，但是我的重点是在纯粹的技术层面上确定哪​​种数据库最适合该工作。因此，考虑到上述假设，问题是：每个数据库（包括SQL和NoSQL）对哪些作业而言是最佳工具，为什么？

31 sql  database  nosql 

我一直在浏览一些著名CMS的SQL转储，包括Drupal 7，Wordpress（一些非常旧的版本）以及一些基于Python的自定义应用程序。 所有这些转储都包含带有字符串标志而不是整数标志的数据。例如，一个职位的状态表示为published，closed或inherit不是1，2或3。 我在数据库设计方面的经验非常有限，并且从未尝试过使用简单的SQL，但是始终有人告诉我，应该对此类数据使用数字/整数标志。显然tinyint，与例如相比，在数据库中占用的空间要少得多varchar(9)。 那我想念什么呢？这不是浪费数据存储和数据冗余吗？如果这些列使用整数而不是字符串，浏览，搜索和索引编制会不会更快一些？

29 database  database-design  sql  strings 

这个问题与SQL和NoSQL之间的区别无关。我正在寻找一些目前对我来说实际上毫无意义的理由（可能是由于我缺乏理解或欣赏）。 我们从头开始使用MVC5，Entity Framework 6代码和SQL Server 2008开始了一个新项目。当架构师检查数据库架构时，声明应该删除所有外键和其他此类约束，因为这是“业务逻辑”，并且应该在应用程序代码的业务层中应用。 我的观点是，外键构成数据/引用完整性的一部分，并不能真正模仿业务逻辑。我将业务逻辑视为控制引用什么/何时/如何/为什么应用引用的过程和验证。我可以理解唯一的约束可以说是业务流程，但是对我而言，这只是逻辑的补充，并构成完整性的一部分。 第二个论点是目标是对数据采用NoSQL方法。我发现这确实是不寻常且不合常规的：考虑到使用SQL Server 2008，报告的需要，数据无法扩展到TB级以及缺乏对诸如Mongo，Raven等技术的考虑。 有人遇到过这种情况吗？为什么有人在为参考数据设计的SQL Server中采用NoSQL方法而不想要外键？

28 sql  sql-server  nosql 

我正在一个项目中尝试在一个标准SQL关系数据库或JSON对象之间存储有关事件或活动的数据。 该项目将存储多种事件类型的数据，因此我决定仅描述此问题的一种事件类型。 现场音乐事件（此问题底部使用JSON模式完整描述）是一个对象，用于存储数据，例如事件发生的地点，事件的时间/日期和事件的成本。现场音乐事件对象具有一对一（事件->名称，事件->描述）和一对多（事件->场所，事件->日期，事件->票证类型） ）关系。此外，事件对象可以包含一个或多个执行者ID，这些ID链接到执行者对象。表演者对象存储有关在现场音乐事件中表演的音乐家的数据。 用户将使用简单数据（“以'x'名称为我查找事件”）和复杂数据（以'x'音乐体裁为'y'事件并在距我当前半径'z'范围内以'y'为代价的事件来查询数据）位置”）查询。数据将由用户使用Web表单提交。 从定义的JSON模式中可以看出，我本来打算使用JSON对象存储此数据，但是我听到有些人说，因为我的数据是纯关系型的，所以我应该坚持使用较旧的方法。 鉴于我的需要，我希望对每种方法的利弊有任何想法。如果您需要任何澄清，请随时询问。 { "event": { "eventID":{ "type":"string" }, "eventType":{ "type":"array", "eventTypeItem":{ "type":"string" } }, "eventName":{ "type":"string" }, "eventDescription":{ "type":"string" }, "eventVenueList":{ "type":"array", "eventVenueListID":{ "type":"integer" } }, "eventURL":{ "type":"string" }, "eventTwitter":{ "type":"string" }, "eventFB":{ "type":"string" }, "eventInstagram":{ "type":"string" }, "eventEmail":{ "type":"string", "format":"email" }, "eventContactPerson":{ "type":"string" }, …

28 design  sql  json 

似乎有很多开发人员通过大写关键字来编写SQL： SELECT column FROM table INNER JOIN table ON condition WHERE condition GROUP BY clause HAVING condition 我想知道为什么人们会坚持这种方法？显然，这是一个由来已久的惯例-但我从未遇到过需要大写的RDBMS 。 就我个人而言，我发现那条呼喊的关键词引起了人们对查询错误部分的注意，这就是为什么我用小写形式写关键词的原因。 尽管如此，仍然有足够多的人使用此约定，我认为我可能会遗漏某些东西，因此是这个问题。

28 sql  history  coding-standards 

作为软件开发人员，我从事过从小型自制应用程序到中型企业应用程序的项目。在几乎每个项目中，我都使用一个数据库，或者后悔从一开始就选择不使用它。 现在，我想知道有关数据库及其在一般应用程序中的用法的一些信息： 为什么Windows本身不使用任何“中央” SQL数据库？例如： 错误报告数据存储在许多文件中， Windows Update将所有内容存储在平面文件中， 图标缓存存储在一个非常奇怪的单个文件中，该文件似乎无法通过SQL等访问。 为什么这么多大型应用程序避免使用数据库？例如，Microsoft Outlook不会通过使用真实的数据库而不是通过使用自己的.pst文件格式并将某些数据存储在注册表中来重新发明轮子而获益吗？ 如果数据库增加了总体复杂性和微小的性能损失，那么在大多数情况下，使代码变得更简单，这是巨大优势的代价，尤其是在存储小的组织化数据块而不是大型二进制数据时流。那么，为什么这么少的产品实际使用数据库呢？我知道的唯一实际使用Sqlite数据库的应用程序是Firefox，也许是Microsoft Exchange（但最后一个不是桌面应用程序）？ 此外，拥有统一的SQL数据库，使部署应用程序，更新/升级数据，在这些应用程序之间共享数据，进行备份变得更加容易，Microsoft Office或Microsoft Expression等应用程序集也不会受益。等等？

28 sql 

我知道INNER JOIN和之间有区别FULL OUTER JOIN，我可以看到，但是以下两个区别是什么：JOIN ... ON...和INNER JOIN...ON...和仍然JOIN...ON...vsFULL OUTER JOIN...ON... 原因是我认为也许只是在使用，JOIN正在搞乱我正在处理的查询，该查询已张贴在SO上，链接到此处的问题。 那么，实际设置操作本身之间的语法差异到底是什么？ 谢谢，

27 sql  sql-server 

至少在SQL中，数据库表名称应为单数，这是一个非常明确的约定。SELECT * FROM user;请参阅此问题和讨论。 RESTful API资源名称应为复数形式，这也是一个相当明确的约定。GET /users/123并POST /users看到这个。 在最简单的数据库支持的API中，URL中的资源名称将是表，URL中的数据元素和请求/响应主体将直接映射到DB中的列。从概念上讲，我认为通过此理论API对数据进行操作与直接通过SQL对数据进行操作之间没有区别。因此，user和之间的命名约定差异users对我来说没有意义。 从概念上来说，当REST API和SQL做相同的事情时，如何证明多元化的合理性？

27 rest  api  sql  conventions  naming-standards 

这是一个开放式的问题，但我想提出一些意见，因为我成长于一个以内联SQL脚本为标准的世界，然后我们都非常了解基于SQL注入的问题以及sql当时多么脆弱在各处进行字符串操作。 然后是ORM的曙光，您在其中向ORM解释查询并让它生成自己的SQL，在很多情况下，这种查询不是最佳方法，但又安全又容易。有关ORM或数据库抽象层的另一个好处是，SQL是在考虑数据库引擎的情况下生成的，因此我可以将Hibernate / Nhibernate与MSSQL，MYSQL一起使用，而我的代码从未更改，它只是一个配置细节。 现在快速发展到今天，Micro ORM似乎正在赢得更多开发人员的支持，我想知道为什么我们似乎在整个内联sql主题上都掉头了。 我必须承认，我确实喜欢没有ORM配置文件的想法，并且能够以更优化的方式编写查询，但是感觉就像我向诸如SQL注入之类的旧漏洞敞开了怀抱，而且我也将自己束缚于一个数据库引擎，因此，如果我希望我的软件支持多个数据库引擎，则需要做更多的字符串黑客攻击，这似乎开始使代码变得不可读且更脆弱。（就在有人提到它之前，我知道您可以在大多数micro orms中使用基于参数的参数，这在大多数情况下都可以防止sql注入） 那么人们对此事有何看法？在这种情况下，我将Dapper用作微型ORM，在这种情况下将NHibernate用作常规ORM，但是在每个领域中的大多数情况都非常相似。 我所说的内联SQL是源代码中的SQL字符串。曾经有过关于源代码中SQL字符串的设计争论，这有损于逻辑的基本意图，这就是为什么静态类型的linq样式查询如此流行的原因，它仍然仅是一种语言，但是在一页中说C＃和Sql现在，您的原始源代码中混合了2种语言。为了澄清起见，SQL注入只是使用sql字符串的已知问题之一，我已经提到过可以通过基于参数的查询阻止这种情况的发生，但是我着重指出了在源代码中根植SQL查询的其他问题，例如缺少DB Vendor抽象以及在基于字符串的查询上丢失任何级别的编译时错误捕获功能，这些都是我们设法通过ORM的高级查询功能来解决的问题， 因此，我不太关注各个突出的问题，而更全局的是，由于大多数Micro ORM使用这种机制，现在再次将SQL字符串直接再次包含在源代码中变得越来越容易被接受。 这是一个类似的问题，它具有一些不同的观点，尽管更多是关于没有微规范上下文的内联sql： /programming/5303746/is-inline-sql-hard-coding

26 database  sql  orm 

一个关于计算器最近的问题引起了有关主键的不变性讨论。我以为主键应该是不变的，这是一种规则。如果有一天某天可能会更新主键，我认为您应该使用代理键。但是，它不在SQL标准中，某些RDBMS的“级联更新”功能允许更改主键。 所以我的问题是：拥有可能会更改的主键是否仍然是一种不好的做法？拥有可变主键有何弊端？

26 database-development  sql 

今天，我浏览了一本有关SQL Server优化的书，看来其中有些想法是基于线性存储模型的。由于SSD具有完全不同的存储模型，它们是否会以任何方式改变人们对数据库调优或优化的看法？

26 sql  database-design  optimization  ssd 

关于性能和最佳资源利用的更好方法是：通过AJAX多次访问数据库以仅在需要时获取所需的确切信息，或者执行一次访问以检索包含所有可能需要的信息的对象。，很有可能实际上并不需要全部吗？ 我知道如何对实际查询进行基准测试，但是当成千上万的用户同时访问数据库时，我不知道如何测试数据库性能方面的最佳选择，以及连接池如何发挥作用。

25 performance  sql 

此问题是从Stack Overflow 迁移而来的，因为可以在Software Engineering Stack Exchange上回答。 迁移 8年前。 根据一个流行的SO帖子，给表名加上前缀被认为是不好的做法。在我公司，每列均以表名作为前缀。这对我来说很难读。我不确定原因，但这实际上是公司的标准。我不能忍受命名约定，但是我没有文档来支持我的推理。 我所知道的是，阅读AdventureWorks非常简单。在这个我们公司的数据库中，您将看到一个表Person，它可能具有列名： Person_First_Name 甚至 Person_Person_First_Name（不要问我为什么看到2x人） 为什么前缀列名被认为是不好的做法？下划线在SQL中也被认为是邪恶的吗？ 注意：我拥有Pro SQL Server 2008-关系数据库的设计和实现。欢迎引用该书。

25 sql 

作为关系数据库程序员（大部分时间），我阅读了有关关系数据库如何不扩展以及MongoDB等NoSQL解决方案如何扩展的文章。由于到目前为止我开发的大多数数据库都是中小型的，所以我从来没有遇到过一些索引，查询优化或模式重新设计尚未解决的问题。 我希望看到MySQL会遇到什么样的大小。多少行？ （我知道这将取决于应用程序和存储的数据类型。让我知道的一个东西基本上是遗传学数据库，因此将有一个主表，带有3或4个查找表。主表将在其中包含其他内容，例如染色体参考和位置坐标。很可能会查询到染色体上两个药水之间的许多条目，以查看其中存储了什么。

24 database  sql  nosql  scalability 

许多Web框架（例如Flask或Django）都使用SQLite作为其默认数据库。 SQLite之所以引人注目，是因为它包含在python中，并且管理开销非常低。 但是，大多数高流量的公共生产站点最终都使用更重的数据库：mySQL，Oracle或postgresql。 问题： 假设： 站点流量适中，并且将同时进行对数据库的读/写访问 我们将结合使用SQLAlchemy和SQLite写锁（尽管此注释使我有些紧张） 该数据库可能包含60,000条记录 数据结构不需要在较重的数据库中发现的高级功能 对于作为中等流量内部公司工具的网站，是否存在令人信服的反对SQLite并发的案例？如果是这样，什么条件将导致SQLite出现并发问题？ 我正在寻找已知的特定根本原因，而不是普遍的恐惧/未经证实的指责。

23 sql  frameworks  scalability  web-framework  sqlite