From: Mark D. <mj...@ge...> - 2009-04-22 20:58:01
|
During the development of TB2 there have been several times when I wished that each database table had an extra scratch column. While checking and correcting the migration from TB1, I often found myself maintaining and merging lists of object ID numbers. For example, I might have a list of objects which needed to be checked, another list of objects which were found to be erroneous, and so on. Rather than maintaining a bunch of text files with object ID numbers, it would have been much more convenient to be able to store this information in the database itself. Or another example: I have written a garbage-collection utility that identifies and removes inaccessible objects from the database. The easiest way to do this is with a mark-and-sweep algorithm: first mark all the known reachable objects, then all the objects reachable from those, and so on; then make a second pass and delete all the unmarked objects. But to implement this requires storing the mark somewhere. At present, the utility program keeps an external record of which objects have been marked. Storing the marks in the database would be much simpler. It would require a small change to the code to add an additional field to every persistent object table to enable this sort of use. The obvious time to do it would be at the time the tables are created at NESCent. The obvious drawback is that it takes up storage. (There are 3e08 matrix element objects.) Is this a bad idea for some non-obvious reason? |