为什么数据库不与 3D 和绘图软件一起使用（用于存储点和其他原始形状）？
我的问题是为什么数据库不与绘图、3D 建模、3D 设计、游戏引擎和架构等软件一起使用来保存图像的当前状态或屏幕上显示的内容或项目的一部分数据库。
一个明显的答案是速度，检索或保存构成几何形状的所有数百万个三角形或点的速度非常低，因为每秒会有数百或数千个查询，但这真的是原因吗？考虑到使用数据库的明显优势，当设计保存在公共位置时，可以允许通过网络实时共享设计，并且不止一个人可以同时处理它，或者可以在设计某些东西时提供实时反馈当它被共享时，特别是当使用基于时间的更新时，例如每5或10秒更新一次，这不如实时同步，但应该足够快。在此类软件中使用数据库的基本问题是什么导致它们不以这种方式使用，或者没有开发或研究新的算法或技术来优化以这种方式使用它们的好处？以及为什么这个想法没有得到很多研究。
My question is why Databases are not used with Drawing, 3D Modelling, 3D Design, Game Engines and architecture etc. software to save the current state of the images or the stuff that is present on the screen or is the part of a project in a Database.
One obvious answer is the speed, the speed of retrieving or saving all the millions of triangles or points forming the geometry is very low, as there would be hundreds or thousands of queries per second, but is it really the cause? Considering the apparent advantages of using databases can allow sharing the design live over a network when it is being saved at a common location, and more than one people can work on it at a time or can use can give live feedback when something is being designed when it is being shared, specially when time based update is used, such as update after every 5 or 10 seconds, which is not as good as live synchronization, but should be quick enough. What is the basic problem in the use of Databases in this type of software that caused them not to be used this way, or new algorithms or techniques not being developed or studied for optimizing the benefits of using them this way? And why this idea wasn't researched a lot.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
简而言之，答案本质上是速度。将信息写入磁盘驱动器的速度比写入 RAM 慢一个数量级。网络访问的速度又比写入或读取硬盘慢一个数量级。像您所描述的那样的实时共享应用程序确实是可能的，但不一定需要您所说的“数据库”，使用数据库也不是一个好主意。更多不存在的原因是它们实际上非常难以编程。编程本身就已经足够困难了，即使只是用单一的叙述直线思考。但要进行类似的编程，需要您能够准确地可视化同时作用于相同数据的多个并行维度，而不会破坏任何东西。这其实是很难的。
The short answer is essentially speed. The speed of writing information to a disk drive is an order of magnitude slower than writing it to ram. The speed of network access is in turn an order of magnitude slower than writing or reading a hard disk. Live sharing apps like the one you describe are indeed possible though, but wouldn't necessarily require what you would call a "database", nor would using a database be such a great idea. The reason more don't exist is that they are actually fiendishly difficult to program. Programming by itself is difficult enough, even just thinking in a straight line, with a single narrative. But to program something like that requires you to be able to accurately visualise multiple parallel dimensions acting on the same data simultaneously, without breaking anything. This is actually difficult.
你的答案显而易见是正确的；我不是该特定领域的专家，但我认为即使从远处你也可以看到这（可能）是主要原因。
这并不否定此类系统在某些时候使用数据库的可能性。
确实如此，但仅仅因为信息被传递并不意味着您必须将其存储在数据库中才能做到这一点。一旦某些东西在内存中，你就可以用它做任何事情 - 不持久的东西的问题是，如果服务器失败/停止/等，你将丢失数据。
我有兴趣看看是否有人有更开明的答案。
Your obvious answer is correct; I'm not an expert in that particular field but I'm at a point that even from a distance you can see that's (probably) the main reason.
This doesn't negate the possibility that such systems will use a database at some point.
True, but just because the information is being passed around doesn't mean that you have to store it in a database in order to be able to do that. Once something is in memory you can do anything with it - the issue with not persisting stuff is that you will lose data if the server fails / stops / etc.
I'll be interested to see if anyone has a more enlightened answer.
有趣的讨论...我对避免向空间问题或挑战添加太多“结构”（如 DBMS 解决方案中的索引、表等）存在偏见，而这些空间问题或挑战超出了那些无法轻松地从更小的模型中重新创建的问题或挑战数据的子集。我认为，如果原始发帖者会从真正需要回答需求/开发解决方案的角度来看待问题……他可能不需要经常查询 DBMS……所以有问题的 DBMS 可能与 3D 相关空间，但实际上是该空间中总值的一小部分......以类似的方式，数字显示器并不关心像素（或体素）值的每个变化，而只关心那些已更改的变化。由于与视频显示相比，大多数 3D 问题的“刷新”率要低得多，因此 DBMS 上的点击频率可能不足以使 3D DB 看起来“实时”。
Interesting discussion... I have a biased view towards avoiding adding too much "structure" (as in in the indexes, tables, etc. in a DBMS solution) to spacial problems or challenges beyond those that cannot be readily recreated from a much smaller subset of data. I think if the original poster would look at the problem from what is truly needed to answer the need/develop solutions ... he may not need to query a DBMS nearly as often... so the DBMS in question might relate to a 3D space but in fact be a small subset of total values in that space... in a similar way that digital displays do not concern themselves with every chnage in pixel (or voxel) value but only those that have changed. Since most 3D problems would have a much lower "refresh" rate vs video displays the hits on the DBMS would be infrequent enough to possibly make a 3D DB look "live".