目前，我对MySQL数据库感到有些沮丧，因此我一直在考虑我希望将来在数据库中看到的所有内容。但是我认为听到别人的想法也会很有趣-我绝不是专业人士。

解决方案

回答

云计算可能很有趣
和对象数据库(ODBMS)

回答

你对什么感到沮丧？表现？我认为，如果我们对当前的关系数据库发现的问题更加清楚，我们也许可以进行讨论(尽管这实际上并不是stackoverflow的含义，所以也许更好的问题是"什么是一个功能？当前关系数据库中最缺乏的？")

回答

平面文件！

回答

诸如SQL Server数据服务之类的某些解决方案可能是存储范例的未来

回答

我认为当前数据库使用中缺少的大部分不是数据库本身。它是在与数据库交互的ORM，框架和应用程序中。看到不知道如何利用数据库的功能与数据库进行交互的代码非常普遍。

解决这个问题并尝试回答问题；我认为数据库缺少的是在数据库和使用该数据库的应用程序之间创建实际API的简便方法。 SQL实际上并不是在这里有用的API，因为SQL意味着将应用程序与数据库结构紧密地联系在一起。一个有用的API的示例是为应用程序需要执行的每个动作创建存储过程/函数，但是当前需要在应用程序中进行很多额外的工作。

我还希望看到的是数据库中功能更强大的过程语言，这些语言仍然使与数据库的交互变得非常容易。 Postgres允许我们在数据库内部使用Perl和Python之类的语言，但是与plpgsql中的语言相比，该语言与数据库之间的交互还不那么干净和容易。另一方面，plpgsql不是一种非常强大的语言。唯一真正的好处就是与数据库进行交互的难易程度。拥有更强大的plpgsql之类的东西将使创建数据库API(至少在数据库方面)更加容易。

回答

WebCould是另一项新技术。云计算将改变我们处理后端系统的方式，或者在大多数情况下，我们可能不需要为下一代(支持云的)应用程序提供数据库。

当然，我不是在谈论企业级业务应用程序。

回答

放弃SQL并正确实现关系模型！

回答

分贝：当我们说它们不知道如何与数据库进行交互时，我们将具体讨论哪些ORM和框架？与许多人一起工作时，我很想听听意见。

回答

当前数据库系统(imho)的最大问题是，我们必须考虑数据库系统的表和结构。我们不能在对象中工作或者直接保存它们(是的，我们可以在对象上方和周围构建抽象)。我认为数据库的未来可能会以对象为中心(像序列化)。我想花更多的时间来考虑问题空间对象，而不是应该如何将其标准化为关系系统...

回答

根据应用程序的不同，我们可以使用全文本搜索引擎(apache lucene / apache solr)存储数据。使用此解决方案，我们可以配置为哪些"列"或者数据字段建立索引，并且只需一次调用即可搜索所有字段。不再根据数据对象中的属性值生成sql语句。

另外，如果要向数据索引(或者存储)添加其他字段，则只需添加字段并重新索引即可。我们可能无需更改任何代码即可在搜索中添加其他字段。

这些全文搜索引擎通常内置某些类型的分页系统也很方便。

回答

我希望我可以说OODB，但没有OODB真正在市场上取得突破。

回答

时态数据库将是不错的。
不再需要花时间手动加入。
也可以进行自动审核。叹。

对于进度预测/报告...。那不是很好。

我自己有一个开放的bug可以实现诸如准确的进度条之类的东西。
我将记录命令对象的执行时间。
我们还将记录参考系统的命令执行时间，因此用户可以查看是否"似乎有问题"。

我要做的就是以一种整洁的方式对查询进行参数化，以预测GUI的执行约束。也许是多项式。在理想世界中，它可能会自动适应实际数据。

(我已经做过类似的事情来预测打印进度。)

回答

我更喜欢Oracle，并认为MySQL是一个玩具数据库，尽管MySQL具有(很少)Oracle中不存在的有用功能。

我最喜欢的功能是PL / SQL，这是一种非常强大的编程语言，可用于存储过程，触发器和"包"，过程单元以及数据库中的其他内容。同时，我倾向于编写大部分在数据库内部进行海量数据处理的代码，而无需在Db和应用程序之间进行昂贵的交互。

我不认为我们会很快转向面向对象的数据库，因为关系数据库可以很好地满足90％的所有应用程序的需求，并且可以使其余的应用程序工作。

顺便说一下，Oracle支持平面文件，如Shog9在此处所要求的。我们可以将它们安装为"外部表"。我已经将其用于海量数据导入，效果很好。

回答

未来的数据库将在很大程度上取决于需求。我认为，与使用经典关系数据库相比，我们将看到更广阔的前景，更多的选择余地。新技术，例如用于连续实时查询的数据流管理系统，用于存储以文档为中心的文档的XML数据库，列存储，数据仓库等。

但是关系模型还远未结束。最好是提供更多有关挫败感的详细信息，以便我们找到问题的未来，而不仅仅是整个数据库的范围。

回答

未来不会出现在SQL上，它是功能语言受损的最低公分母。好的，至少它是某种标准化的。

尝试使用对象流行度(cl-prevalence，Hibernate)或者磁盘上的对象数据库(例如Elephant)。

回答

我将答案一分为二：

从概念层面(关系模型)

一阶谓词演算，其中的关系代数是不会消失的。从概念上讲，这种代数在形式化任何"对象模型"，层次结构和网络数据结构方面没有问题。
这里的改进空间仍然存在，它朝着更高阶的逻辑和类型理论发展。

这与平面文件，xml，SQL，对象，ORM或者任何实现细节无关(也永远不会)。这个事实非常重要(SQL是基于关系的，但是SQL不等于关系；即使SQL失败，关系代数的概念也会成立)。

从使用角度(SQL数据库管理系统)

SQL数据库管理系统具有许多可以改进的领域。

数据库系统的最初卖点是让数据库决定如何存储和检索数据仍然是一件好事，但是(平均而言)它无法识别使用场景的广泛程度(使用MySQL的唯一原因是，在适当的时候它意识到有一个整个行业对数据的完整性和一致性并不在乎；在历史上，SQL数据库实际上主要是数据捕获系统，人们没有意识到主要是读取型系统变得多么重要。
索引(或者更广泛地说，数据存储和检索)应该比当前更具灵活性，从而可以优化以下任何一项：读取速度，写入速度，一致性，持久性(在内存事务中)，原子性，完整性以及非常精细的粒度和详细信息(尤其是在读写方案下)。

即使差异不是很大，对象关系集成也可以有很多改进。从本质上讲，数据库实体是对象，因此它主要归结为工具。 (大多数ORM的问题都在那儿，因为很多人不确定他们的对象类是行还是表)

时态数据库管理系统绝对更接近我们人类存储我们处理的数据的方式。在这方面，最好在数据设计和管理的每个级别上达到更高的人机工程学水平。支持完整历史记录并自然地与时间概念和时间相关的操作配合使用的任何系统的可用性都在大大提高。

这个时间方面不仅适用于数据，而且适用于元数据，包括完整性规则。

同样，数据和元数据的分离有点过分强调，或者换句话说，设计数据库系统(并维护它们)是对元数据的操作，因此，如果使用与常规数据(在我看来，这指向高阶逻辑)。

为此，数据库管理系统需要对表达式进行更强大的符号操作，这再次指向诸如lambda演算之类的概念。

不幸的是，由于数据和系统惯性(成本)，SQL标准不太可能发生巨大变化，直到可以证明或者至少提出足够的节省为止。

回答

我认为NoSQL数据库表明，数据库的未来将比现在更加异构。关系数据库无论从短期还是长期来看都不会消失。毕竟，如果数据与经济数据一样是自然的关系数据(即表格数据)，则关系模型非常方便。

但是，对于某些类型的数据：层次结构，多对多关系等，关系模型的用处不大。或者，它很有用，但是数据库模型变得相当扭曲。那就是键值存储，文档数据库，图形数据库的所在。

通常，组合可能是最有效的。暂时简化一下，我们通过两种方式使用数据库：

• 存储数据(并通过ID /主键检索)
• 搜索数据

关系数据库可以做到这两者，但是根据数据的结构，两者可能都不是很好。在这种情况下，使用文档数据库进行存储和使用外部搜索索引(如Lucene)进行搜索可能会更好。

不幸的是，我认为语义数据库(又名三重存储和关联数据库)不会得到广泛使用。但是，如果我在这里做错了，那就更好了，因为关联数据模型是IMO最直观和最具表现力的。