您觉得SQL存在哪些不足之处？您会对它做出哪些改变？
您在使用SQL时遇到过缺陷，限制或缺陷吗？
使用其他非SQL语言很容易完成的任务是如此复杂或无法用SQL做到的！
这是一个很好的例子
您能否向我提供您遇到的问题的案例，或者例如SQL查询需要复杂结构的情况？ 人们陷入的一个陷阱是认为所需的解决方案必须适合单个SQL语句。
您能否提出改进建议使SQL更强大，更简单？ 示例：PSM
您认为哪种SQL实现最强大？
您希望在SQL中实现哪些非SQL环境function？
我们假设SQL不存在，你会用什么操作数据？
就个人而言，我对CODASYL数据库情有独钟，您可以在其中访问数据集以访问相关数据元素…也许是因为我对数据库的第一次体验是DECs DBMS。 找到父记录，然后简单地走一组孩子的能力很容易使用; 并且在基础数据库结构中构建的数据集之间的显式关系是关系数据库中可悲的缺点……并且在任何人提出之前，外键是该关系的苍白，一维的阴影。
SQL中内/外/直接连接的复杂性变得不相关，因为数据集的结构维护不同记录集（表）之间的关系，允许您仅访问相关的那些数据集记录。 查找订单和行走OrderLine数据集将仅返回作为该订单一部分的订单行，而无需制定第二个查询以从所有订单的整个订单行表中检索该系列行。
缺点是几乎所有的设计都需要预先完成……一旦设计了数据库结构，它几乎是固定的，难以改变….与RDBMS相比，在任何时候都可以更容易地添加新表….不是特别适合RAD / Agile / XP / Scrum的世界。
现在，如果只有某人能够提出一个数据库系统，其结构像RDBMS一样灵活且易于更改，并且具有CODASYL数据库的所有数据访问的简单性。
OLAP数据库是RDBMS的另一个很好的替代方案，其中数据可以很容易地构建为n维立方体，其中查询允许您“切片并切块”立方体，快速提取数据段。 我对OLAP的第一次介绍是Oracle Express，它（不幸的是）使用自己的专有查询语言而不是事实上的标准MDX。 但是，并非所有数据都可以轻松地安装到“立方体”结构中，因此它仅适用于某些应用程序类型 – 尽管几乎所有数据挖掘应用程序都非常适合。
SQL通常作为数据库语言存在一些严重的缺陷。 只有一些问题是：
-
重复行（多组而不是基于集的模型）
-
空值和三值逻辑会增加复杂性，模糊性和不一致的结果，而不会给语言增加任何表达能力
-
SELECT语句语法比关系代数更冗长，更复杂
-
缺乏对多重分配的支持意味着参考完整性支持和对约束的支持总体上受到严重限制
SQL中很难解决的两个更具体的查询问题的例子：
-
SQL中的传递闭包没有简单的等价物。 因此，从邻接关系结构中进行选择需要使用过程代码，游标或非直观且难以优化的递归查询语法。
-
缺乏密钥inheritance意味着SQL查询接口总是返回简单的二维表，这是本质上是n维的查询支持（OLAP）类型查询的主要缺点。
改进？ 我不相信有任何有用的改进是有意义的，因为修复上述内容会彻底改变语言，甚至假装它不再是SQL就没有多大意义。 我相信最好的方法是开发全新的，真正的关系语言。 日期和Darwen的D模型是SQL最明显的inheritance者，已经导致了许多关系语言的新实现。
为了增加@dportas的优秀答案，对我来说SQL中的“错失机会”是建议的时态扩展，称为TSQL2，从未进入SQL标准。 因此，即使使用Full SQL-92，时态数据库也很难正确，例如，当有效状态表中的序列删除需要四个语句（ INSERT ，两个UPDATE和一个）时，多个赋值将是一个福音。 DELETE ）。 当您考虑到大多数供应商缺乏对SQL-92function的支持时（例如，SQL Server缺少DEFERRABLE约束，Oracle缺少CHECK约束中的子查询等），如果没有“最差”类型的过程代码，几乎不可能实现。
从数据操作语言的角度来看，SQL有一些缺点：
- 没有标准的SQL方法来使用正则表达式。 数据约束通常以正则表达式的forms表示，并且在SQL中使用标准的正则表达式语言非常有用。 我知道SQLite允许你放入自己的正则表达式引擎，我确信其他数据库也可以这样做，但是标准的数据库会很好。
- SQL需要SQL中的命令式编程语言，语言结构包括变量和变量赋值，词法闭包和迭代器。
- SQL需要一种标准方式来表达可在查询中使用的用户定义函数。
我认为这将有助于它作为关系数据操作语言。 对于其他类型的数据，SQL还不够好。
神奇的答案，dportas 🙂
虽然不是那么迷人，但我希望在SQL标准中使用的是“INSERT OR UPDATE”约束冲突解决算法。 MySQL和SQLite将其实现为SQL标准的扩展 。
这个IMO应该是内在的数据库引擎function，否则你会纠结于：
IF (record_exists) THEN -- update record ELSE -- insert new record
这似乎微不足道，但它
- 促进复制/粘贴代码块等坏习惯
- 介绍错误和
- 只是浪费你的时间，很多次。
- 它还增加了可维护性的负面影响。
两个查询可以很容易地替换为一个：
"Insert OR Update Table (field = value) Where ID = @ID"
感觉更自然:-)
您在使用SQL时遇到过缺陷，限制或缺陷吗？
很多： http ： //c2.com/cgi/wiki？SQLFlaws
你能用不同的DML或编程语言轻松完成同样的任务吗？
我相信答案是肯定的。 第三个宣言描述了我们应该使用什么而不是SQL： 教程D.
您能否向我提供您遇到的问题的案例，或者例如SQL查询需要复杂构造与其他方面的简单构造的情况？
是：例如，在SQL中重命名列。 假设我有一个包含此列的表：a，b，c，d，e，f，g，h，我现在，说我想将列a重命名为“X”。 在SQL中我需要写：
SELECT a as X,b,c,d,e,f,g,h,i FROM SomeTable
在教程DI中只写：
SomeTable RENAME ( a AS x)
或者让我们反过来看看，这个Tutorial D查询的等价物是什么：
SomeTable REMOVE (e)
嗯，很难找到丢失的“e”..不是吗？）：
SELECT a,b,c,d,f,g,h,i FROM SomeTable
或者简单地告诉我，用什么代码更容易理解开发人员的意图：
SELECT a as X,c,d,e,f,g,h,i, g+h as z from SomeTable
或者用这个（它是相同的查询！）：
SomeTable RENAME (a AS X) REMOVE (b) ADD (g+hz)
看到？ SQL 存在缺陷核心！ 或者简单地尝试从存储过程调用中编写select *。 根据数据库的不同，它可能不起作用
您能否提出改进建议使SQL更强大，更简单？
许多，用Tutorial D或Dataphor之类的东西替换它
您认为哪种RDBMS / SQL产品实现最强大？
强大的伪RDBMS ？ Oracle，DB2和SQLServer。 强大的RDBMS？ 没有了。 也许Dataphor或Rel将成为第一个…所有其他人都无权被称为“关系”
您希望在SQL中实现非SQL环境的哪些function？
我的梦想是有一天看到一个正确的关系实现…但是目前我很高兴如果任何数据库完全实现了SQL标准（没有）
我们假设SQL不存在，你会用什么操作数据？
我将阅读第三个宣言，并实施它。 或者使用DataLog或Genexus 都可以为您提供访问路径独立性 ，Genexus甚至可以为您提供Normalization By Synthesis ，超出SQL的范围。
或者，最近， ODATA查询 （但遗憾的是，ODATA分享了SQL的一些弱点）