The final numbered post in this version of my “pillar” series of posts ends in the most contestable part of the design/implementation process.  Encapsulation. The concept of encapsulation is not contested (or even contestable by sane programmers in any field of the art of system creation. Every time you use a Windows API call you are ...

With the previous post on the fourth pillar, I have reached the “end” of the design posts.  To review, these were: Coherent – cohesive, comprehendible, standards based, names/datatypes all make sense, needs little documentation Normal – normalized as much as possible without harming usability/performance (based on testing) ...

This blog probably won’t stir up a hornet’s nest or anything, but I would also expect that it would be the least popular in practice. The person who feels they can disagree with the need for a reasonable amount of documentation is probably nuts. In the first post, I defined documented as “Anything that cannot be gathered from the previous four is ...

This one should be simple to anyone who sees it (once I decode what I mean by fundamentally… and sound…by then for sure!) In the initial post I defined this as – fundamental rules enforced such that you don’t have to check datatypes, base domains, relationships, etc.  The gist here is that you at a minimum don’t have to spend all of your time ...

The first pillar was easy, since no reasonable person is going to argue that having a design that is not coherent is desirable. No matter what the type of system, any design that isn’t easy to understand is likely to be a bad design (obvious caveats are that it must be understandable to other people of a given level of intelligence in the given ...

One of the definitions on wiktionary.org for coherence is “a logical arrangements of parts”. In my initial post, I defined “coherent” for database designs in the following manner: cohesive, comprehendible, standards based, names/datatypes all make sense, needs little documentation.  Both definitions share one specific common theme: ...

Before I get started with the pillars of a well built database, I want to reply (in long form) to a comment on the last post. I see the phases of the project to have five distinct phases (again trying to make memorable lists that an stick in your mind): Requirements – The process of extracting what needs to be done from the mind of the people ...

As I am starting the process of writing my next edition of the database design book (over the next 3+ years) I am starting to try to come up with some catchy way of stating that a database is well designed and implemented.  So I started to think of some metaphor and pillars is the best I could do. Catchy? Dunno, but the idea is that without ...