dnielsen (1) [Avatar] Offline
There is an important point that is missing from Chapter 1. It is a point that is particularly important because of the likelihood that a large proportion of your readers will be coming from a background with ESRI products, whether shape files or "geodatabases". Coming, that is, from a background where data are commonly stored in an un-normalized and crosstabbed form. Coming, that is, from a background of poorly structured data. In my (25 years of) experience, people with this background and little familiarity with relational databases will simply import shape files into a DBMS (like Postgres) and consider the result to be a database.

The point that should be made in Chapter 1, therefore, is that Postgres/PostGIS is (or should be) above all else a *database*, not just a different storage method for existing poorly structured data. The benefits of properly structuring the data are fewer errors due to data inconsistencies, lower maintenance costs, and greater performance. Those who are moving from shape files or ESRI "geodatabases" really should use the transition as an opportunity to improve the quality and efficiency of their data management.

This involves telling some readers that they ought to learn something about relational databases, which is a message that is somewhat at odds with the very gentle and undemanding introduction currently presented in Chapter 1.
regina.leo (265) [Avatar] Offline
Re: What a spatial database is not
Good points. We didn't want to put this in chapter 1 though. In later chapters particularly we go over that.
Part of the reason for trying not to be too pedantic in chapter 1 is a couple fold

1) From a marketing perspective - it will bore readers without providing substance to the statements. And its really hard to add substance without making this a book about how to design a relational database system. Tons more books on the subject that do a better job of that.

2) A good chunk of the audience are coming from the other side of the fence -- relational database folks who now have this strange thing called geometry to contend with or who are developers with a good sense of relational db but are just discovering the power of spatial analysis. They will be especially bored.

Admittedly many of these folks consider a database as a convenient dumb datastore to house spatial data and our intent is to change that.

3) This is just one of those lessons that I feel people need to learn by making mistakes. We started out 15 some odd years ago using relational databases, and we made many mistakes like that which you described and are better off for being allowed to make them and had a more enjoyable experience doing so. When it came the time to accept or deviate from standard RDBM philosophy we could point out exactly why instead of "Because someone said that's the way it should be"

I think once people start stuffing their shapefiles in a database and if you gently demonstrate how you can do something with it besides swash it around like a piece of meat, eventually people will see the light for themselves.
regina.leo (265) [Avatar] Offline
Re: What a spatial database is not
We've taken your thoughts into consideration and have significantly rewritten chapter 1. Some of it covers a little on data management side of things, though we try not to be too overwhelming. Hope you find that it hits closer what you were thinking about.

Leo and Regina