Yes, I do realize I may have lit this fire, with my response to Mike a few years back, and it is a bit of a cop out to try to not respond to your point. However, I’m hoping to reign in the conversation and keep the blog as apolitical as possible. If it helps, I’ll declare Mike the winner of that debate and move on.

That was a big reason why it took me longer (in the beginning) to understand and implement the true relational db normalization model since it was easier to rely on the lookup fields that others created (and then I created), as a means to link data from other tables.

I’ve seen it happen to many others also, and many have gained a false sense of confidence in being able to build more advanced databases because of the lookup field link to other tables. Fortunately for me, I understood that I didn’t know enough to proceed into deeper waters until the time came.

But cheap imitation practices do delay learning correct practices, as visual conceptualization is a big part of learning and grasping true practices. Just because Johnny can drive the car around the driveway, doesn’t mean he is ready for the highway. Same goes for “relational” database theory.

Maybe someone is wondering what I am talking about. Well, for example, many dept managers gain the false belief that just because someone can present them a database that is “RELATIONAL” — has data from multiple tables being linked (RELATED) through lookup fields from other tables, that that alone proves that one understands relational db theory, when it is not the case at all.

I’ve seen it many times over, many dept Access database hobbyists come in with a supposed relational database, and thus the boss surely thinks they have arrived at the breakthrough ability that others haven’t figured out in being able to make a db relational. Now, this may sound crazy, as I am not talking about dummies here, but a dept full of engineers in various other disciplines.

Obviously, advanced users will know how to develop a db with or without lookup fields, but not everyone does. So, it is my opinion that lookup fields ought to be left for novices learning early Access database operations, and not for developmental databases.

As for the other points about lookup fields being evil, I can’t answer that, as I have not tested out those hypotheses or those rebuttals besides this one point I am making. But I know this one point to be a FACT, as I have seen a number of databases in advanced stages of cancer where chemo couldn’t even help them – all because the “lookup field” gave Johnny a license to drive when he was not ready!

One pattern is “programming is a passion and I burned out”. I’m uncomfortable with that. Programming is a tool to translate a business requirement to a working process. I actually think 90% or programmers do “un-targetted work”, and in that set falls a lot of the “passionate” programmers. Is programming some sort of end-in-itself ? NO. It is a tool to accomplish an end, END OF.

And “burned out” – I respect the effort that must have gone into that, however, if the focus were “learn what you need to learn to get from A to B”, ie targetted, then burn out may not be necessary.

My view is ones’ true capability is set at birth, and deteriorates relatively little with age – certainly to 50s’. Two things set ones’ real usefulness, one is experience in a “real” field (chemical engineering has been mentioned), and two your (birth set) ability to translate engineering issues to economically created code.

I think the age issue certainly exists, but its’ small beer compared to real engineering experience and actual ability.

I’m looking around for something to do, whatever comes along I will focus 100% on what the business process is, ie what generates income for the company, before agonising over any software issues.