Re: Clean Object Class Design -- What is it?

"Bob Badour" <bbadour_at_golden.net> wrote ...
> However, I started this thread because an OODB vendor
> claimed that OODB designs do not need any kind of normalization. Of
 course,
> the vendor's claim was simply absurd.

Not being a database person myself, I get the feeling you're going to berate me without making any points that I can make sense of. This is nothing personal, and derives entirely from experience with other database people who are not you, so apologies if I sound overly defiant. I hope I'm wrong, but what better way to find out...

I'm not entirely seeing your point. I feel confident that, given an object-oriented class model that's appropriate for a problem or set of problems, I can automatically generate an appropriate schema to store data in a database. In fact, I've written and used a tool in my last software consulting position to do exactly that. The tool needs to be told what indexes to create, since programmatically deciding that would require analysis of code that's much harder than just informing the tool of the necessary indexes.

The tool I'm talking about also doesn't add a lot of the data integrity constraints that a database designer probably would. It does add foreign key constraints to enforce the relationships between tables, but data within a table isn't controlled at all. These data constraints, however, are encapsulated in the code that is used to access the data. It's assumed that all access to data goes through these objects, which can be remotably running on some set of intermediate servers to support that kind of access.

I have no doubt that a scheme something like this is what the vendor meant when they said that use of an OODB doesn't require normalization.

What you seem to be saying, instead, is that one can't properly understand the data in the first place without undergoing a formal database normalization process. All I can think of is that this must be some kind of mental frame you get into when you do a lot of database stuff. I just looked at http://www.phpbuilder.com/columns/barry20000731.php3, which explains (at least this guy's understanding of) the rules of database normalization... turns out that when designing a class model with the intention of storing it in the database with this tool, I always follow them in my class design when they apply; not because I know the rules of database normalization, but because anything else just seems stupid.

> When comparing two proposed designs, one can use objective criteria for
> comparison.

Fine, so if you want to measure the same things, you can apply your criteria to the schema that is implied by a given class model.

> >Afterwards, if data persistence is required (and it mostly
> >is), then you put in data persistence.
>
> So, in other words, one just turns on persistence without any thought to
> enforcing integrity constraints

Integrity constraints are expressed by the relationships between classes in the class model, or by the precondition checks in the classes that encapsulate data access.

> or how the initial application design will
> affect other potential uses of the data?

In an enterprise-wide system, data is designed by using generic data model classes and made available over the network. Another application using the same data might require more indexes to optimize for different lookup patterns, but if it's using the same data then it's using the same data.

> The database is just an
> afterthought?

The database is clearly not an "afterthought" since the system wouldn't work without it, but it doesn't much affect the design of the classes I use to encapsulate my data. Instead, it provides a way to store that data with efficient insertion, deletion, and in-place updates; to achieve transactional integrity when using that data; and to retrieve relevant data sets. None of these tasks relate to the class model in the slightest.

> You obviously do not know what the software crisis is.

I obviously don't know what you mean when you say "the software crisis". I foolishly assumed you meant a crisis in software, not that it works so well that people can't get enough of it. Most people say "software crisis" when they are about to make comments on how horrible the state of the industry is, and how it needs to "mature", and get a bunch of rules and complex industry review processes and formal proofs of correctness that make it difficult to get to the point of getting work done that you know is right. They say "software crisis" to mean that we need heavyweight waterfall models of development where every stage is completed and cast in stone in turn. This is the opposite of productivity. It's safety at the expense of productivity.

If you're using that term to talk about the opposite problem, then perhaps you ought to mention that first.

> Yes, but who meets all of their other software needs? Are you claiming
 that
> you can single-handedly meet the entire world demand for software
> development? Have you established that your clients have no unmet software
> needs? I bet if you investigated, just a little, you would soon understand
> what the software crisis really is.

Why are you being condescending. I realize that there are unmet software *wants* in the world. I realize that more software development will further increase the productivity of many businesses. I don't think this is a crisis. What you're essentially saying is that because a better way of doing things came around and not everyone is using it, we're in a state of crisis. Wow! I can imagine all the earthquakes and volcanoes destroying the planet if only we didn't have the enormous software infrastructure we already have.

Perhaps we have different understandings of the definition of "crisis."

> Incidentally: Why not bug-free? Many, many, many developments in
 engineering
> are completed successfully and without bugs. Why can we not deliver this
 in
> software? Hmmm?

Now you're sounding like the software crisis people I talked about above. The answer is that there is such a pressing need for software development. There isn't time to do formal verifications, extensive review processes, etc. except in places where correctness is a critically important system requirement. In security software, in the hard real-time market, etc. you do see a lot of exactly these kinds of verification, review, and bug-free systems... along with orders of magnitude less productivity in terms of software functionality.

Chris Smith Received on Sun Jul 22 2001 - 01:32:56 CEST