RE: [QUARANTINE] Re: CamelCase For Procedures Names
- From: Jeff Chirco <JChirco@xxxxxxxxxx>
- To: Michael Moore <michaeljmoore@xxxxxxxxx>
- Date: Mon, 21 May 2012 22:28:42 +0000
I guess as long as there is some type of standard within an organization is all
that is important.
From: Michael Moore [mailto:michaeljmoore@xxxxxxxxx]
Sent: Monday, May 21, 2012 1:23 PM
To: Jeff Chirco
Cc: Joel.Patterson@xxxxxxxxxxx; oracle Freelists
Subject: [QUARANTINE] Re: CamelCase For Procedures Names
Importance: Low
On singular vs plural it depends upon your perspective. Are you interested in
the TABLE as an object or interested in the data content of the table. You
could say there is one Employee table or there are 35 employees. Given that
either perspective is legitimate, there would seem to be no conceptual argument
for going with singular or plural. However, from a practical point of view,
plural takes an extra character and that extra character can be multiplied if
your naming convention includes name stacking. I.E. tcustomers_vendors_map. You
might be surprised the number of times that dropping 2 characters can put you
below the 30 character limit. There seems to be no advantage to using plural
forms for table names. My shop standard is to use singular.
Mike
On Mon, May 21, 2012 at 12:39 PM, Jeff Chirco
<JChirco@xxxxxxxxxx<mailto:JChirco@xxxxxxxxxx>> wrote:
Really, I feel table names should be plural. I believe Steve Feuerstein
recommends this too. It is a Table of EMPLOYEES not a Table of EMPLOYEE.
From: Joel.Patterson@xxxxxxxxxxx<mailto:Joel.Patterson@xxxxxxxxxxx>
[mailto:Joel.Patterson@xxxxxxxxxxx<mailto:Joel.Patterson@xxxxxxxxxxx>]
Sent: Monday, May 21, 2012 11:44 AM
To: michaeljmoore@xxxxxxxxx<mailto:michaeljmoore@xxxxxxxxx>
Cc: andy@xxxxxxxxxxxxxxx<mailto:andy@xxxxxxxxxxxxxxx>;
kennethnaim@xxxxxxxxx<mailto:kennethnaim@xxxxxxxxx>; Jeff Chirco;
Oracle-L@xxxxxxxxxxxxx<mailto:Oracle-L@xxxxxxxxxxxxx>
Subject: RE: CamelCase For Procedures Names
I certainly agree about the prefixes - and the suffices for that matter. I
just made an exception for tables - but optional. Something not mentioned,
but not optional IMHO is to make table names singular. It is the EMPLOYEE
table, not EMPLOYEES.
Joel Patterson
Database Administrator
904 727-2546<tel:904%20727-2546>
From: Michael Moore
[mailto:michaeljmoore@xxxxxxxxx<mailto:michaeljmoore@xxxxxxxxx>]<mailto:[mailto:michaeljmoore@xxxxxxxxx<mailto:michaeljmoore@xxxxxxxxx>]>
Sent: Monday, May 21, 2012 11:47 AM
To: Patterson, Joel
Cc:
andy@xxxxxxxxxxxxxxx<mailto:andy@xxxxxxxxxxxxxxx><mailto:andy@xxxxxxxxxxxxxxx<mailto:andy@xxxxxxxxxxxxxxx>>;
kennethnaim@xxxxxxxxx<mailto:kennethnaim@xxxxxxxxx><mailto:kennethnaim@xxxxxxxxx<mailto:kennethnaim@xxxxxxxxx>>;
JChirco@xxxxxxxxxx<mailto:JChirco@xxxxxxxxxx><mailto:JChirco@xxxxxxxxxx<mailto:JChirco@xxxxxxxxxx>>;
Oracle-L@xxxxxxxxxxxxx<mailto:Oracle-L@xxxxxxxxxxxxx><mailto:Oracle-L@xxxxxxxxxxxxx<mailto:Oracle-L@xxxxxxxxxxxxx>>
Subject: Re: CamelCase For Procedures Names
I think the advantages of having a standard prefix outweigh the disadvantages.
One such advantage I found unexpectedly. We start all of out table names with
T, like TVENDOR. The big advantage comes in verbal conversation. When, in a
design meeting, somebody says 'tee-vendor' , it is immediately clear that they
are talking about the database table, and not a person that sells things. Of
course you could say, 'the vendor table', but when the names of tables are
mentioned thousands of times over the course of a month, the savings in time
and effort adds up. Other advantages may be specific to your shop. I.e do you
use Perforce? Do you produce reports that contain a mishmash of dictionary
object types. One suggestion I would make however is not to use a _ . ie. not
T_VENDOR, but TVENDOR. With only 30 characters, every character counts.
Sometimes you will want to combine names, for example suppose you want at table
that maps vendors to customers. You might want to call it Tcustom
er_vendor_map. Then suppose you want to name an index for this table;
tcustomer_vendor_map_ix. In this particular example still did not push beyond
the 30 character limit but many table names will be more than 6 to 8
characters to start with. This might seem like a trivial problem, but it can be
very annoying when you are trying to follow the index naming standard and
somebody has created a table name that's alerady 30 characters long. Use
abbreviations where possible. Instead of Tbilling_revenue_stage, use
tbil_rev_stg. Maybe the first time somebody looks at it, they won't know what
it means, but some poor schmuck like me is going to have to type that table
name a thousand times over the next 5 years, so keep it short.
IMHO.
Mike
On Mon, May 21, 2012 at 6:00 AM,
<Joel.Patterson@xxxxxxxxxxx<mailto:Joel.Patterson@xxxxxxxxxxx><mailto:Joel.Patterson@xxxxxxxxxxx<mailto:Joel.Patterson@xxxxxxxxxxx>>>
wrote:
I like the example, it pretty much says it all (43 chars though).
What about suffixes or prefixes like R_for_procedures (or _R), or P_for
packages, I did not catch Steve mentioning Packages and Package declarations in
the paper? (btw I don't believe tables need a prefix or suffix).
I do like what Steve says about avoiding 'get' with regards to a function.
Joel Patterson
Database Administrator
904 727-2546<tel:904%20727-2546><tel:904%20727-2546>
-----Original Message-----
From:
oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx><mailto:oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>>
[mailto:oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx><mailto:oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>>]
On Behalf Of Andy Klock
Sent: Friday, May 18, 2012 9:11 PM
To:
kennethnaim@xxxxxxxxx<mailto:kennethnaim@xxxxxxxxx><mailto:kennethnaim@xxxxxxxxx<mailto:kennethnaim@xxxxxxxxx>>
Cc:
JChirco@xxxxxxxxxx<mailto:JChirco@xxxxxxxxxx><mailto:JChirco@xxxxxxxxxx<mailto:JChirco@xxxxxxxxxx>>;
oracle Freelists
Subject: Re: CamelCase For Procedures Names
The most important thing is consistency by a defined coding standard
that everyone must follow. I don't even think it's because it makes
the code more readable (though it does) but more because it saves so
much time not having to think about what and how to call stuff.
Developers should spend more time on the actual logic than whether or
not to use CamelCaseWhichIsAnnoyingAsHellWithLongNames or
easy_to_read_names.
An old friend and colleague (who I know is a lurker here:) turned our
old team onto a document very much like this:
http://www.toadworld.com/Portals/0/stevenf/Naming%20Conventions%20and%20Coding%20Standards.pdf
Make amendments to fit your taste. For me it made all the difference
in the world.
Andy
> -----Original Message-----
> From:
> oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx><mailto:oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>>
>
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx><mailto:oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>>]
> On Behalf Of Jeff Chirco
> Sent: Friday, May 18, 2012 5:39 PM
> To: oracle Freelists
> Subject: CamelCase For Procedures Names
>
> I am settling a debate about allowing CamelCase procedure names within a
> package.
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
