flutesultan on Fri, 23 Sep 2005 21:18:57 -0500 (CDT) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
RE: [s-d] Generic Document storage |
When from left field a question comes, chase the ball I must. I'll preface by stating that it has been long and long since I've dealt with large database systems. Back in the late 70's and early 80's, I worked extensively with DB2, DB3 and DB4 as they evolved, and later with Foxpro until it was absorbed into the Office suite by his Gatesness. I've designed and written code to support entire two-line accounting packages for business, and database management for large amounts of data does require a degree of format standardization. A few questions arise. 1) Is server space to support this evolution a non-issue? (I'm thinking 2x to allow for conversion). 2) Will scripting code become more or less complex in implementing access to stored documents, whether for viewing or alteration? 3) How swiftly will rule changes that impact the form of documents be able to implemented? 4) Will some level of immutability be required in evolving to this standardization? >A really ambitious project would be to then import all of B Nomic's >history into this system... I'd have to agree with that. Moreover, it seems the likely test as to the functional feasability of such an undertaking. >Right now we have a single Rulebook with all the rules in it. We also >have a couple other types of Game Document floating around, like Props, >Talisman definitions, etc. An illustrative set of examples. Props are quite like Rules, but require a field for Owner. Talismans and House Rooms are not, though could be made so to allow for revisions to Effects or Ordinances, etc. The larger question, I suppose, is: "Is management of the existing system progressing in a downward spiral?" If countinuing to add a foreseeable plethora of document types to the standing database will introduce unforeseeable gremlins, then a formal standard format seems the way to go. If that entails a one-time delay to implement, it's preferable to many short term 'kludgings' in the long run. Triller _______________________________________________ spoon-discuss mailing list spoon-discuss@xxxxxxxxx http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss