FLAT FILE <--> DB RELATIONSHIP


    In order to minimize the impact of RATS V2, rather than customize everything to work with RATS's interface to the client side DB, the DB will be integrated into the UNIX system as much as is possible with "glue" that is well understood by UNIX tools in general. In this iteration of RATS, the glue will be the standard UNIX flat files. The flat files will be used to initially populate the database, and they will be the means by which a lot of system components gain access to the data stored in the DB. Although this might seem self defeating at first, it isn't. The DB will periodically dump its contents into the standard flat files (probably at user definable intervals). Since they will not have an altered format, anything that simply reads these files should be unaffected by the data being stored in the DB. However, these files will never be fed back into the DB after the initial load except under catastrophic failure conditions. Since these files are really write-only as far as the DB is concerned, anything that writes to these files will need to be replaced or altered to understand how to speak to the client side DB.  As far as the flat files are concerned data will be pushed from the back end to the front end. At first this seems to go against the grain of the general design of RATS V1. Server pushes do indeed go against the RATS model, and that model will not change. The part of the RATS model that is changing is that lots of small real time updates are being redirected to something better suited to deal with them (the DB), and all those small updates are then replaced with one big scheduled update at periodic intervals as far as the system is concerned (which is something it can deal with better). Rather than add a server push of data, what we are really building is an accumulation buffer for lots of little client pushes, and making it look like one big client push. Although this solution isn't completely transparent as most would like, it should be feasible to implement. It could also be used in the future to feed ypmaps or LDAP with some work. In addition, if the industry standardizes
on a better method for account management than the standard UNIX flat files, the flexible generic abstraction of data provided by a real database should ease the transition to this new method. The current design is only as compatible with LDAP as much as the standard unix flat files are. LDAP support can be implimented in the future in a more robust manner if it is needed. As LDAP appears largely to present data about a person that is beyond the scope of any one subsection of RATS, it is probably outside rats to present this data. This statement however is far from final as LDAP's role at the university is at best ill defined currently. Should we determine the proper use and scope for LDAP at the university, I am sure RATS role and functionality can be altered in kind.