Thursday, August 11, 2005
« CSLA .NET 2.0 | Main | .NET Rocks! interview »

Like any author who writes practical, pragmatic content I am constantly torn. Torn between showing how to write maintainable code vs fast code. Between distilling the essence of an idea vs showing a complete solution that might obscure that essence.

Just at the moment I'm building a demo application, including its database. Do I create the best database I can, hopefully showing good database design techniques and subsequently showing how to write an app against an "ideal" database? Or do I create the database to look more like the ones I see when I go to clients - so it will have good parts and some parts that are obviously ill-designed. This latter approach allows me to show how to write an app against what I believe to be a more realistic database.

I'm opting for the latter approach. Yet sitting here right now, I know that I'll get lots of emails (some angry) berating me for creating and/or using such a poor database in a demo. "Demos should show the right approach" and so forth. Of course if I were to use a more ideal database design I'd get comments at conferences (some angry) because my demo app "isn't realistic" and only works in "a perfect world".

See, authors can't win. All we can do is choose the sub-group from which we're going to get nasty emails...

But that's OK. The wide diversity of viewpoints in our industry is one of our collective strengths. Pragmatists vie against idealists, performance-hounds vie against those focused on maintainability. Somewhere in the middle is reality – the cold, hard reality that none of us have the time to write performant, maintainable code using perfect implementations of all best practices and known design patterns. Somewhere in the middle are those hard choices each of us makes to balance the cost of development vs the cost of licensing vs the cost of hardware vs the cost of maintenance vs the cost of performance.

I think ultimately that this is why computer books don’t sell in the numbers you’d expect. If there are 7+ million developers, why does a good selling computer book sell around 20,000 copies?

(The exceptions being end-user books and theory books. End-user books because end users just want the answers, and theory books because they often rise above the petty bickering of the real world. Every faction can interpret theory books to say what they like to hear, so everyone likes that kind of book. Theory books virtually always “reinforce” everyone’s different world views.)

I think the reason “good selling” books do so poorly though. Only a subset or faction within the computer industry will agree with any given book. That faction tends to buy the book. Other factions might be a few copies, but they get a bad taste in their mouths when reading it, so they don’t recommend or propagate the book. Instead they find other books that do agree with their world view.

Note that I’m not complaining. Not at all!

I’m merely observing that C# people won’t (as a general rule) buy a VB book, and Java people won’t buy a C# book. OO people won’t buy a book on DataSet usage, and people who love DataSets won’t waste money on an OO book. People who love the super-complex demos from Microsoft really hate books that use highly distilled examples, while people who just want the essence of a solution really hate highly complex examples (and thus the books that use them).

As I write the 2nd editions of my Business Objects books I’m simultaneously writing both VB and C# editions. Several people have asked whether it wouldn’t be better to interleave code samples, have both languages in the book or something so that I don’t produce two books. But publishers have tried this. And the reality is that C# people don’t like to buy books that contain any VB code (and visa versa). Mixed language books simply don’t sell as well as single-language books. And like it or not, the idea behind publishing books is to sell them – so we do what sells.

But that solution doesn’t work for realistic vs idealistic database designs – which is my current dilemma. You can’t really write a book twice – once with an ideal database and once with a more realistic one. Nor can you really double the size (and thus cost) of a book to fit both ideas into it at once.

So I’m settling for the only compromise I can find. Parts of my database are pretty well designed. Other tables are obviously very poor. Thus some of my forms are trivial to create because they come almost directly from the “ivory tower”, while other forms rely on more complex and less ideal techniques because they come from the ugly world of reality.

Maybe this way I can get nasty emails from every group :)


Thursday, August 11, 2005 3:48:43 PM (Central Standard Time, UTC-06:00)
You couldn't have possibly worded it better. People just need to realize that to demonstrate an isolated concept that the book is about, the code will have to be isolated on the frictionless surface it will run on.

The problem isn't the author, it is the armchair author (reader), who doesn't realize that the author's goal is the get his point across, and not try and impress you with all the cool stuff he knows.

It's a tough battle to win. :)

_ SM
Thursday, August 11, 2005 5:10:30 PM (Central Standard Time, UTC-06:00)
What kind of people do you expect would defend using a poorly designed database for their applications? Just because people make mistakes in the real world doesn't mean that you should repeat them, especially if you know better.
Joe Chung
Thursday, August 11, 2005 6:14:18 PM (Central Standard Time, UTC-06:00)
Joe, it isn't that people defend their bad database. They typically know it is bad because they fight with it day in and day out. But they are also typically STUCK with it and need to build applications against it whether they like it or not. Databases often live for decades, applications merely for years...

So the complaint isn't "please show me how to build crappy databases", but rather "please show me how to build apps against crappy databases, because that's what I've got". Or to put it another way "don't show me how to build apps against perfect databases because that just pisses me off - show me something REAL dammit!"
Friday, August 12, 2005 1:36:50 AM (Central Standard Time, UTC-06:00)
I think it's definitely important to show that the ideas you outline in the book works with a real word database, i.e. one that has some not so well designed parts. Knowing from experience that this is often the case (you wouldn't belive how bad designs I've seen out there).

However, I think it's also important that, in the book, you point out why some parts of the db is bad. It can't take more than a few pages maximum to outline why it's bad and how it should have been. Experienced readers will understand from a brief review, and the not so experienced ones will know that it's bad (but maybe not why). Hopefully they'll counsult other sources of information to find out the details.
Jonas Risbrandt
Friday, August 12, 2005 10:23:31 AM (Central Standard Time, UTC-06:00)
To get working code to use, readers have to go to a web site. What if you used the ideal database samples in the book and provided the real-world database samples (and additional explanatory text) as an article on the web site?
Friday, August 12, 2005 4:37:07 PM (Central Standard Time, UTC-06:00)
Without reservation I can declare that there are enough bad examples in the world, and not enough good ones.

If you want to write a book on refactoring (code, database, architecture), then there is a reason to show the "before", but ONLY because you're about to show the "after" and how to get there from here.

Please, be a leader and show the right way.
Saturday, August 13, 2005 12:54:44 PM (Central Standard Time, UTC-06:00)
Rocky,

I can only say thank you for the v1.0 book. That really crystalized a lot of thought in an exciting way.

I would say that I disagreed with the v1.0 approach to the database, specifically the abhorance towards NULL state in columns.

Dealing with "real" databases where folks stick "-1", or "''", or "0" or anything that doesn't "relate" to a foreign key is one of the most consistent and worst practices that all comes from programmers saying ... "NULL? yuck!"

Of course this is a rant, but I want to encourage you to encourage other programmers (who often have more "Design" input into a database than they are qualified for) to do the right thing up front and also PUSH for the right decisions over the course of the years that they write against the database.

Most of my exposure to databases that I couldn't modify or extend have been old databases that we were moving off of anyway. I wrestle with a horrible database design on a daily basis for a product, which leads to daily fantasy-thought of a complete ER rewrite and migration path - alas, code must get out.

As a GENERAL practice however I encourage the use of:
- 6 standard columns per table (CreateDate, CreateUser, ChangeDate, ChangeUser, Active[bit], RowStamp[timestamp])
- Identity key vs. GUID or compound key (it works across MS replication, is fast, and can quickly identify a row - compound keys are relegated to UNIQUE index or constraint)
- Restrict access to tables via stored procs or other abstraction
- Bust out tables for unused fields in a 1:1 relationship and use views or stored procs to reconstitute for specific scenarios
- Index on FK column
- *NEVER EVER* tie a report to the table itself, always a database abstracted object (view, stored proc)
- DEACTIVATE rows vs. DELETE rows to maintain historical picture // I rarely find a user who really means DELETE when they try to remove something - you still will have InvoiceDetails that shouldn't appear and should be DELETED, but DELETING a customer just doesn't do it... the Active field (above) does the trick and I just extend your objects


I'm eagerly awaiting your thoughts and design approach in CSLA 2.0. A current VB6 vertical app needs a labotemy and I am awaiting its medicine: .NET 2, CLSA, CodeSmith, Database Redesign.


I'm also excited about the two language editions, I'm half tempted to take our VB6 team and shove all of us into C# just so we GET that .NET is DIFFERENT.
Brett Veenstra
Saturday, August 13, 2005 7:35:51 PM (Central Standard Time, UTC-06:00)
Well I'm not writing a book on database design, I'm writing a book on how to build apps against a database - presupposing that it already exists. My concern is that if I only show how to build the app against perfect databases it will reduce the value of the book, because that's the trivial case. The app building really only gets interesting if you have non-perfect database structures.

Of course if I use a "perfect" database then it will radically shorten my chapter because the tools do most of the work. But anyone without a perfect database will be entirely in the dark on what to do...

I am not a database expert, nor do I pretend to be, nor do I want to become one. That's a whole field of expertise by itself. This is why I am a strong supporter of stored procedures - as they provide a strong abstraction layer between me and the database so I don't _have_ to care what goes on behind the curtain.

But in this case the use of stored procedures will come later, with dynamic SQL to start with, so the actual database structure matters...
Monday, August 15, 2005 7:44:11 AM (Central Standard Time, UTC-06:00)
Sorry I went of the DB deep end..

Have you considered an abstraction of the schema itself?

If you could extend that, then you could have a consistent picture of a "good" database design to write your book against.

Perhaps a custom section of the App.Config could allow for an area for developers to document relationships, defaults, values that should be treated as "NULL", etc. Or this section could extend generated XSDs created by Visual Studio. In the end a single CSLA class could be used much like the ProfileProvider for ASP.NET.


This rant from a small fish in big pool.
Brett Veenstra
Monday, August 15, 2005 7:56:45 AM (Central Standard Time, UTC-06:00)
I think the replies to the original post go some way to illustragint your point :-)
Tim Ensor
Monday, August 15, 2005 8:34:45 AM (Central Standard Time, UTC-06:00)
Isn't this the truth... just when you give out some sample code someone comes along with 'agh that's really not the best practice'.

I like your books Rocky.
Monday, August 15, 2005 1:42:10 PM (Central Standard Time, UTC-06:00)
Brett, in this case (believe it or not) I'm not using CSLA. Instead I'm using the new DataSet and strongly-typed DataTable features in Visual Studio 2005. And using them, I am providing an abstraction of the database - creating custom DataTable objects that provide a more useful view of data by either normalizing or denormalizing the data as _I_ need it regardless of the underlying database structure.

I've decided to stick with the mixed database design btw. Parts of the database are normalized nicely, and at least one table really sucks. But it sucks in a way that is so common out there and I think I'd be doing a bad thing by not showing how to overcome that kind of table by using the new VS 2005 features.
Monday, August 15, 2005 2:51:00 PM (Central Standard Time, UTC-06:00)
Can't wait! I remember listening to your camio on DNR a few shows ago and wondering how you were planning on integrating the DataTable and specifically hooking the ESC behavior found in the databinding. It was a familar comment from CSLA VB book on why you needed to use C# for a part of the databinding to handle what Microsoft didn't have quite right yet.

I hope you didn't take any of my comments as flames!
Brett Veenstra
Monday, August 15, 2005 5:55:58 PM (Central Standard Time, UTC-06:00)
I haven't seen a flame here yet :)
Monday, August 15, 2005 6:01:04 PM (Central Standard Time, UTC-06:00)
I definitely understand your point about being damned if you do, damned if you don't. I can only offer a suggestion to help curb some of the "enthusiastic" emails you may receive, and that is to include a short chapter or appendix at the end of the book that describes the good, the bad, and the ugly. Depending on just how much your book talks database design you could even describe what makes the bad bad and the ugly ugly and how to turn both into good design.

For what it's worth, I don't care what route you take...as long as there's a C# version of it!! ;-)
Trevor Braun
Wednesday, August 17, 2005 9:54:20 AM (Central Standard Time, UTC-06:00)
Personally, I was happy that you only had the VB.NET version in the beginning because I wanted to learn C#. While working through the VB.NET version of the book, I converted the code to C#. I not only learned more about VB.NET but also learned about C# at the same time. It gave me a much better understanding of both languages and the differences between them.

I doubt that I would have done that if you had a C# version from the beginning.

I'm also a big proponent of _real_world_examples_. There is nothing I hate more than something that is contrived for the sake of example. I feel that as long as you point out why the example you use is "bad" then the db purists can take a hike. As you said, you're not writing about db design.

Keep up the great work Rocky!
Sunday, August 21, 2005 9:51:30 AM (Central Standard Time, UTC-06:00)
Rocky,

I have always enjoyed your books. As a trained teacher, I'd much rather see you focus on the topic at hand. By focusing on making everything else "perfect" including a "perfect" database, exception handling and other code extraneous to the topic, it makes the code less readable.

I find this perfectionism frustrates many people. The less experienced may find the long listings overwhelming or unclear. When the experienced reader encounters this, she may think, “Yes, I understand all the extra code I need to add in my applications. Does he need to include it in every example?”

Yes, in the "real world" your code should look very different. However, you are not writing a tome on "real world" development, you are presenting a structure for building scalable applications.

I'm also in favor of some disclaimer in the preface or wherever you deem appropriate which states your approach. Then, when you receive e-mails from those perfectionists, you can kindly refer them to that page.

If you are ever looking for another technical reviewer, please feel free to send me an e-mail.

Best Wishes,

Rich
Rich Beck
Comments are closed.