Re: Naming conventions for lots of stored procedures - Mailing list pgsql-general

From Justin Graf
Subject Re: Naming conventions for lots of stored procedures
Date
Msg-id 4B985E9E.7010306@magwerks.com
Whole thread Raw
In response to Naming conventions for lots of stored procedures  (Chris Travers <chris@metatrontech.com>)
Responses Re: Naming conventions for lots of stored procedures  (Chris Travers <chris@metatrontech.com>)
List pgsql-general
On 3/10/2010 8:16 PM, Chris Travers wrote:
> Hi all;
>
> One of my applications currently has over 60 stored procedures and
> future versions will likely have several hundred.  I am wondering what
> folks find to be helpful naming conventions for managing a large
> number of stored procedures.  We tried using double underscores to
> separate module vs procedure names and that just became a mess.  I
> have found a few possible separators that might possibly work but they
> are aesthetically revolting (_$ for example, like select
> test_$echo(1);).
>
> I can't imagine I am the first person to run up against this problem
> and would rather ask advice of more experienced folks then to wander
> from one maintenance headache into a possibly far worse one.
>
> So, what are approaches each of you have taken in the past?
>
> Best Wishes,
> Chris Traverl
>

look into schemas.

this allow group table and procedure logically and can limit access
based on schemas.

what i did is group procedures, views, and tables into schemas  to keep
them logically grouped.
in one project there is 300 tables, and 1200 procedures
wip  (work in process)
sales
AR
AP
GL
public


All legitimate Magwerks Corporation quotations are sent in a .PDF file attachment with a unique ID number generated by
ourproprietary quotation system. Quotations received via any other form of communication will not be honored. 

CONFIDENTIALITY NOTICE: This e-mail, including attachments, may contain legally privileged, confidential or other
informationproprietary to Magwerks Corporation and is intended solely for the use of the individual to whom it
addresses.If the reader of this e-mail is not the intended recipient or authorized agent, the reader is hereby notified
thatany unauthorized viewing, dissemination, distribution or copying of this e-mail is strictly prohibited. If you have
receivedthis e-mail in error, please notify the sender by replying to this message and destroy all occurrences of this
e-mailimmediately. 
Thank you.


pgsql-general by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: crosstab functionality for postgres 8.1.4
Next
From: Phillip Berry
Date:
Subject: Re: SAS Raid10 vs SATA II Raid10 - many small reads and writes