或许你觉得这样的方式读取数据库会更快一些
    我现在需要做一个MRP运算，他的结构大概是这样的。

      电动车
轮子  发动机 电池 外壳 。。。

递归解析：轮子由外胎 内胎组成
             外胎又由：塑料 + A 组成
                 塑料又由 B 和 D组成
                     B 由。。。。。。。。。。。。
现在我需要计算的动作是：生产 电动车A，电动车B，电动车C 
  总共需要多少物料，是什么物料？
  现在仓库里面是否有这样的东西可以用？
  我需要采购多少？

物料结构如此深不可测的递归下去，问我的数据库应该怎么设计才合理？
怎样才能查询的速度？

当然现在有更悲催的事情。

因为计算错综复杂，所以我需要选择两条路：
1、程序代码计算。
    优点：维护容易，代码易读。
    缺点：需要从数据库先读到内存再进行计算，本身速度已紧缺。
2、数据库代码计算。
    优点：计查计算。
    缺点：恶心的代码，估计得是两三页密密麻麻的货。还有那坑爹的游标等等。

程序代码抉择之路：
   1、将整个物料结构表读取到内存中，再执行计算
       优点：减少对数据库的查询，减少服务器压力，也加快运算速度。
       缺点：
         1.1 需要消耗一定的内存。
         1.2 在加载表到内存也需要时间。
         1.3 我不敢我在本地的数据能与数据库查询相媲美，当然会比数据库查询慢多了
   2、解决加载表需要时间：在开机时将表加载到内存中，等待运算。
       优点：削弱运算时时间
       缺点：加大开机时间和一直保持内存占用

数据库运算抉择之路：
   1、除了代码恶心 一切安好



求高手解答，为小抉择。 或提供更好的解决方案，我愿以身相许

                                                       -- 654635195


------解决方案--------------------

引用:

2、解决加载表需要时间：在开机时将表加载到内存中，等待运算
这句是恶心的错。。。Sorry啊！！

不能这么做，因为数据是动态的！

前提你的内存要足够大。听说微软下一个SQLServer（不是2012）是内存数据库。对于MRP，要考虑业务，而不是如何用程序去实现。一般的慢主要在报表，这时候可以考虑用空间换时间，即把一些可以不实时运算的数据冗余。
------解决方案--------------------

引用:

引用:
引用:2、解决加载表需要时间：在开机时将表加载到内存中，等待运算
这句是恶心的错。。。Sorry啊！！

不能这么做，因为数据是动态的！前提你的内存要足够大。听说微软下一个SQLServer（不是2012）是内存数据库。对于MRP，要考虑业务，而不是如何用程序去实现。一般的慢主要在报表，这时候可以考虑用空间换时……

有个叫bom结构的，你去了解一下是否合适你们的业务。
------解决方案--------------------
把SAP的数据库导出来研究研究。