引用详细内容：

1，M区对于绝大多数人来说足够大，使用M区恰恰为了是结构更简单而不是很乱，M区定义好符号表后，直接使用符号很方便，用DB是极度不方便的。比如有100个Motor，对应一百个fault，每个项目类似单不完全一样，所以有些注释需要跟着改变。那么实际应用的时候，需要找到motorXX，我就在goto location那里输入motorXX，就能直接找到了，你用DB试试怎么输入，无论如何要逼用M区复杂得多。当需要修改注释，我在原地就可以修改，不需要离开编程的位置，DB可以吗？不可以！而且使用DB会导致符号很长，因为DB的名字是必须的，加上每一级struck都要增加个“.”，结果就是注释太长，程序很难看。

2，DB+UDT绝对没有想象的那么好用。修改完udt回到DB的时候需要重新update，工作量不见得小，有的FB引用了UDT经常会出错，工作量更大

3，DB可以实现的复杂数据类型，基本上用M区都可以替代，只是少了个名字而已，但是用起来更方便，因为他是绝对地址寻址，比如Any数据类型，M区可以很方便地定义每一个位置，不知道那里比DB不方便？

4，FC的out参数，如果程序内部不方便初始化，或者使用s/r，或者程序有跳转，用DB作为实参是会出问题的，而用m区不存在这个这个问题。

5，编程习惯就对了，你有你的习惯，别人有别人的习惯，每个人都有自己的规划方式，并不代表哪个更好。为何用M区就叫狗皮膏药？如果M区这么不好，西门子干嘛不取消掉？

6，问你个问题，假如程序有100个报警，用M区存储可以采用名字为A001--A100，采用DB的话最简洁的就是"F".A001--"F".A100。当这些报警显示在HMI上的时候，现在的维护人员如果最快速在程序上找到这个报警的位置？假如用户使用的不是wincc，并不能直接从HMI跳转！