今天遇到的麻烦是前两天设计考虑不周详导致的。
在传统的设计思路中,留给后期运行时可以扩展的部分通常交给数据库的存储过程实现。
例如:保存某数据时,对数据的检查。获得某数据时,对数据的格式化等等。
我一开始设计时也是如此考虑的,在设计数据保存表时,考虑了保存、检查、获取记录时可以选择的额外处理:
CREATE TABLE IF NOT EXISTS TCI_TYPE
(
FCITYPEID INT UNSIGNED,
FCISERIAL INT UNSIGNED,
FCISUBTYPE INT UNSIGNED,
FCIITEMTYPE INT UNSIGNED,
FEDITABLE INT UNSIGNED,
FDISPLAYTYPE INT UNSIGNED,
FISNULL INT UNSIGNED,
FMINLEN INT UNSIGNED,
FMAXLEN INT UNSIGNED,
FDISPLAYX INT UNSIGNED,
FDISPLAYY INT UNSIGNED,
FGETDATA VARCHAR(255),
FSETDATA VARCHAR(255),
FCHKDATA VARCHAR(255),
FCINAME VARCHAR(255),
FCITAG VARCHAR(255),
FCIREMARK VARCHAR(255),
FCIDEFAULT VARCHAR(255)
) ENGINE=InnoDB;
call sp_dropindex("TCI_TYPE","IND_TCI_TYPEID");
CREATE UNIQUE INDEX IND_TCI_TYPEID ON TCI_TYPE(FCITYPEID,FCISERIAL);
如上表中,FGETDATA,FSETDATA,FCHKDATA,即为获取本记录,设置本记录,检查本记录时所应当做的额外处理。
在最初的设计上,是考虑执行mysql的sp来完成此工作。
比如,如果FGETDATA填写一个sp的名字,这样,获得这条记录时,执行sp,然后用sp返回的值作为显示值展示给界面,
界面修改后,保存时,在执行FSETDATA的sp(如果有),进行保存。
设计这个的初衷,就是为了让获得、保存记录时,能够用sp的灵活性,基于其他数据(全局数据库内、本表的其他数据)进行判断和处理。
这样设计本是没有问题的----如果所有的数