NYCPHP Meetup

[lists at nopersonal.info]

> Essentially the thinking is that whenever you're processing code that 
> involves a lot of tables or a lot of queries (and returned results), 
> you end up with a bucketload of things named 'id' to handle.  
> 
> For instance imagine pulling out the contents of ten tables through ten 
> queries in one script, and all the ID fields are named, id.  Or if you 
> are doing a SELECT query where you are pulling stuff from 3 tables at 
> once and all three of them have a field that you need to reference 
> named, you guessed it, id in all three cases.  
> 
> The thinking being that if you don't name everything 'id' then you 
> won't make mistakes caused by everything being named 'id'.

Kristina, this is so true. The moment I started dealing with more than
one table in a query I realized that I was probably going to get myself
in trouble if my id names weren't more specific, so I decided to opt for
the more cautious route even if it meant more typing.

I was starting to waver in my resolve though, so I'm glad you explained
things so well as it'll keep me from getting lazy.

> The flipside of the argument is that it gets darn annoying always 
> forgetting whether or not in this table the ID is prodid or prod_id or 
> productid or whatever it may be...and you're looking it up for the 6th 
> time that day at 2 AM....

It's good to know the flipside--thanks.

> Or you inherit a database that's got fun ID field names like 
> cat_subCat_xtab_id and you start cursing the day that someone came up 
> with the silly idea that naming ID fields 'id' was a bad idea...When 
> you start muttering things like "this is a database, not the Iowa 
> Writer's Workshop" under your breath, you know it's time to leave and 
> get that cold beer.

LOL

> And you've got to be consistent with your own database design.  If you 
> decide now to go with prod_id, stick with that, don't all of a sudden 
> start to think that the underscore is "so last year", and start to use 
> prodid...so you don't get confused between databases.  I've been guilty 
> of getting bored with using the same old, same old field names over and 
> over and making my life more difficult than it has to be...

You know, a couple of times I switched my naming conventions and it was
a PITA, so I can definitely see the wisdom in your advice. I finally
decided to just stick with a underscore as it's second nature to me
after all my years of front end production.

Bev