Spring 2003

here is a blurb from the intro:

Introduction

This is a book that relates my personal experiences and knowledge about building scalable and performant applications that make use of an Oracle database. It has been my longstanding experience that applications dependent on the database for processing - and today that is pretty much every application of note - succeed or fail based on how they use the database.

There are many schools of thought out there today that describe how to build applications that will scale and be performant but the one thing they all have in common is they use a database to store and process data and, if you strip away the GUI at the end of the day - it is really about data and processes accessing and using that data. Therefore, it is my premise that regardless of the tools you use, the approaches you take to implementing your application - sound and proper use of the database from day one will increase your odds of success many times over.

I am not going to promote the use of one development technique over another but rather will stress that database design and implementation and the choices you make as to what features to use in the database versus do yourself outside of the database in the application will affect you.



What is this book about?

This is not a book about "tuning after the fact" or "fixing a broken database" - although all of the concepts and ideas in here are applicable in that environment. You are at that point looking for how to fix things and that is in this book - however, unlike many other performance books out there, I will not show you the dozen scripts you need to run to find little ratios that tell you if your database is "OK". This book is about building it right from the start.


Who should use this book?

The target audience of this book is the development TEAM - the group of people that have 100% of the control over the overall performance of the system. This is contrary to the popular myth that the DBA is solely responsible and has total control over application performance inside of the database. The best way to understand that this is a myth would be to use a car racing analogy. The DBA is the pit stop guy who changes the tires, makes sure the engine is gassed up, that the car functions. If you give the pit stop guy (DBA) a Lincoln Navigator (a truly huge truck) and tell them to race the Indy 500 with it - what'll happen? The DBA can make sure the truck runs as fast as it can but he cannot affect the performance of the truck on a tight corner at 100+ miles per hour. There is really very little to be done after the car has been designed and built (short of throwing out the car and starting over - the car is the application here). That analogy is frightening in its applicability to so many systems. A Lincoln Navigator was built where a high performance Indy car was needed or vice versa. Remember - we need 18 wheelers, minivans, race cars - everything. There is no one size fits all here.
.......


we are shooting for about 600 pages. It is less "reference" then Expert one on one is -- more best practices (eg: why you need a test environment, why you need to benchmark, question authority ;), the tools you'll want and need, when to use MTS (shared server), ....

600 pages is the target (but then again, E-1/1 was to be 800 pages ;)

Really, shooting for 600 pages on this one.

thats the last thing we decide ;)

we write them and then see what fits...

2004 is sooo far away ;)

But anyway -- this current book I am working on for 2003 is a book for all versions. Consider it version independent. It applies to Oracle 6.0 as much as 9i.

amazon.com