Overlays was my first thoughts as well.. Why another DB when we now have overlays..??
But for ‘some things’, I think it’s a absolutely brilliant idea.. These some things have nothing to do with ARS objects hence overlays wont even be in the picture.. These are ‘foreign’ tables we tend to create in the ARSystem schema, and have it reside in there resulting in many sometimes hundreds of foreign tables in there, and without a good naming convention, you can easily loose sight of whats internal and whats external to the database.. I think for this one and only reason, having a database of something like ARSExternal to keep all external objects outside, and then create DB links to reference this is an absolutely gem of an idea for the pure purpose of maintenance.. In that external space, you could even have a table with the same name – who cares.. Good idea.. But for anything internal, as David rightly pointed out, overlays man.. they will be your next best friend for a few years to come until something better comes out! Joe From: Easter, David Sent: Thursday, September 06, 2012 8:40 PM Newsgroups: public.remedy.arsystem.general To: [email protected] Subject: Re: Thoughts regarding a separate DB for custom DB objects ** Just thinking somewhat inside the box – but wouldn’t overlays do the majority of this for you? Any custom objects you create would be well known/documented as would any modifications to BMC base objects. The base BMC objects would remain on the system unchanged. If you really then wanted to transfer only your extensions and modifications to a new box, you’d just transfer the custom and overlaid objects. -David J. Easter Manager of Product Management, AR System BSM & Atrium Solutions Management BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Jason Miller Sent: Wednesday, September 05, 2012 3:33 PM To: [email protected] Subject: Thoughts regarding a separate DB for custom DB objects ** I would like to get some input on something I have been thinking about recently. I am considering creating a new DB on the same DB server as the ARSystem DB. This DB would be right next to the ARSystem DB but would house all of the custom DB work we do. My thought is to have all custom tables, views, stored procedures, functions, etc. in new DB which would ideally leave everything in the ARSystem DB created, maintained and modified via the AR System API or BMC installers. Basically I am picturing a layer of abstraction or a library of custom objects if you will. Maybe more like a different namespace or data set for those CMDB gurus out there. As it is right now in our very customized 7.5 ARS DB all custom tables, views, etc. are all intermixed with the ARS maintained objects. We try to keep our objects lumped together by naming convention but just when my team starts using the same convention a different DBA (for example) comes along and uses their favorite convention. If we all agree to only make changes to the custom DB then naming convention is not as important (DBAs usually ask which DB do you need something not so much “what is your naming convention?”). Another considerations is portability of the ARSystem DB. Right now when we refresh our production DB to another environment there are things like different linked server references that need to be updated, object owners, etc. All objects in the custom DB would have the same names between environments (Dev, QA, Prod). With all of the custom objects in their own DB we can move ARSystem DBs between environments and as long as the custom DB is configured correctly for the environment no changes are needed to any of ARSystem DB objects. Our new “out of the box” ITSM 7.6.04 system does not have any custom DB work done yet but I know it is only a matter of time before the need arises as we transition between old and new systems. If there are advantages and no major negative results to this architecture I would like to set this up while we are still out of the box. Can anybody think of any negative (or positive) effects of this approach? I am figuring because it still on the same DB server that there should not be much performance impact. Thanks! Jason _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
