[EMAIL PROTECTED] wrote:
The second camp, as is described in the article, are more data-oriented.
This practice was created in the original days of databases and programming design where ALL variables, including table names and field names, were global and needed to be absolutely unique.
It's not just that. Part of this convention is that when you have foreign-key fields, you name them the same in both the defining table and the referring table.
I.e. if you have a COMPANY table with CompanyID, CompanyName, etc., and an EMPLOYEE table, it can have a CompanyID that's now "obviously" (sic) "related" to COMPANY.CompanyID (you'd mark it as a FOREIGN KEY in EMPLOYEE). It also makes JOINs a little easier to write and read, because you'd be doing
FROM COMPANY c, EMPLOYEE e
WHERE ...
AND c.CompanyID = e.CompanyID
...and so on - looking at the column names immediately gives you a clue about the key relationships..
It's a style thing that I've seen a lot of, and there's nothing wrong with this. As you say, it's "data-oriented", but is really a naming-style issue.
If you were following the "object-oriented" (quote-unquote!) style, the above query may be harder to read (assuming that you used names like just "ID" and "Name" in COMPANY):
FROM COMPANY c, EMPLOYEE e
WHERE ...
AND c.ID = e.CompanyID -- 'uh, what's a "c"? Oh, yeah, a COMPANY.'
...
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
