Rss & SiteMap
Foxtable(狐表) http://www.foxtable.com
贺老师,这个问题希望在下次更新时改一下。
另外还有,您答应用户登录的扩展属性中,增加一个是否保存的选项,希望也也别忘了。
另外,关于设计表结构的问题,再次希望引起您的重视!不管您怎么说,不管这个功能的使用频率高不高,目前的保存方式浪费时间已经是不可争辩的事实,这终究不是好事情,期待您能有好的解决方案!(其实,说句公道话,修改表结构使用频率不算太高,但在设计项目的初期,修改表结构肯定也是很频率的,尤其对于我们菜鸟,我就不相信您能一次性设计表结构不用更改)。
贺老师,这个问题希望在下次更新时改一下。
另外还有,您答应用户登录的扩展属性中,增加一个是否保存的选项,希望也也别忘了。
另外,关于设计表结构的问题,再次希望引起您的重视!不管您怎么说,不管这个功能的使用频率高不高,目前的保存方式浪费时间已经是不可争辩的事实,这终究不是好事情,期待您能有好的解决方案!(其实,说句公道话,修改表结构使用频率不算太高,但在设计项目的初期,修改表结构肯定也是很频率的,尤其对于我们菜鸟,我就不相信您能一次性设计表结构不用更改)。
修改表结构不等于更改列列,前者任务更多,一旦代码落笔,需要计算什么,那个列应该是什么类型,基本已成定局,论坛里真正像您这样一次性修改很多列的寥寥无几,难道您就会把单位设为数值型?把数量设为字符型?这样的道理很简单,我总感觉不应该出现这么大的返工量,您也像贺老师一样,再好好考虑考虑吧,看看到底是哪里出了问题,但这并不是否认您的建议!
修改表结构不等于更改列列,前者任务更多,一旦代码落笔,需要计算什么,那个列应该是什么类型,基本已成定局,论坛里真正像您这样一次性修改很多列的寥寥无几,难道您就会把单位设为数值型?把数量设为字符型?这样的道理很简单,我总感觉不应该出现这么大的返工量,您也像贺老师一样,再好好考虑考虑吧,看看到底是哪里出了问题,但这并不是否认您的建议!
估计程老师又误解了,我说的修改表结构的保存方式,与上午那个贴子是一个意思。我的建议是修改完所有列后,一次性保存,而不是改一列保存一列。
而且,我记得上午的时候程老师还是挺赞成的。