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:arslist@ARSLIST.ORG] On Behalf Of Jason Miller Sent: Wednesday, September 05, 2012 3:33 PM To: arslist@ARSLIST.ORG 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 _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
