hellerim (22) [Avatar] Offline
#1
Dear authors,

When you are contrasting NoSQL technology against RDBMs I find your statements sound a little blatantly.

First, it sounds as if a data schema is something bad. But you don't tell the reader how she finds out what to expect in the database otherwise or why a NoSQL database does not need one.

Second, the many transformations between the various layers from the application to the storage engine are criticized in a very sweeping way. However, these transformations do not stem from some over-engineering but have some pretty well-founded reasons for them. I did not yet read very far in your manuscript but I strongly suppose that a financial application would not be the very best candidate for being stored in a NoSQL system.

Third, storing the whole thing (e.g. an order with customer information in it) as one entity in a database raises the immediate question of how you would handle redundancy.

Fourth, of course, most of the relevant RDMSs of two day do have parallel- and multi-processing capabilities and can be operated in cluster configurations, so caching statements across machine boundaries is a reality with RDBMSs. I think I feel what you wanted to say - caching across loosely coupled nodes -, but you don't express this.

Fifth, you are mentioning agility but in the context of business processes. I suppose that your readership will consist in their majority of developers and other IT professionals, but not so many business people because of to many technical terms I would not expect them to be familiar with. In the IT context, in particular in software engineering, agility is a rather concrete thing. When building software this means that, in an agile environment, this is a very responsive process, even when you are using RDBMS technology.

I'm writing all this since your introduction appears - at least to me - as if it should create some market hype in favor of NoSQL technology by telling us simply to forget most about those old-fashioned technologies which should be avoided whenever possible. Phrases like "Making the transition from SQL to NoSQL" suggest such interpretation. But I think there is no force driving a transition - it is simply a fact that RDBMSs and NoSQL systems solve different problems (with a certain overlap). I would assume that NoSQL technologies now deliver the right tools to attack data storage problems to which no appropriate way existed to tackle them by means of relational technology. I hope to learn more about this from you.

Now I don't believe that such interpretation is really your intention. I believe that you are quite knowledgeable in relational technology. And I believe that you have to tell very interesting things even to old-fashionend RDBMS professionals. But I think it is the wrong approach to tell them that what they're doing everyday is probably suboptimal.

Another problem of your introduction is that when it comes to presenting examples of NoSQL technologies or their forerunners you are using terms that I would assume many of your possible readership might not be familiar with - e.g. "star-shaped set of dimensions", "OLAP", "ERP", and so on. If you expect readers to by acquainted with this, then you should not expose them to such an - excuse me - superficial argumentation against relational technology.

Wouldn't it be a better approach to consider the space of storage problems which could not be solved be relational technology appropriately, making some points about the differences between them and those handled by an RDMS very well?

Then, you are mixing two different aspects. One is the linguistic aspect. In the seventies of the last century, Dr.Codd overcame a problem the existing database technology - hierarchical and network - could not solve. Navigating such a database needed heavy programming and implemented hard links. Relational technology in contrast derives links between from the data dynamically. Two-dimensional tables lent themselves to his approach - SQL and database tables fit well together. A well-founded approach to the design of relational database models evolved, and the technology proved to handle redundancy quite well by avoiding it to a high degree.

When XML arose, there was no immediate way how an RDBMS could handle XML documents. Now XML is a linguistic approach to describe the semantics of documents and was primarily intended to support data exchange between systems, not to store documents. XML is implementation-agnostic, and it does not provide any way to navigate XML documents. The XPath standard was conceived for that purpose, and since its declarative power turned out not to be sufficient, a complementary standard, XQuery, was developed. Even then, this is a linguistic standard which should be implemented by data accessing technology. E.g. a couple of XSLT processors appeared on the scene which did just this and many things more.

Of course, many RDBMS came up to store XML documents as text lobs and integrated XQuery somehow with their respective SQL dialects. XML-DBMSs appeared on the market, open source and commercial, but up to today they cover a niche market only. The interesting point is that they are not table-based but still support schemas, XML schemas in this case, and many of them support XQuery.

Now - and this is the second aspect -, NoSQL databases are a new technology. At least to me, the naming does not mean "No SQL" but rather "Not only SQL". On a first sight, it appears to be a storage technology as opposed to a data access language. I'd like to read a little bit more in your introduction on why storage of (key,value) pairs is predominant there and how this helps solve some problems that cannot be handled by relational technology appropriately.

No, I really don't want to have the whole book already in the introduction!!! But I want to get a better idea about what to expect in the chapters to follow.

This is a quite long list objections I have against the introduction but by no means it is intended to attack you personally. I'd simply like to get a book in my hands that I can recommend to my students, and I believe that you will deliver it!

Kind regards,

Goetz Heller

Message was edited by:
hellerim
jfs.world (107) [Avatar] Offline
#2
Re: Introduction to sloppy
what is 'sloppy'? Some software u plan *to* introduce?

I can understand that English may not be ur first language - but pls edit ur subject so that ur post/s can get more attention...

It's not "Introduction *to* sloppy". But "Introduction *too* sloppy"?

Thanks.
hellerim (22) [Avatar] Offline
#3
Re: Introduction too sloppy
Thank you for your hint. I'll try to correct it. Further, I don't use SMSian, but I try to understand it. As to "sloppy", please see http://www.merriam-webster.com/dictionary/sloppy.

Kind regards,

Goetz
daniel.mccreary (21) [Avatar] Offline
#4
Re: Introduction too sloppy
Hello Goetz,

Thank you for your detailed feedback. We have read all your comments and I think that many of the concerns you cite will be answered in many of the chapters after chapter 1. We are also trying to give a fair and balanced consideration of RDBMSs, their strengths and weaknesses in chapter 3 so we hope you find time to review that chapter also. We also have new versions of the first four chapters coming out so some of the issues you cite will be addressed in these versions.

> I'd simply like to get a book in my hands that I can recommend to my students, and I believe that you will deliver it!

I am glad you are considering using this book for your students. What classes do you teach? What level are the students? We know that XML seems to be very popular in Europe and Germany in particular. Most of the native XML databases (eXist, BaseX) seem to have strong developers in Germany.

We have been using the content in this book in our training classes for corporations for several years and we think our approach works well for a broad audience. We continue to try to find ways to explain things clearly and are are interested to see if you have any additional ways to help explain how NoSQL is different.

We look forward to feedback from you and your students also.

Thanks! - Dan
hellerim (22) [Avatar] Offline
#5
Re: Introduction too sloppy
Hello Dan,
thank you for your answer. I'll continue reading through the chapters next week. Of course, I expect to learn more about the points I described in the following chapters.My concern is simply that many people will start reading your book with the introduction and then could be disappointed by getting a wrong impression.The really important thing which imho - you should clearify already in the introduction: Is NoSQL about to replace relational technology or will they peacefully coexist to cover a broader range of applications? Will the expertise gained on relational technology become useless, or will knowhow about NoSQL valuably complement it?
For my next class which is going to start in three weeks, I will be teaching on object-oriented software development for entry-level students at the Baden-Wuerttemberg Cooperative State University Mosbach. In these classes, databases will be mentioned only and, at best, some programming using databases will be done. However, I use to demand my students to work through some books and to report on them. The theme covered by these is not restricted to OO technology only but to common practices such as agile and other things you have to touch on during professional life.

Kind regards,

Goetz
daniel.mccreary (21) [Avatar] Offline
#6
Re: Introduction too sloppy
Reguarding:> ... my next class... on object-oriented software development...theme covered by these is not restricted to OO technology...

My hope is that I will have some good portions of chapter 11 on functional programming ready for your students to review. I think a very clear contrast between why OO does not scale to large data centers but functional programming does might be a good contrast. The fact that many NoSQL systems are written in Erlang shows how functional programming complements OO development skills. This might be a bit advanced for an intro class but the cost savings are very clearly documented in the AWS price per CPU hour for MapReduce.

I am glad to share my slides on functional programming if you are interested.
adavidow (4) [Avatar] Offline
#7
Re: Introduction too sloppy
I actually appreciated the time spent comparing the variety of "No SQL" approaches to RDBMS. I teach a class in cloud computing and one of the areas with which students have most trouble (but in which students are most curious) is "No SQL" and the variety of database approaches that are enabled when you have access to a cloud computing resources.

In our case, we may well focus on SimpleDB (we use AWS for the class practicum), but this is the nicest, and most accessible description of the general field I have encountered so far.

Looking forward to seeing the rest of the book as it is released.