接我上一个回贴： 考虑在存储或失败的时候记入log文件，只能加上人工维护来作为补充了。 或者在纪录上加一个显示控制字段，倘若操作文件时出错，即暂时关闭此字段。避免404 NOT FOUND。这样也还是存在需手动维护的问题，不过还是能尽量减低错误率。
to c_crazyren(楚狂人) 最好减少人工干预的工作，降低维护成本啊。当然，你说的操作文件时出错时的确应该锁定记录，而不像CSDN一样不管三七二十一转向了再说。to Andrawu(Andrawu) 的确，成功后再更新状态会有这种情况，所以才需要一个上级的“系统事务日志”做统一管理。不过有时也想做一个程序天天检查那些状态不对的记录，但是实际试验下来效率实在是太低了……to pengji(彭乃超) and All大家以前做项目的时候有没有什么类似的体会/经验，拿出来说说。 除了使用IBM Content Manager或DB2 + Datalink等软件平台直接解决的…… 是自己开发解决的经验，说说？
begin tran update db rollback and return if fail upload file rollback and return if fail commit so what if a power outage happens when uploading file? the transaction will be rolled back eventually. a garbage file might be on disk. But that's quite trivial though, right?
begin tran update db rollback and return if fail upload file rollback and return if fail commit so what if a power outage happens when uploading file? the transaction will be rolled back eventually. a garbage file might be on disk. But that's quite trivial though, right?
to ajoo(聪明的一猪) 你这么做是不行的，upload file（改成create file好不好，不要一说Content Manager就变成Web Content Manager，就好像一说电子商务就是网上卖东西一样）的时间可能会很长，对于大文件（如媒体文件）可能还需要特殊处理，如果这样的话，这个事务的时间是否有点长的过分啊？如果有多个并发的话，我需要给数据库分配多大的事务日志空间啊。另外我不觉得一个垃圾文件是小事情，我觉得系统应该知道这个垃圾文件，并清除它。这样的系统才是称作强劲的(Strong)系统啊。另外，ajoo(聪明的一猪) ，你看如果这样做的话，你怎么处理更新(update file)这种情况呢？BTW:你不是能输入中文了吗？
when I'm at work. I only have english. only have win2k at my home pc. if add file, really don't think garbage file is a big issue. even db has to do automatic recovery to cleanup garbage at power outage. you can run maintenance job to clean those garbage file up.yes, my approach requires big transaction, that's not necessary. just create file delete and return if fail begin tran update db rollback delete file and return if fail commit tran. for update file, that's a big headache. maybe we can do this: create file delete file and return if fail begin tran update db with the new file name delete file rollback and return if fail commit delete the old file
He he. only when I'm at home with my win2k OS started up can I input Chinese. :)I do feel that garbage file is not a big issue and not avoidable. are you familiar with db's recovery mechanism? it's also leaving garbage log records at events like power outage. of course, db can do automatic recovery at startup. But, for our file, don't think that worth the effort and cost. you can just run some maintenance job to clean up garbage files, not a big deal.Yes, my approach requires a big transaction, and that's not necessary.here's a better one: create file return if fail begin tran update db delete file and rollback and return if fail commit tranfor update file, what about this?create new file return if fail begin tran update db with the new file name delete file and rollback and return if fail commit tran delete the old file
要是非要自动维护，可以学一学db的transaction log. 以下是update fileadd log record saying we are going to replace file f1 with f2 return if fail create file f2 remove log record (or add transaction abort record) and return if fail begin tran update db delete f2 and remove log record and rollback and return if fail add transaction partially done record delete f2 and remove log record and rollback and return if fail commit tran delete f1 return if fail remove log record (or add transaction complete record) and return 以下是automatic recovery, rollback: 1. 找到一个未完成transaction (还没有partially done) 2. delete the file in question roll forward: 1. 找到一个partially done transaction 2. delete f1 3. remove log record(or add transaction complete record)
to leonzhao (灯泡):1、数据库维持数据完整性。数据库中有的文件文件系统中一定有，文件系统中有的文件数据库中可以没有。 无论文件系统中有没有这个文件，如果在数据库中没有，用户都是不可见的。2、由于第一点，所以要求用户请求文件全部通过数据库。3、由于第一点，不用删除文件。4、由于第三点，所以操作时，先操作文件系统，再操作数据库。5、由于三、四，所以修改文件分为拷贝和更新两步。6、为了解决第三点带来的问题，使用服务器端的deamon线程来删除文件。以上（当然这也不是我想出来的，是做项目跟老外学的，现在这种方法在外国很普遍）
to eyeieye(魔之眼) t()的方法就是这样的，这样的方法我还没有想过，老外果然有一堆优秀的设计师to t()第1，2，3条很容易保证，第4条我有些不明白，既然文件系统的文件永远不同步删除对于第4条是否就只是针对添加和更新的，不是针对删除的？ 第5点我持保留意见，我对5的理解是先拷贝源文件，再更修旧文件。拷贝文件的操作开销太大了吧？对于第6点，如果服务器运行正常，一切都好说，如果服务器运行不正常，deamon线程在重新启动之后如何知道它有那些事情还没做需要去完成？to ajoo(聪明的一猪) 是我说的不好，非线编——非线性（视频）编辑系统(Non-Linear Video Editing)，因为处理的文件很大(xG-xxG)，而且这么大的文件还是视频、音频左、音频右、低质量视频分开的，加上相关资源（图片、文字……）一堆，很难保证数据的一致啊。广集思路～
to leonzhao(灯泡):第4条，你说的对。用户操作是删除时，在数据库中删除就可以了，不用操作文件系统。第5条，那也是没办法的事。拷贝-〉更新-〉修改数据库第6条，deamon只需要check数据库中存在的文件，数据库中没有的文件统统删除。regardsT.
t()： "数据库中没有的文件统统删除" is a very very expensive operation! not appropriate for daemon to do it. it could kill the production server.而且，我不认为，删除文件就一定会导致不一致。为什么非要不删除文件呢？我跟leonzhao说的意思是： 能及时删除就删除文件，掉电等突然事件造成的垃圾文件，正象你说的，不造成数据不一致，所以不是大问题。可以由一些维护程序进行定期清除。（但不能是daemon进程）leonzhao: 不懂你说的不一致是怎么回事，只要程序写得正确，不管文件多大，都应该没有你说的问题的。
不过话说回来,如果没有这样的问题,还要系统管理员做什么啊!?
当然如果能根据这样的系统做一个特定的事务到是不错,也就是说,RDB中有该文件的记录文件不能删,文件存在,RDB中的数据也不能删,但真的要这样的话,恐怕只有MS做的出,因为只有他们才有自己的OS呀!
大家说说看有什么好方法能保持数据完整性!?
不过话说回来,如果没有这样的问题,还要系统管理员做什么啊!?
当然如果能根据这样的系统做一个特定的事务到是不错,也就是说,RDB中有该文件的记录文件不能删,文件存在,RDB中的数据也不能删,但真的要这样的话,恐怕只有MS做的出,因为只有他们才有自己的OS呀!
大家说说看有什么好方法能保持数据完整性!?
那么你说这是哪个方面的内容？我找不到才放在这里的。我认为这比扔到数据库专区或别的什么都好一些。
当然如果这个问题又和上次的问题一样没有得到很好的答复的话，我也不能说什么，只能接受这里的高人不多，水平平均偏低这个现实而已。to pengji(彭乃超)
以前我想模仿IBM CM的系统做一个类似的东西，它那个东西对这种事情解决的很好啊。但是发现自己开发难度实在是……
我觉得……系统管理员不应该天天盯着不一致的数据吧……关键就是这种不一致非常不好发现。一旦这种错误的数据被留档后就更麻烦了。
问题就是，我不是很想管那些绕过我的应用对数据直接操作造成的不一致，例如直接删了文件，从RDB中delete了数据等等。但是即使所有的操作全都通过应用走的话仍然有数据不一致的情况。而且，还不能对各种突发情况做特殊处理。不知道各位有什么意见？
这应该是RDB的事务问题,但你说的"即使所有的操作全都通过应用走的话仍然有数据不一致的情况"这应该是可以避免的吧!
以下的建议不知道可不可以避免问题:开始数据库的事务;
存储文件;
if 失败
{
回滚;
return;
}
新增加RECORD;
if 失败
{
回滚;
return;
}
commit;
return;
删除也一样,这样应该可以保持数据的一致性了吧!
存储文件->成功;
增加Record->失败;:回滚文件系统操作
删除文件->失败;我就想不出来然后该怎么办了……
另外如果针对文件系统的操作进行到一半出错，例如更新到一半出错，怎么办？因为更新在进行中，没有事务去回滚修复更新失败的文件啊。自己做个事务控制文件系统？然后还有例如操作过程中机器死掉/没电等等情况，再次启动系统的时候如何对系统做恢复（除了找系统备份以外）？…………BTW:如果照这个思路想下去，很快脑袋就完蛋了……我已经完蛋过了，现在看各位的了！
存储文件->成功;
增加Record->失败;:回滚文件系统操作
删除文件->失败;我就想不出来然后该怎么办了……
另外如果针对文件系统的操作进行到一半出错，例如更新到一半出错，怎么办？因为更新在进行中，没有事务去回滚修复更新失败的文件啊。自己做个事务控制文件系统？然后还有例如操作过程中机器死掉/没电等等情况，再次启动系统的时候如何对系统做恢复（除了找系统备份以外）？…………BTW:如果照这个思路想下去，很快脑袋就完蛋了……我已经完蛋过了，现在看各位的了！
存储文件->成功;
增加Record->失败;:回滚文件系统操作
删除文件->失败;我就想不出来然后该怎么办了……
另外如果针对文件系统的操作进行到一半出错，例如更新到一半出错，怎么办？因为更新在进行中，没有事务去回滚修复更新失败的文件啊。自己做个事务控制文件系统？然后还有例如操作过程中机器死掉/没电等等情况，再次启动系统的时候如何对系统做恢复（除了找系统备份以外）？…………BTW:如果照这个思路想下去，很快脑袋就完蛋了……我已经完蛋过了，现在看各位的了！
if(存储文件){
if(!增加Record){
删除刚存储文件；
返回失败；
}
返回成功；
}
if(删除文件){
if(!删除Record){
怎么办？//增加一个维护机制，检查空联接进行删除
返回删除失败的table、id?
}
返回成功
}偶可能没有接触访问量很大的站点，暂时并没有受此类问题困惑。
if(!删除Record){
怎么办？//增加一个维护机制，检查空联接进行删除
返回删除失败的table、id? //再然后呢？如果这时候锁定本记录的那个用户开始请求这个文件了，怎么办？
}
返回成功
}还有
if(!更新文件成功) //很可能出现的，尤其是比较大的文件。
then 怎么做？文件已经被替换成不完整的了，怎么回滚这次操作呢？
先执行增加记录，然后上传文件。开始数据库的事务;
新增加RECORD;
if 失败
{
回滚;
return;
}
commit;
存储文件;
(可能要很长时间，或断电）
if 失败
{
return;
}1.如果记录保存不成功，文件上传也不会成功。（这种情况是正常的）
2.如果记录保存成功，而可能文件没有上传成功。（这种情况也可能发生）
3.如果记录保存不成功，而可能文件上传成功。（这种情况好象以上代码不可能发生）
4.如果记录保存成功，文件上传成功。（这种情况是正常的）由此针对第2种情况，记录被保存，而文件没有上传，所以只要删除记录就可以了，怎么去确定哪些记录的文件没有上传成功呢?可以用以数据表中记录去遍历文件名，如果文件不存在，则删除该记录。不知以上分析有没有问题，帮忙分析并指出。
更新是最复杂的，就以更新为例：开始系统事务，打开系统事务日志
if 需要更新索引信息 {
开始数据库的事务;
更新RECORD;
if 失败 {
回滚;
return error;
}
commit;
}
开始文件系统操作事务，打开事务日志;
建立新文件;
if 失败 {
回滚系统事务，回滚文件事务;
return error;
}
删除旧文件;
if 失败 {
回滚系统事务，回滚文件事务; //如果这里失败的话系统中就有两个版本了，而且这两个版本还不能通过查询RDB得知这种数据的不一致，我没有想好怎么做
return;
}
commit各种事务;这样的话其实很麻烦的就是这个事务日志我怎么做，怎么去通过这个日志做灾难对抗，同步真个系统。
各位还有没有什么好的建议？
数据最终也是存在文件里的呀.
这和数据库把文件存在什么地方没有关系，和数据库本身的设计有关。
大家还有什么好的方法一起讨论讨论!
考虑在存储或失败的时候记入log文件，只能加上人工维护来作为补充了。
或者在纪录上加一个显示控制字段，倘若操作文件时出错，即暂时关闭此字段。避免404 NOT FOUND。这样也还是存在需手动维护的问题，不过还是能尽量减低错误率。
除了使用IBM Content Manager或DB2 + Datalink等软件平台直接解决的……
是自己开发解决的经验，说说？
update db
rollback and return if fail
upload file
rollback and return if fail
commit
so what if a power outage happens when uploading file?
the transaction will be rolled back eventually. a garbage file might be on disk. But that's quite trivial though, right?
update db
rollback and return if fail
upload file
rollback and return if fail
commit
so what if a power outage happens when uploading file?
the transaction will be rolled back eventually. a garbage file might be on disk. But that's quite trivial though, right?
if add file, really don't think garbage file is a big issue. even db has to do automatic recovery to cleanup garbage at power outage. you can run maintenance job to clean those garbage file up.yes, my approach requires big transaction, that's not necessary.
just
create file
delete and return if fail
begin tran
update db
rollback delete file and return if fail
commit tran.
for update file, that's a big headache.
maybe we can do this:
create file
delete file and return if fail
begin tran
update db with the new file name
delete file rollback and return if fail
commit
delete the old file
of course, db can do automatic recovery at startup. But, for our file, don't think that worth the effort and cost.
you can just run some maintenance job to clean up garbage files, not a big deal.Yes, my approach requires a big transaction, and that's not necessary.here's a better one:
create file
return if fail
begin tran
update db
delete file and rollback and return if fail
commit tranfor update file, what about this?create new file
return if fail
begin tran
update db with the new file name
delete file and rollback and return if fail
commit tran
delete the old file
以下是update fileadd log record saying we are going to replace file f1 with f2
return if fail
create file f2
remove log record (or add transaction abort record) and return if fail
begin tran
update db
delete f2 and remove log record and rollback and return if fail
add transaction partially done record
delete f2 and remove log record and rollback and return if fail
commit tran
delete f1
return if fail
remove log record (or add transaction complete record) and return
以下是automatic recovery,
rollback:
1. 找到一个未完成transaction (还没有partially done)
2. delete the file in question
roll forward:
1. 找到一个partially done transaction
2. delete f1
3. remove log record(or add transaction complete record)
//shy
what is 非线编系统?
无论文件系统中有没有这个文件，如果在数据库中没有，用户都是不可见的。2、由于第一点，所以要求用户请求文件全部通过数据库。3、由于第一点，不用删除文件。4、由于第三点，所以操作时，先操作文件系统，再操作数据库。5、由于三、四，所以修改文件分为拷贝和更新两步。6、为了解决第三点带来的问题，使用服务器端的deamon线程来删除文件。以上（当然这也不是我想出来的，是做项目跟老外学的，现在这种方法在外国很普遍）
第5点我持保留意见，我对5的理解是先拷贝源文件，再更修旧文件。拷贝文件的操作开销太大了吧？对于第6点，如果服务器运行正常，一切都好说，如果服务器运行不正常，deamon线程在重新启动之后如何知道它有那些事情还没做需要去完成？to ajoo(聪明的一猪) 是我说的不好，非线编——非线性（视频）编辑系统(Non-Linear Video Editing)，因为处理的文件很大(xG-xxG)，而且这么大的文件还是视频、音频左、音频右、低质量视频分开的，加上相关资源（图片、文字……）一堆，很难保证数据的一致啊。广集思路～
"数据库中没有的文件统统删除" is a very very expensive operation! not appropriate for daemon to do it.
it could kill the production server.而且，我不认为，删除文件就一定会导致不一致。为什么非要不删除文件呢？我跟leonzhao说的意思是：
能及时删除就删除文件，掉电等突然事件造成的垃圾文件，正象你说的，不造成数据不一致，所以不是大问题。可以由一些维护程序进行定期清除。（但不能是daemon进程）leonzhao:
不懂你说的不一致是怎么回事，只要程序写得正确，不管文件多大，都应该没有你说的问题的。
:)