"This is an excellent book. It is relevant, readable, timely, and technically accurate. The author has a good handle on what is important to the industry, separating the hype from the practical solutions."
-Rick Cattell"Peter's book is rich with code examples that will help you understand exactly how to follow his footsteps to get a working system."
-Mary Loomis
Building Scalable Database Applications: Object-Oriented Design, Architectures, and Implementation is a comprehensive and authoritative guide to building client/server applications by developing a stable and reusable business model. The business and database models illustrated in this book both address the unique challenge of manipulating object storage and retrieval from a developer's point of view.
Software engineers and programmers need this information to lead their development teams toward businesswide distributed software systems. This book demonstrates the pragmatic approach of integrating systems that are currently in use into a cost-effective and time-saving object-oriented system. The approach allows for the business model and the database schema to operate independently so that they can evolve individually, allowing them to be easily reused and maintained.
Highlights include:
This is the first book to thoroughly cover scalable database applications; Building Scalable Database Applications focuses on building independent models that are free from all database and user-interface aspects.
Peter Heinckiens currently conducts his research at the University of Ghent, where he is responsible for coordinating the strategic planning and deployment of software technology throughout the administrative section of the university. He holds the Belgian equivalent of an M.S. in electrical engineering.
0201310139AB04062001
Product Details
Would you like to update product info or give feedback on images?
|
|
Share your thoughts with other customers:
|
||||||||||||||||||||||
|
Most Helpful Customer Reviews
29 of 30 people found the following review helpful:
3.0 out of 5 stars
Half brilliant; half useless.,
This review is from: Building Scalable Database Applications: Object-Oriented Design, Architectures and Implementations (Paperback)
Near the beginning of the book, the author acknowledges two facts. First, much of the database development being done today is using RAD techniques with little formal design discipline. Second, object-orientation is a philosophy, not necessarily connected to the tool you use. Just because you are using C++ doesn't mean you are OO, and similarly you can use OO principles to improve the architecture of programs written using languages that aren't traditionally considered object-oriented. Unfortunately, if you aren't a C++ programmer, you won't get as much out of this book as you could. Chapters 1-4, 13 and 14 are brilliant. These chapters describe the mismatch between object architectures and relational databases and they lay out a philosophy that can be used to develop a solution. The middle chapters, where the author describes his particular solution to the problem (the Scoop architecture), are not nearly as helpful. As a Visual Basic developer who reads a lot about object-oriented programming, I am used to having to adapt what I read to fit within the limits of my chosen language. It isn't usually as much of a struggle as it was with chapters 5-12. I found two problems. First of all, where many authors would use examples to illustrate concepts from the text, this author seems to believe that his examples speak for themselves. The text is little more than filler between code segments. As I said, I am not unfamiliar with C++ examples, but the ones in this book are a chore. I had so much difficulty deciphering what they were doing, that whatever message they were intended to communicate was lost. Second, the examples are so dependent on C++ features like inheritance and operator overloading that they were utterly useless for me. Not to mention their dependence on a particular third-party SQL library (Dbtools.h++). It will be easier to find my own solution than to adapt his. Perhaps a C++ programmer would be able to use the examples in production code, but I would have been better served by higher level, more philosophical examples. UML diagrams that did little more than describe what functionality goes where would have been perfect. So in summary, I guess I still recommend this book to any programmer wrestling with how to apply object oriented techniques to database programming. You'll gain a clearer understanding of the problem and the choices you will be forced to make. Just ignore the author when he tells you that he has solved these problems for you.
3 of 3 people found the following review helpful:
4.0 out of 5 stars
Great info, but a little confusing,
By A Customer
This review is from: Building Scalable Database Applications: Object-Oriented Design, Architectures and Implementations (Paperback)
This book contains several great ideas for abstracting the persistence mechanism out from your business objects. Hienckiens provides several insightful ideas about applications development as such - e.g., regarding the persistence store as just another view on your business model, and creating "informationbases" instead of just databases. Overall, the examples were confusing, however - particularly because he outlines one method for instantiating a persistence mechanism at the beginning of the book (inheriting from PSets), but uses another for the example at the book's end (inheriting from a virtual IdObject). Still, great advice - a welcome addition to object-relational mapping theory.
6 of 8 people found the following review helpful:
1.0 out of 5 stars
A waste of time,
By
This review is from: Building Scalable Database Applications: Object-Oriented Design, Architectures and Implementations (Paperback)
There must be some kind of curse with books on objects and persistence. After being deceived with some book by Sessions some years ago, now I got seriously disappointed with this one. This 300-page book suffers from the "big wait" syndrome: it introduces the major topics again and again, each time maybe being a little more specific in some areas, but does not delve into central stuff until 80 pages have happened. That is reinforced by a broken rythm and too short sections that end when they are leaving introductory stuff and starting to turn interesting.Also, it contains a number of inaccuracies and inconsistencies. Naming conventions are awful or absent, both from the syntactical and semantical viewpoint; see code in p. 68 for a specially relevant example. A book with so much printed code should pay attention to this. Also, some concepts are plain wrong: tables using foreign keys pointing to other tables are not "joined" but linked or related (p. 51). Joining may come later through specific SQL queries using the JOIN keyword. Classes related to other classes don't necessarily result in objects "containing" other objects (p. 52), but referencing them. Most central to the book, the author claims that IM resolvers solve the problem of making library classes of which we don't have the source code persistent. What about privately held state? You cannot solve this problem as an afterthought without a good metainformation-based reflection infrastructure such as that of .NET, for instance. I don't think the Scoop architecture is much better than any other way to make objects persistent. Also, attributes are usually considered scalar properties of classes, but the author omits the "relation" or "reference" concept and uses "attribute" to mean any property of a class (p. 58, p. 71). Later, he discusses the issue (p. 176) but the conclussion he draws contradicts his previous use of the concept! Overall, the book shows a lack of sound conceptualization of object-oriented ideas, and is too geared to the pure programming of persistent objects from a clearly narrow perspective. The author ignores high-level persistent libraries (such as ADO in the Windows platform) and puts too much importance in C++, which definitely is not the most used language in database environments. For instance, the identifier of an object is not the memory address it occupies. That's just a not so convenient way to build object ids. The author builds on top of this by saying that an untrained programmer could start using Visual Basic in a few days; of course, my 3-year old daughter could also start moving pieces on the chessboard right now. But that does not mean she plays chess! I feel deceived about this book. I spent my money in a work edited by Addison-Wesley, which is a reputated firm from which I have read dozens of brilliant books, and this one does not keep the minimum level. The book cover shows the names of Mary Loomis and the Three Amigos, which undoubtedly endorse the book's value. What's their value?
Share your thoughts with other customers: Create your own review
|
|
Suggested Tags from Similar Products(What's this?)Be the first one to add a relevant tag (keyword that's strongly related to this product).
|
|
This product's forum
Active discussions in related forums
Search Customer Discussions
|
Related forums
|