> 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 _______________________________________________ New York PHP User Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/show_participation.php
