Now that is a bit tricky... To stay "out of the box" we need to think
"inside the box" :)
You are absolutely correct. All AR maintained objects will utilize
overlays and best practices. What I am talking about are custom DB objects
not maintained by the AR System. Most of (if not all of) our custom DB
objects are for integration purposes
Here are some examples:
- The Views that View Forms are created against
- Tables that cache data from other systems that View Forms are created
against.
- In the case of our HR and Financial systems creating View Forms
over a Linked DB server were too slow for use in UI workflow (Cost Center
and Sub Account Menus/Validation, HR/Finance Locations, etc.)
- Stored procedures to populate the cache tables mentioned above
- Functions converting to/from epoch time
- Function for INITCAP (we're MS SQL so we had to build it)
- Stored procedures that other systems use to access Remedy data (yeah
we are trying to move most of these to web services when possible).
- Views that other systems use to access Remedy data (yeah we are trying
to move most of these to web services when possible).
- Stored procedures to truncate import Forms (T and H tables)
Currently all of these things are in our ARSystem DB. Moving these out
would make the ARSystem DB more portable and "pure."
Jason
On Thu, Sep 6, 2012 at 5:40 PM, Easter, David <david_eas...@bmc.com> wrote:
> **
>
> 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"_ ****
> _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"
