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