Search results matching tags 'Database Design' and 'Writing'

Chapter 8–Patterns and Anti-Patterns

drsql — Sun, 10 Jul 2011 17:29:42 GMT

In this last kind of “creative” chapter, I will look at some of the ways you implement common problems in your relational database, and some of the ways you probably shouldn’t. The “should” sections will deal with:

Uniqueness – Beyond the simple uniqueness we have covered in the first chapters of the book, looking at some very realistic patterns of solutions that cannot be implemented with a simple uniqueness constraint.
Data Driven Design – The goal of data driven design is that you never hard code values in your code that don’t have a fixed meaning. You break down your programming needs into situations that can be based on sets of data values that can be modified without affecting code.
Hierarchies – A very common need is to implement hierarchies in your data. The most common example is the manager-employee relationship. In this section I will demonstrate the two simplest cases, and summarize other methods that you can explore
Images, Documents, and Other Files – There are quite often a need to store documents in the database, like for a web users’ avatar picture, or a security photo to identify an employee, or even documents of many types. We will look at some of the methods available to you in SQL Server.
Storing User-Specified Data – You can’t always design a database to cover every known future need. In this section I will cover some of the possibilities for letting the user extend their database themselves in a manner that can be somewhat controlled by the administrators.
Generalization – In this section we will look at some ways that you will need to be careful with how specific you make your tables so that you fit the solution to the needs of the user.

This marks an increase of a 4 sections from the last book, when I added this Patterns chapter. I did take away a few bits about sequence and calendar tables, but I do plan to move this to a later chapter on development, where I will discuss the sorts of objects that I find nice to have in each database and why.

For the anti-patterns, I am adding one more in this edition, on undecipherable data.

Undecipherable data – Too often you find the value 1 in a column with no idea what 1 means without looking into copious amounts of code.
One-size-fits-all domain – One domain table to implement all domains rather than individual tables that are smaller and more precise
Generic key references – Having one column where the data in the column might be the key from any number of tables, requiring you to decode the value rather than know what it is.
Overusing unstructured data – The bain of existances of the dba, the blob of text column that the user swears they put well structured data in for you to parse out. Can’t eliminate a column for notes here and there, but overuse of such constructs lead to lots of dba pain.

This is one of my favorite chapters because it really gets to the core of design. Up until now we have stuck mostly to basics and fundamentals, building very basic structures and working with the object types available to us. Here we build practical solutions to solve common problems.

From here, the next chapter we will move along to security, structures, and then putting the finishing touches on things. Hopefully soon I will have some exciting new about a final chapter that will tie it all together once I get final approval and acceptance from the guest writer on this chapter.

Chapter 7–Enforced Data Protection

drsql — Tue, 21 Jun 2011 04:36:13 GMT

As the book progresses, I find myself veering from the original stated outline quite a bit, because as I teach about this more (and I am teaching a daylong db design class in August at http://www.sqlsolstice.com/… shameless plug, but it is on topic :) I start to find that a given order works better. Originally I had slated myself to talk more about modeling here for three chapters, then get back to the more implementation topics to finish out the book, but now I am going to keep plugging through the implementation tasks, then finish up with modeling task (which I hope I might end up getting some help with…emails are going out once I talk it over with my editor).

In the last edition, the chapter on data protection was more inclusive, including programmatic data protection, including client code and stored procedures. But, keeping with the basic, implementation type chapters (and trying my best to shorten chapters to more realistic chunks (the free chapter shouldn’t be 1/2 of the book, or so I am told), I will put that off to probably the final chapter.

This chapter was broken up into two main sections, Check Constraints and Triggers. I will demonstrate the following scenarios, and if you see anything missing, please do make suggestions

Check Constraints

Simple value checks – Like when you want to make sure there are no blank string values CHECK (len(value) > 0)
Value reasonableness checks – Like if a value should be a non-negative integer, CHECK (value >= 0)
Checks using different tables – Like setting up a data driven format check

Triggers – Broken down by AFTER and INSTEAD OF Triggers

AFTER

Range checks on multiple rows – Like when you want to make sure that the sum of rows related to (and including) the newly inserted rows is > 0
Maintaining summary values (only as necessary) – Denormalization, pure and simple, but if you are going to do it, triggers are the way to go (you really shouldn’t)
Cascading inserts – Like creating child rows to ensure a 1 to at least 1 row relationship is met, or creating a parent
Child-to-parent cascades – Like deleting parent rows when the last child row is deleted
Maintaining an audit trail – Also something that will come up in security, but implementing an audit trail of actions on a table. Less needed these days with auditing, but
Relationships that span databases and servers – sometimes you just have to implement RI between databases, so it is back to 6.0 style RI

INSTEAD OF

Automatically maintaining values – For example, if you want to implement a bulletproof rowLastUpdatedTime column to know when the row last changed, but don’t trust the client (who does?)
Formatting user input – Like formatting words in all caps, or proper case. Another thing that might be better done outside of SQL Server, but it is very straightforward to implement
Redirecting invalid data to an exception table – For example, eliminating data that is outside of the norm. Possibly done better outside of SQL Server code, but if you really want to build something that takes previous data into consideration, this might be a reasonable way.
Forcing no action to be performed on a table, even by someone who technically has proper rights – Simple do nothing trigger that works because in an instead of trigger you have to replicate the action, so you don’t.

It might seem weird to consider formatting data or redirecting invalid data to another table as data protection, but the point of data protection is to make sure that they data ends up in a reasonable state, and triggers can do some “magical” seeming stuff. Admittedly, triggers are not a fan favorite with many programmers because they do those magical stuff that they cannot directly control, but in many ways that is the point. If the dev forgets to update the last update date, the ETL may not see the row, and oops your data is out of sync.

In any case, I do my best to make it clear that you don’t in fact have to do any of this, but here are the tools in the tool bag.

Normalization and How to Know When You Are Done… The short version…

drsql — Sun, 29 May 2011 20:54:15 GMT

A while back, I was working on a short article about Normalization for a book that never got published (admittedly I wasn’t getting paid for the article, and it wasn’t for charity, so I wasn’t that broken up over it.) The task at hand was to, in 2 pages or less, describe the process of normalization and help you to know when you have finished. In my upcoming book Pro SQL Server 2000 + N (where N > 10) Relational Database Design and Implementation, it takes about 45 pages. So it wasn’t really a realistic task, especially considering I have spent about a full paragraph letting you know how hard the task is going to be. The most important thing that is missing from this short introduction is examples, which I include in the book in truck loads.

There are two distinct ways that Normalization is approached. In a very formal manner, there are a progressive set of “rules” that specify “forms” that you are working to achieve. There is nothing wrong with that definition, but progressing through the forms in a stepwise manner is certainly not how any seasoned data architect is likely to approach the problem of designing data storage. Instead, you design with the principles of normalization in mind, and use the normal forms as a test to your design.

The problem with getting a great database design is compounded with how natural the process seems. The first database that the past uneducated version of me built had 10+ tables, all of obvious ones like customer, orders, etc. set up so the user interface could be produced to satisfy the client. However, tables for address and even order items were left as part of the main tables, making it a beast to work with for queries, and as my employer wanted more and more out of the system, the design became more and more taxed. The basics were there, but the internals were all wrong and the design could have used about 50 or so tables to flesh out the correct solution. Soon after (at my next company, sorry Terry), I gained a real education in the basics of database design, and the little 1000 watt halogen light bulb went off…

That light bulb was there because what had looked like a more complicated in the college database class that no normal person would have created (bet you can’t guess what my grade was in that class!) was really there to help my design fit in with the tools that I was using. Turns out that the people who create relational database engines use the same concepts of normalization to help guide how the engine is created that I needed to for a database to work well. So if the relational engine vendors are using a set of concepts to guide how they create the engine, it turns out to be actually quite helpful if you follow along.

First, lets look at the “formal” rules. The normalization rules are stated in terms of “forms”, starting at First Normal Form, and including several others some of which are numbered, some are named for the creators of the rule. (Note that in the strictest terms, to be in a greater form, you ought to also conform to the lesser form. So you can’t be in third normal form and not give in to the definition of the First). To be honest, it is rare that a data architect will actually refer to the normal forms in conversation specifically unless they are having a nerd argument with a developer that is trying to design an entire customer relationship management system in a single table, but understanding the basics of normalization is essential to understanding why it is needed. What follows is a very quick restatement of the normal forms:

First Normal form/Definition of a Table – Attribute and row “shape”
- All columns must be atomic—one value per column
- All rows of a table must contain the same number of values – no arrays
- Each row should be different from all other rows in the table – unique rows
Boyce-Codd Normal Form – Every candidate key is identified, and all attributes are fully dependent on a key, and all columns must identify a fact about a key and nothing but a key.
- Encompasses:
  - Second Normal Form - All attributes must be a fact about the entire primary key and not a subset of the primary key
  - Third Normal Form - All attributes must be a fact about the primary key and nothing but the primary key
Fourth Normal Form - There must not be more than one multivalued dependency represented in the entity. That is to say that every attribute relates to the key with a cardinality of one. Not a common rule to violate, but it definitely does occur.
Fifth Normal Form - All relationships are broken down to binary relationships when the decomposition is lossless. Very rarely violated in typical designs.

There are other, more theoretical forms that I won’t mention, but they are rare to even encounter the definition. In the reality of the development cycle of life, the stated rules are not hard and fast rules, but merely guiding principles that can be useful to help you avoid certain pitfalls. In practice, we end up with denormalization, (meaning purposely violating a normalization principle for a stated, understood purpose, not ignoring the rules to get done faster) mostly to satisfy some programming or performance need from the consumer of the data (programmers/queriers/etc)

Once you deeply “get” the concepts of normalization, you really will find that you build a database like a well thought out Lego creation, desiring how each piece will fit in to the creation before putting pieces together, because disassembling 1000 Lego bricks to make a small change makes Legos more like work than fun. Some rebuilding based on keeping agile can be needed, but the more you plan ahead, the less data you will have to reshuffle.

In actual practice, the formal definition of the rules aren’t thought of at all, but instead the guiding principles that they encompass are. In my mind, I use the following four concepts in the back of my mind to guide the database I am building, falling back to the more specific rules for the really annoying/complex problem I am trying to solve:

Columns - One column, one value
Table/row uniqueness – Tables have independent meaning, rows are distinct from one another.
Proper relationships between columns – Columns either are a key or describe something about the row identified by the key.
Scrutinize dependencies - Make sure relationships between three values or tables are correct. Reduce all relationships to binary relationships if possible.

The question in the title still has yet to be conquered. “How to know when you are done?” What I left out of the description of Normalization was the granularity you go with. The word “atomic” is a common way to describe a table or column that is normalized enough. Atomic would tend to indicate something that is broken down to its absolute lowest form. But unless you are not a nerd (and would you really be reading this if you weren’t?) we know that there are lots of particles smaller than an atom. When you try to mess with particles smaller than the atom, you get a mushroom cloud that even Timothy Leary would not have approved of.

It is the same way with databases. Tables and columns split to their atomic level have one and only one meaning. Deal with them at a higher level, and you will suffer with lots of substrings, switching attributes that you use to find out what a table means in a situation. But break things down too far, and you will suffer even more. My best example of this is a column that holds a large quantity of text. If you never need to us part of the data using SQL, a single column is perfect (a set of notes that the user uses on a screen is a good example.) You wouldn’t want a paragraph, sentence, and character table to store this information. On the other hand, that same character column is abused when the users start putting coded information (because users WILL find a way to work if your software fails them). Then and you have to search for, you will need to begin working with the less comfortable string manipulation functions in SQL… And just try to index a part of a large text column. Possible? Sometimes. Best way to go? Never.

The key to knowing what is normalization and what is an academic exercise for a nerd is to understand the needs of the users (commonly referred to as requirements, as in “Why don’t we ever have good requirements before we code!?!”). If it is clear that the user is planning on maintaining a list of values and will need to update them programmatically, then it is your job to make each value a row in a table. But if there is no requirement to ever search on a value in that list or programmatically access part of the value, then it might be overkill to do anything other than leave the value alone. It is often best to err on the side of caution, but the ideal relational storage for a document would be minimally at the word/punctuation level. If you are read this far and are convinced that would be the proper solution, then you need to get a complete book or take a class on the subject before you start creating a relational database.

The reasonable answer to when you are done normalization is when users have exactly the right number of places to store the data they need and you can query/use the data without parsing it… Easy enough until the user changes their mind, huh?

Chapters Two, Three, and Four

drsql — Wed, 23 Feb 2011 04:21:39 GMT

I am trying to blog all of the chapters of the book, but due to deadlines and a lot of shuffling about, I never got around it for these three chapters, two of which I have added since I wrote the original table of contents. All of these contain mostly material from previous editions of the book, updated a good amount, but nothing tremendously different if you had memorized the material from the previous edition. As such, the pre-writing blog ritual wasn’t as necessary (for me at least) as it is going to become in the next few chapters after these.

Part of the material was stuff I had previous intended to cut. I got to the end of Chapter 1 and started to feel that I hadn’t done nearly enough on requirements, so I resurrected 1/2 of the last edition’s chapter 3 on conceptual modeling.

Chapter 2 is now a short, fifteen or so page chapter about how necessary requirements are and some tips on finding them.

Chapter 3 is a data modeling overview using IDEF1X, and really hasn’t changed too much other than fixing some mistakes from the previous edition, particularly in the description of Information Engineering/Crow’s Feet modeling’s graphical elements. Of course I still have a open question mark for the Denali parts of this chapter… who knows what is in store?

Chapter 4 is the rest of the Conceptual Modeling chapter from previous editions. When I started to jump from modeling to the Normalization chapter, it felt really just too harsh, plus I am having second thoughts about how I plan to present modeling and implementation. I am thinking about presenting sub-models to demonstrate all of the different patterns you can model along with how to implement them in a single package. I really am struggling to find a way to write this stuff in a manner kind of like I use when I teach a day long course, which I think goes along with how people learn.

I still have a good amount of work to do before I get there, and first off I have some work to do on the Normalization chapter to get make it more concise and clear, based on some reader feedback (my favorite part of the writing process is getting constructive criticism, so email me at drsql@hotmail.com if you have any, or leave comments.)

Design Book–Dimensional or No Dimensional, that is..the question

drsql — Wed, 01 Dec 2010 02:29:31 GMT

So, it is right there in the title of the book “Relational Database Design” etc (the title is kinda long :) But as I consider what to cover and, conversely, what not to cover, dimensional design inevitably pops up. So I am considering including it in the book. One thing I try to do is to cover topics to a level where you can start using it immediately, and I am not sure that I could get a deep enough coverage of the subject to do that. I don’t really feel like it has to be the definitive source on all topics, but it should be usable.

For example, I have a chapter on physical structures, indexes, files, partitions, etc. After reading the chapter, you will have a good enough feeling for the structure of the database to know the basics of applying indexes, partitions, filegroups, etc and a good amount of when and where to apply them. In the end, I usually direct readers to go elsewhere for the truly advanced coverage of the SQL Server Internals (like the books of the owner of the http://www.sqlserverinternals.com/ domain, in fact).

In this case, I am not really thinking that a full chapter is possible, but more of a quick intro. Fact and Dimension tables, and an example or two. The real payoff will be in the case study chapters where I could include a basic set of tables to demonstrate how offloading reporting to a dimensional structure could be done and how it can be used to produce a reporting model that takes the complexity out of writing reports. No ETL coverage of course, and I would use a complete reload script to simulate the data.

Admittedly, the point of these design book blogs is to talk myself into or out of doing something, and usually I pretty much have the answer by the time I am finished. In this case I am still not sure. On the good side of thing, I won’t have to just say “data warehousing, good idea, denormalization, bad idea, get another book and find out”. On the other hand, can I really cover the topic deep enough to make it worthwhile? I don’t think I can include an example in the case studies and not introduce it in the skills chapters.

Design Book– First Section (Skills)

drsql — Tue, 23 Nov 2010 03:04:23 GMT

One of the main things that I haven’t always loved about the previous books is that it wasn’t a perfect reference book. I focused on having a flow throughout the book that, not unlike a school class, started at the beginning and finished at the end. Interspersed were semi-cohesive examples that followed along in an entire chapter (once even for the entire book). The downside to this was that it became necessary to make examples that were often contrived and felt a bit weird at times. So if the desire was to demo the First Normal Form, it was required for me to not immediately eliminate a non-scalar value, have some columns like payment1, payment2, etc. In the real word, no one with any skill does this. You immediately make a new row per value in a comma delimited list that the user wants to store, immediately create a payment table, etc. Even worse there are some tools (like triggers) where there is good value in discussing and demonstrating the power of the tool, but honestly you rarely will make use of them.

So this time, instead of setting up examples with a story, I have a plan to break the skills from the case study style usage examples and hopefully this will give me the ability to have standalone sections for each skill such that as a re-reader you get the skill, sample code, and everything packaged right there in one location. The examples will be less real world in some cases, but I find that more often than not, when I want to find some example, I use bingle (bing then google) find the topic I am looking for, and then copy the code.

This first major section is going to include many such reference bits for the process of modeling the database, which I am calling “Modeling The Database – Base Skills” would be broken down something like:

Theory/Concepts/Requirements – The basic stuff that you ought to know to get started in relational database. Theory more or less for a history lesson to get you going and understand from whence all of the stuff came from. Admittedly I don’t expect it to be the most read part of the book by any stretch of the imagination, but I do plan on using the information from the pillars blogs I did a few years back (and am developing a new PowerPoint deck based on for a session, perhaps at the Louisville SQL Saturday?) to set the tone and context for the rest of the book.
Language of Data Modeling – Data modeling using the IDEF1X method with examples in other styles
Normalization – In many ways, teaching normalization as the individual forms is not completely necessary for people to make progress. But, the fact is, having knowledge of the normal forms is very useful to getting your mind in tune with what you are doing. It very much reminds me of the process of learning calculus. In the first class, we basically spent months on learning how to prove and work through the process of doing a derivative. Then they taught us the trick in 10 minutes of how to do one. The trick is the way to do it, but only once you know why it is done that way.
Techniques and Patterns – Technically, once you know what and how to do a data model, and you know the techniques involved in normalization, you have all of the tools you need to get started. However, there are many techniques and patterns that regularly show up and knowing what they are can be extremely helpful.

Some of the example patterns I plan to work with include data driven design, uniqueness, optional data, hierarchies, and perhaps even a touch of dimensional design thrown in to illustrate that important method of avoiding denormalization by offloading querying. (I will blog this topic individually once the outline blog series has completed).
Testing – One of the harshest criticisms I received from the previous edition was the lack of coverage of testing… So in this edition I plan to include the basics of setting up a test plan, particularly as it regards setting up the specifications for testing. In later chapters I will try to pepper sections with ideas for testing, but

By the end of this section, ideally the reader’s toolbox should be loaded up with modeling skills and be ready to do some modeling. In the next section we will apply these skills and actually create a few models. Note that the toolbox will be full of modeling “techniques”, not “implementation” techniques. As a rule, I have pushed those techniques to the latter half of the book. In the third section of the book, I am thinking that starting from the tool (constraint, trigger, procedure, client code, etc.) and demonstrating how to implement the types of techniques and patterns (and doing testing, which in and of itself may end up in the third section in total.)

I am not 100% sure if this is going to be the final way to go or not, but that is why I am doing this in the blog. Writing it out for you is also a mental exercise for me to see how it sounds when I read what I write.

Design Book–Top level outline

drsql — Wed, 17 Nov 2010 04:10:12 GMT

The more I teach sessions about database design, the more I realize that two things are true. First, most people don’t dig the normalization stuff as much as I do (some do), and second, people really need the normalization stuff more than they think.

The really hard part is how to flavor the medicine just enough such that it will be read by more people, but no so watered down that it does what it should. In past editions, I have tried to mix a lot of examples, and long examples, in with the basic skills. As a complete read though, I think this works pretty well. But for myself (whom is in fact my most important reader), I use the book for two things.

1. A cohesive example that shows how to do the process

2. Learning and reviewing particular skills

I find that the examples are excellent ways to get a handle on the entire process, but rarely do these seem valuable in a reread. In fact, they basically get in the way. What is super useful, even as the writer of the book, is to have the fully searchable ebook to look for certain skills and an example of the skill. For example, on the rare occasion I need to write a trigger from scratch, I whip out the ebook, search for trigger, and bam, I have the basic code I need.

So the current plans are to separate the book into 2 sections, each with 2 minor sections:

Modeling The Database
- Base Skills - Theory, Normalization, Alternative Modeling Techniques (Dimensional), Testing, Table Patterns, Testing
- Logical/Conceptual Modeling – Several case studies that will use most of the base skills in a manner to show the reader an example of how to put it all together. This section will be the location for the cohesive examples
Implementing The Database
- Techniques for implementing the Model – DDL, including Triggers, Constraints, etc; Security; Examples
- Physical Abstraction Optimization – Structures: Database, Table, Index; Concurrency; Datatypes; Data Quality,

Next step is to break down each of the sections into chapters and start a bit of discussion (if in fact, only with myself) about what to put in the main text of the book.

What is a physical database?

drsql — Thu, 11 Jun 2009 22:26:36 GMT

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, etc used to store data
The actual on-disk structures.

Frankly, until 3 years ago, I used the first interpretation. However, I was beaten up pretty badly by a few people whom I don’t really remember (I think Anith Sen was one of them.) The problem is, I was scolded, “physical” already had a meaning, given it by the “founder” himself, EF Codd.

So, checking his 12 Rules, Codd stated the following two things:

Rule 8: Physical data independence:

Changes to the physical level (how the data is stored, whether in arrays or linked lists etc.) must not require a change to an application based on the structure.

Rule 9: Logical data independence:

Changes to the logical level (tables, columns, rows, and so on) must not require a change to an application based on the structure. Logical data independence is more difficult to achieve than physical data independence.

And actually, the implementation layer really is the logical model if you follow his terminology since his rules were pertaining to the relational model and not the entire design process. This article says it better than I can in a long blog, but I am not sure about that URL (mac.com?):

http://homepage.mac.com/s_lott/iblog/architecture/C465799452/E20080301143528/

The physical layer of a relational database occurs down at the file system level. Codd's "Rule 8" (Physical Data Independence) says that the things we're designing in ERwin (and similar tools) are the things our application depends on. These are not physical in nature, but are the relational implementation.

So the thing I am trying to say is that physical means that a little 5 volt charge is sitting there representing a bit of data in the physical world. I like the term logical to mean implementation platform non-specific.. The thing in the middle is the SQL Server/Relational implementation specific model. It may take liberties to optimize for SQL Server, but it is not physical. That is were partitioning. indexing, filegroups, etc come in. Changes to this layer ought never be noticable by the application.

I guess in the comments, I ought to expect a good number of replies that might start to answer the question. Does it matter? Is it only semantics? Hey if you don’t think semantics matter, I hope that when you find yourself drowning that the person who has the choice of tossing you a life preserver or a sack of door knobs interprets the meaning of your cry for help in the way you intended. You would hate to find yourself at the bottom of a lake thinking “hmm, I wonder why they did that? Did they hate me, of just mis-interpret the meaning of my sentence?"

Book Reviews – Again

drsql — Mon, 20 Apr 2009 04:53:00 GMT

I have gotten a few more reviews in, and interestingly I appreciate the negative ones almost as much as the positive ones. I prefer the negative ones that have decent star ratings better… but what are you going to do.

The most recent review was critical of the book for not having mentioned testing. I actually think that this was really good criticism and have already started my planning for how to rectify this. The only thing I wish this reviewer had done was mention the rest of the book. This person has three reviews on Amazon and some cool stuff on his wish list (if we ever meet, I will be happy to buy you an expresso/cup of coffee and discuss the rest of the book, which pretty much goes for anyone, if you want. I will also buy you lunch at my favorite restaurant: Prince’s Hot Chicken Shack. Only rule is that we have to talk about the book at least a little).

Please, if you have read the book, oh please (am I begging), I beg you (yes, I am begging) to please email me your feelings on the book or post reviews. I would love to know what you thought of it. I just want to make the book better and who knows, I usually give out a few copies of the next book (no guarantees) if the advice is really constructive.

The real problem here is that writing is a VERY slow process. If my book was electronic, I could start writing and shoehorn in the new material and be done with it. But a book is not like a website. I wrote the book as a cohesive 650+ pages that are supposed to work together as a unit. Unlike a set of web pages, my hope is that you will skim 1/2 of the book and read at least half (which half depends on you, but I like both halves.) And in each edition, I try to give more and more information as I find it, learn it, and on a few shining occasions, make something up.

In the first edition, the process was simply that I wrote what I thought I wanted to say, and editor(s) hacked that to bits. So about 10 people were involved in the creation. Now, working on the fifth edition I have had hundreds of people give me feedback, and a fairly small percentage tell me stuff that was missing that ruined the experience for them. I take these comments VERY seriously, especially if I agree with them. If you compared version one to the fourth version, a lot of the stuff I was really enthused about didn’t make too many people all that excited, so I cut it. In this last version, I have more examples, more code, and more technique, because it was asked for.

Now if I just knew if this reviewer liked anything else about, or if there was more that was disliked I could possibly make the next book even better. So if you have any ideas/feelings/criticism/etc email them to louis@drsql.org. Thanks!