Have a design situation where I could use a field name alias to simplify some programming. I'm wondering which of my options would be considered "good form."
I generated a series of database action shells (as I call them) in a middleware language to standardize a sequence of events surrounding db add, update, and delete actions. These were originally created for a project with a number of simple unrelated tables. Each table's primary key was a field called "rcrdNo." Because of this standardized field name, these routines all use rcrdNo explicitly as the PK. Now, moving these routines to a project where there are a number of related tables (my first real SQL project, so its my first crack at xfring these routines) I see where each table's PK would benefit from a unique name to keep things from getting very confused. I see two options: 1) send the unique PK field name as a paramater to my routines (which I have to do for the db_name anyway). Pro: fully flexible routines. Con: more programming steps. 2) create a field name alias of rcrdNo for each PK. Pro: routines work as is, less programming. Con: I dunno, I guess I am asking you guys :-) I suspect aliases are best reserved to solve hairy conflicts when merging sysems or something. But does the simplification of using standardized routines like this also make for good reason to use them? Wanting to have adopt good habits from the beginning.... Thanks. -- Greg Willits -- [EMAIL PROTECTED] --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
