and then when i make fk's i have something like this:  productID or
whatev, lets say for a cart application, etc.

tw

On Wed, 21 Jul 2004 16:26:43 -0400, Tony Weeg <[EMAIL PROTECTED]> wrote:
> i use id, and i use camel caps.  makes it really easy, and since
> everything has scoped names, etc...its all good :)
>
> but then again, im a neo-maxi-zoom-dweebie, and what i say, doesnt
> matter, right tango!
>
> tw
>
>
>
> On Wed, 21 Jul 2004 12:43:17 -0400, Tangorre, Michael
> <[EMAIL PROTECTED]> wrote:
> > > The standard that I use is to have table names pluralized
> > > except in the case of join tables (users, locations,
> > > userslocations) and then will generate the ID based on the
> > > table name (users_id, locations_id, userslocations_id).
> > >
> > > Yes it can lead to long field names, however it makes for
> > > easier to follow standards.
> >
> >
> > I always make table names singular and the PK (if it is not a composite key)
> > is the table name TABLE_NAME_ID in all CAPS. In fact, every column is CAPS!
> >
> > APPLICATION_USER
> > --APPLICATION_USER_ID (PK)
> >
> > PERMISSION
> > --PERMISSION_ID (PK)
> >
> > APPLICATION_USER_PERMISSION_LINK
> > --APPLICATION_USER_ID (PK)
> > --PERMISSION_ID (PK)
> >
> > I don't care how long table names and column names are as long as I don't
> > have to stop and try and figure out an abbreviation. Space doesn't cost $500
> > a MB anymore, so.....
> >
> > Also, IMO, camelCase is tough to read after awhile... So I juts stick to
> > CAPS and UNDERSCORES.
> >
> > To each his own. The thing is, if you work alone be consistant. If you work
> > in a team, hopefully there is a standards document to follow.
> >
> > Mike
> >
> >
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]

Reply via email to