Xref: utzoo comp.databases:4706 comp.lang.c:25214 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!samsung!aplcen!haven!vrdxhq!dev!dgis!jkrueger From: jkrueger@dgis.dtic.dla.mil (Jon) Newsgroups: comp.databases,comp.lang.c Subject: Re: How do you name table/structure elements? Message-ID: <725@dgis.dtic.dla.mil> Date: 20 Jan 90 16:32:11 GMT References: <1990Jan16.170217.16718@aqdata.uucp> Followup-To: comp.databases Organization: Defense Technical Information Center (DTIC), Alexandria VA Lines: 38 sullivan@aqdata.uucp (Michael T. Sullivan) writes: >I would like to get some feedback as to how and why you name your >database table rows or C structure elements. As far as I can tell, >there are two camps: the "plain descriptive" and the "table/structure >descriptive". Let me give an example: supposed you have a >table/structure called "customer". Its elements can be named two ways > plain descriptive table/structure descriptive > ----------------- --------------------------- > name cu_name > address cu_address > city cu_city > state cu_state > zip cu_zip > ...and so on. What you're calling the table/structure descriptive is a symptom of impoverished namespace tools, or someone's exposure to the same in previous work. Query languages can name columns unambiguously using classic structure.member syntax. Nothing is added by the redundancy. Consider: select cu_name from customer select * from customer, locations where cu_name = lo_name Versus: select name from customer select * from customer c, locations l where c.name = l.name Anyone see any advantage of the first form? -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger The Philip Morris Companies, Inc: without question the strongest and best argument for an anti-flag-waving amendment.