Re: Naming Standards

As if you don't have enough conflicting answers already.... I have seen databases which strictly adhered to prefixing column names with table names and thought it was very handy...we never had to prefix otherwise ambiguous column names in sql stmts. I find it particularly annoying to have to say (for example): SELECT systables.tabid FROM systables ST, syscolumns SC WHERE SC.colname = "balance" AND SC.tabid = ST.tabid (bad example, a join is not necessary here, BUT it illustrates mypoint...Who cares which table your selecting tabid from???? It's equal in both cases if you'll note the where clause.) This example also illustrates that using table-name aliases is not such a bad thing...that wasn't too confusing looking was it? Also I would disagree with the warning against "Hungarian notation" to indicate variable type. for the cost of one letter or two (if you use an underscore after it), you can save yourself having to look up a data-type. I never declare a pointer in C, without prefixing it with "p_", and I generally differentiate character arrays by suffixing them with "str". This very easily tells the world that name_str and p_name_str are 2 different kinds of variables (I don't go so far as to actually use this notation everywhere, but another useful convention is to use f_, g_, and m_ to indicate the scope of a variable (function, global, or modular), but I guess I'm sidetracked since you're talking about field names in a database. 18 characters should generally be plenty to describe most fields, and you can never include every nuance of a field in it's character name. Long names are no substitute for good documentation describing a field and how it interacts with the rest of the system (is it a primary key? foreign key? a flag? a serial id? an obsolete field retained merely for backwards compatibility? You'll never fit all that into a variable name.) I made a sarcastic remark about being glad that someone saved themselves from typing one character by naming a field tot_cub, instead of tot_cube (Mainly because I kept typing in the longer name because it was more natural-and kept having to fix that mistake.) In defence of the name (more a retaliation of my sarcasm, in reality, I believe) it was pointed out that the shorter name meant better performance, since the database had one less character to parse (yeah, right, talk about your very minor performance gains, and how do we know Informix isn't looking at all 18 characters anyway...the way they wrote 4GL to pass fixed length arrays instead of implementing pointers...doesn't that strike anyone else as being inefficient?) But seriously, didn't anyone ever tell you that names should be short and descriptive? How long are the names of your files on your file system? I am not even aware of the limit imposed by my operating system, because I have only rarely exceeded it. Dale Forrey wrote: > > We are new to the Informix world and the Data Administrator at our > shop is a little frustrated with the 18 character limit on names. Has > anyone come up with a clever set of naming standards that they are willing > to share with the list? For instance, do element names always or ever > reference the entity to which they belong? Is there a standard set of > abbreviations that you use? Are some words always abbreviated and others > never abbreviated? Where did Informix come up with a limit of 18 characters > in the first place? Anyway, thanks for your help. > > Dale Forrey, DBA email: forrey@wsu.edu > Information Technology FAX: (509) 335-0540 > Washington State University Phone: (509) 335-7098 > Pullman, WA 99164-1222