|
|
|
|
Browse by Tags
All Tags » Best Practices » Database Design (RSS)
-
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 Read More...
|
-
A bit of terminology that gets beaten to death is that of the “physical” database. I would think most every DBA uses this term (I do), but…to mean what? I think there are two common utilizations: The layer of tables, constraints, indexes, Read More...
|
-
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 Read More...
|
-
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 Read More...
|
-
Okay, so on the first look this sounds like the most boring Japanese action movie ever. Requirements is tearing through the village, and Architecture is in the city. Developers by the horde are trying to code both of these into oblivion…Maybe not. Read More...
|
-
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, Read More...
|
-
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 Read More...
|
-
I know this is a topic that could cause a few heads to spin around uncontrollably if taken the wrong way, but I preserve. Today I was having a conversation with an end user, an influential one at that, about a business rule that was needed for the Read More...
|
-
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, Read More...
|
-
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): Read More...
|
-
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 Read More...
|
-
As I have been walking around Disney World this week, my mind starts to wander to matters of database design. Sad, perhaps, but I will guess that most people who read this blog do the same much the same thing with whatever technology they are good at Read More...
|
-
As I am easing back into real life from writing the book, I am in search of easy targets for blogging. My boss mentioned this blog over on Jeff Atwood's Coding Horror Blog and it got me thinking about commenting. His advice is to only comment Read More...
|
|
|
|
|
|