This was my fortune cookie the other day.   It was attributed to Confucius.   Now, I doubt that Confucius actually said it.   The humor shines through only in English, I think.   For the sake of not plagiarizing, let’s continue attributing it to Confucius.   It reminds me of another quote that I heard a while back.   This one attributed to a Buddhist monk “What I am I am and say not.   Being is the great explainer”.    We will get to this quote in a moment.  

But first …

If you are a job candidate hoping to make it past the screening process, you may well feel like a show-off.   Regardless of your personality, the job interview is not the time for modesty.   The job interview is the time to say and with a straight face “Hey look at me.   Aren’t I wonderful?   Wouldn’t you like to have me working for you?”  

If you are looking for a job, depending on how you find yourself looking, this can be tough.    If you got fired (laid off, downsized, cost reduced, name your euphemism) such confidence will feel alien and fake.   If you are miserable in your current job and casually looking around, you aren’t really motivated to put it all out there, and you can’t maintain the strong self confident image that you need to present.

Fake or uncomfortable, awkward or contrived, however it makes you feel, this is the façade that you have to put on to get the job.

Most of us technology geeks will more easily tend towards the Buddhist quote listed earlier.    We would rather not have to toot our own horn.   We would rather be modest and casual keeping a low profile and avoiding the spotlight.   We try to live by the second quote mentioned earlier.

“What I am I am and say not.   Being is the great explainer”.    If you are a great programmer, it should be obvious if you are doing your job right.   As a general rule, if you have to walk around saying, “I am great at this” or “I am great at that” you usually are not.   More likely than not, you are an insufferable jerk.   If you really are great, it should be obvious and you should not have to point it out all the time.    This is a great philosophy for the daily grind.

Unfortunately, it doesn’t work so well for job searching.   In a short interview, you flat out don’t have the time for “being to explain” what you are, must shine through quickly, usually in 30 minutes or less.   If not, you may not get the rest of the time needed for being to explain.

So, if you are on the job hunt, let loose your inner braggart.   Just me sure to be him back in the cage after you land your next great opportunity.   If you are the screener, realize that the people you are dealing with are probably acting against their character and venturing outside their comfort zone.   Be patient.

I have often thought about what would make a good data dictionary.   Usually I have lamented the absence of any meaningful data dictionary beyond what the DBMS itself keeps on its own.   If everyone would simply add comments everywhere that the database natively allows, we would all be oh so much better off.   But alas we don’t.

As is so often the case, if we don’t have to do something, we probably won’t.    Often times, it’s a matter of meeting deadlines, sometimes it’s a matter of shear laziness, but sometimes, it may just be a case of not understanding the need or not knowing what is intrinsically available.

Let’s tackle the need first…

Database objects rarely have meaningful names.   Database objects with meaningful names to one group may not be meaningful to another group.   When you are trying to learn a new data model, the history of this data model is useful to understand the conventions adopted or ignored.

In its simplest form, I have several goals for a data dictionary:

·        Define the naming conventions followed
·        Identify known exceptions to these conventions
·        Provide an English description for each database object (table, column, stored proc, trigger, etc)
·        Document the accepted data types and their purposes
·        Identify known exceptions to the data type rules
In Oracle or SQL Server, this can all be accomplished with a relatively small word document and the native data dictionary.

I think though that to actually enforce these conventions, we need a little extra support:

·        A Data Thesaurus
·        A rule validator similar to fxCop
The data thesaurus would be used to ensure that appropriate naming conventions are used.   Proposed object names would be split on a case change and run through the thesaurus.   If the individual words are found in main line entries, you are good to go.   If an individual word is found as an alternate, replace it with the main line entry and proceed.   If an individual word is not found in the thesaurus, flag it for review.

Such a process would eliminate such confusing names as:

·        ProcessDate
·        ProcessDte
·        Process_Date
The first name would work as entered.   The second one would be converted to the first one, and the third entry would be rejected since Process_ was not found in the thesaurus.   The key thing here is that it tracks and enforces the convention at the time of object creation not at the end of the process.

The above is one rule based on the data thesaurus.   Other rules that may be useful might include:

·        Insure that object names are not plural.   Each record in the “Members” table is a Member
·        Insure that each table name is a noun
·        Ensure that every column is either a noun or an adjective.   Columns should not be verbs
·        Ensure that every table has an associated comment
·        Ensure that every column has an associated comment
·        Ensure that every stored procedure has an associated comment
·        Ensure that stored procedures pass the thesaurus test
·        Ensure that stored procedures have the form ActionObject, such as InsertMember or SelectMembersByGroupID
Or

·        Ensure that stored procedures have the form NounAction such as MemberInsert or MemberSelectByGroupID

What are your thoughts on a data dictionary?   Has anyone incorporated similar ideas into one?   How did it work out?   Have you thought about and decided against?