Bookmark and Share

Recent Posts

It's Time for a Name Change!

December 9, 2008

Now before you get all bent out of shape about the possibility of yet another name change for our favorite system, that's not what we're talking about this time. What we're talking about is the terminology we use.

Back in October at our RPG and DB2 Summit, our friend and proud DB2 apostle, Mike Cain, made a statement that we thought worthy of a larger audience. We can't  recall exactly how the roundtable conversation reached this point, but the overall  thrust can be summarized along the lines of "How can we convince people from other platforms that we have a real database?" 

Mike's answer was a simple one: STOP TALKING ABOUT FILES, RECORDS AND FIELDS. We  need to change the way we talk about it if we want other people to take it seriously. In Mike's (and indeed our) experience, Oracle and other database users are often convinced that what we have is little more than a flat file system on top of which has been cobbled some half-baked database mechanism. If you think  about it, it's hardly surprising. We constantly talk old-technology terms like  files and records, so we shouldn't be surprised if others think that that they are the foundation of the system.

Of course nothing could be further from the truth. What we have is a fully relational database system which, when called upon, can cleverly disguise itself as a flat file system! Those of us who use the platform can understand what a terrific advantage this is--but it's understandable that others would view it with suspicion.

So here's the thing--keep calling the system an AS/400 or iSeries (or whatever) if you  must, but whatever else you do, when engaging in conversation with an Oracle/SQL  server/MySQL/whatever devotee USE TERMINOLOGY THAT THEY UNDERSTAND. Talk to them about your Tables (files) and Rows (records). Don't even _mention_ record-level access--they can't do it, so at best they won't care, and at worst will think  that your database is out-of-date. 

Remember--perception is everything--the fact that record-level access is a useful feature is irrelevant. Having a full-fledged relational database is the only thing that matters when making comparisons with other platforms. Also remember it's not only techies who notice the difference in our terminology from  those who work on the so-called "real database" platforms but also managers, CIOs,  CTOs, etc. They may not know a row from an index, but often they recognize those as database terms.

In fact, we'd go so far as to suggest that you should begin to transform your DB lingo in everyday conversations, even with other i folks. Why? Because unless it is ingrained into you, it will be tough to suddenly remember to use new terms consistently when talking to non-i folks. We're working on it ourselves and we know how hard it is when the old words we've used for decades trip off the tongue so easily.

Note that this suggestion has nothing to do with whether you actually use SQL to either define or access your data. Regardless of how you create or access the  data, you have Tables, Rows and Columns. (For those who are interested in reading  more of our thoughts on DDS vs DDL, take a look at the EXTRA article we wrote on the subject

So here's your handy-dandy cross reference to the SQL terms you should be using and their related "old" names (Try it--you have nothing to lose but your "old-fashioned" label!):

  • A Library is a Schema or a Collection
  • A File is a Table
  • A Record is a Row
  • A Field is a Column
  • A Logical File is a View (when talking about how the program views the data)
  • A Logical File is an Index (when talking about performance)

Logical Files do present a dilemma in terminology--they can be either an Index or a View. In practice, it's often a "strange" non-standard combination of Index and  View. An Index in SQL is used almost exclusively to improve performance when accessing data via SQL (which sadly on other platforms is the _only_ way to access data!) while a View in SQL is used to present data differently to the user or a program (e.g., by using select/omit or restricting columns or joining to other tables, etc.).

Think about how your everyday language could be impacting the perception of our system in the eyes (and ears) of those CIOs and CTOs not fortunate enough to have experienced i.

A simple change in terminology just might make a big difference.

Posted December 9, 2008| Permalink

Post a Comment

Note: Comments are moderated and will not appear until approved

comments powered by Disqus