Re: Naming Standards

Daniel Wright <danwright@bigfoot.com> wrote: :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 So you would rather type: SELECT systables_tabid FROM systables ST, syscolumns SC WHERE SC.colname = "balance" AND SC.tabid = ST.tabid which would be the result of prefixing column names with table names. If you don't include the whole table name in the prefix you will soon find yourself in a complete mess (how do you shorten table names that are allready short and descriptive as they should be). Additionally tools that suggest joins based on column names will not be able to do this. Table names as prefixes to column names are a bad idea. :(bad example, a join is not necessary here, BUT it illustrates my :point...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? It might have looked like this: SELECT ST.tabid FROM systables ST, syscolumns SC WHERE SC.colname = "balance" AND SC.tabid = ST.tabid See my response to Jonathan on why this isn't the best idea. With a small select like this the issue isn't a big one of course. :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. Exactly. As the orignial poster asked about database nameing conventions it shouldn't have been necessary to state that my suggestions where for database names. Names in program code is another issue. :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.) Agreed very much so. :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. Longer names on files are sometimes very usefull, but generally it's of course important that names should be short and descriptive. Not too short to loose the descriptiveness, and not to long to become hard to use. :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 Nils.Myklebust@idg.no NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway My opinions are those of my company The Informix FAQ is at http://www.iiug.org