我的问题是为什么数据库不与绘图、3D 建模、3D 设计、游戏引擎和架构等软件一起使用来保存图像的当前状态或屏幕上存在的内容或项目的一部分数据库。
一个明显的答案是速度，检索或保存所有数百万个构成几何图形的三角形或点的速度非常低，因为每秒会有数百或数千个查询，但这真的是原因吗？考虑到使用数据库的明显优势，当设计保存在一个公共位置时，可以通过网络实时共享设计，并且一次可以有多个人处理它，或者可以使用可以在设计某物时提供实时反馈共享时，特别是使用时间更新的时候，比如每5秒或10秒更新一次，虽然不如实时同步，但应该够快。在这类软件中使用数据库的基本问题是什么导致它们不能以这种方式使用，还是没有开发或研究新的算法或技术来优化以这种方式使用它们的好处？以及为什么没有对这个想法进行大量研究。
您明显的答案是正确的；我不是那个特定领域的专家，但我认为即使从远处你也可以看到这（可能）是主要原因。
这并不能否定此类系统在某些时候会使用数据库的可能性。
考虑到使用数据库的明显优势可以允许在将设计保存在公共位置时通过网络实时共享设计......
没错，但仅仅因为信息被传递并不意味着您必须将其存储在数据库中才能做到这一点。一旦有东西在内存中，你就可以用它做任何事情——不持久化的问题是，如果服务器出现故障/停止/等，你将丢失数据。
我很想看看是否有人有更开明的答案。
简短的回答本质上是速度。将信息写入磁盘驱动器的速度比将信息写入内存要慢一个数量级。网络访问的速度又比写入或读取硬盘慢一个数量级。像您描述的那样的实时共享应用程序确实是可能的，但不一定需要您所谓的“数据库”，使用数据库也不是一个好主意。more 不存在的原因是它们实际上非常难以编程。编程本身就已经够难了，即使只是直线思考，单一的叙述。但要编写这样的程序，您需要能够准确地可视化同时作用于相同数据的多个并行维度，而不会破坏任何东西。这实际上是困难的。
有趣的讨论...我对避免向空间问题或挑战添加过多的“结构”（如在 DBMS 解决方案中的索引、表等中）抱有偏见数据的子集。我认为，如果原始发帖人会从真正需要回答需求/开发解决方案的角度来看待问题......他可能不需要几乎经常查询 DBMS......所以有问题的 DBMS 可能与 3D 相关空间，但实际上是该空间中总值的一小部分……以类似的方式，数字显示器不关心像素（或体素）值的每一个变化，而只关心那些已经发生变化的变化。由于大多数 3D 问题的“刷新率”要低得多