Likewise, there are a number of packages that had wise developers who separated relatively static globals from relatively dynamic globals. We really didn't get into that habit until the mid 80's. The two globals that grow the fastest and largest are the Orders and the Notes.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of smcphelan Sent: Tuesday, June 21, 2005 4:55 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] VistA global variable partitioning Having things spread across multiple partitions (or namespaces or volume sets or whatever) does increase the management complexity of the system. However routines and business logic will see a VistA database set as one virtual database. Thus the tight integration is not an issue. Now if you are talking about system management issues that is another concern. But those system management concerns overtly do not have any effect upon executing business logic unless you poorly design that database set. Bhaskar, I assume you have large bank customers. I also assume they have multiple database partitions because putting all data in a single database can lead to performance issues. Is this correct? If so, the reasoning behind having multiple partitions for the large banks is similar to the logic for having multiple partitions for a sizable VistA system. Of course whether to partition or not would be platform dependent. How I configure VistA to run on some Dell servers would be different than running VistA on a mainframe. ----- Original Message ----- From: "K.S. Bhaskar" <[EMAIL PROTECTED]> To: <hardhats-members@lists.sourceforge.net> Sent: Tuesday, June 21, 2005 5:55 PM Subject: Re: [Hardhats-members] VistA global variable partitioning > Fair enough, Steve. I thought that with the use of namespaces, VistA > was well partitioned, but I probably don't understand its interwoven > intricacies. I know GT.M, but not VistA. > > -- Bhaskar > > Tomlinson, Steven B wrote: > > That all sounds good, my concern, just for the sake of discussion, is that > > the routines and business logic may be so tightly integrated across > > packages/namespaces that the advantages of physically partitioning the data > > may not be realized sufficiently to justify the added system administration > > overhead of managing multiple databases. > > > > > > Steven B. Tomlinson > > [EMAIL PROTECTED] > > Pacific Telehealth and Technology Hui > > www.PacificHui.org ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
