I would go for the parameterized solution here - fully flexible routines are a very good thing. Plus it sounds as if your tables will be more normalized - i.e. you won't be including meta-data in your data tables (if I'm interpreting what you're saying correctly).
Good luck, Jon > -----Original Message----- > From: Greg Willits [mailto:[EMAIL PROTECTED]] > Sent: Sunday, January 27, 2002 10:44 PM > To: MySQL > Subject: Case for Field Name Alias > > > 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 > --------------------------------------------------------------------- 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
