n this podcast Rob Steward explains how clouds are currently used for storing data and how this is going to impact the IT landscape. Read the rest of this entry »

The Data Access Handbook covers numerous causes for database bottlenecks, including hardware constraints, particularly with regards to memory issues. In this podcast Rob addresses issues that cause memory bottlenecks and explains how they can be overcome. The podcast lasts for 4:32. Read the rest of this entry »

In this podcast Rob Steward explains who The Data Access Handbook was written for, and what benefits they will get out of its content. The podcast runs for 3:00.

You can listen to the podcast by clicking on the following link: http://dataaccesshandbook.com/media/Rob7.mp3

From the Podcast:
Why would the development audience and the database architect be interested in The Data Access Handbook?

Rob Steward:

We wrote the book specifically targeting architects, programmers and DBAs. That may seem like a broad audience, but the reason that I can say that we targeted all three of them is that the book has different sections. The beginning of it we talked more towards the architect, but it’s also beneficial for the DBA or the programmer, in that we go through the concepts of what is middleware and why does it affect things. We talk about how it actually interacts with the network. How it talks to the database. What does that mean in your overall architecture? What are the architecture choices that you make, specifically concerning the middleware and how you access your data that have a great impact on your overall performances? And that’s kind of targeted again towards architects, but also to programmers.

And then we’ve got sections of the book – there’s three chapters where we go through very specific code examples using ODBC, JDBC and ADO.NET – and those three chapters are meant to be a reference for programmers to say, ‘If we take the concepts that we’ve gone over in the beginning of the book, how to we apply those within those standards?’ What does it mean when I say, ‘you need to make sure that you manage your transactions correctly?’ What does that actually mean when it comes to writing codes ODBC and JDBC? Therefore, very specific content for programmers, but, again, backup so the architects who first look at the problem or the applications, they understand on a conceptual level of how this thing needs to be designed. And then for the programmers, what are those specifics to code that you want to write to implement the architectures that we’ve talked about.

And then for DBAs – you know I talk to DBAs all the time – and DBAs are frustrated with the same thing; I’ve been told over and over by DBAs, ‘Well everybody always blames everything on the database; that it’s always in the database.’ And those guys, the DBAs, are probably the ones that know best that the problem’s not always in the database. Because they can tune and they can do these things, and it doesn’t make any difference. So they know it’s somewhere outside of the database, but again they’re not the programmers. But what this book does for DBAs is explain some of these things that the programmers are doing that has that big effect on the overall performance. So they can understand when those problems are on in the database, what kind of problems those could be. And what do they need to tell people to look for in their applications.

So I can say that we targeted this book at architects, programmers and DBAs, and I think there’s a lot in this book for all three of ‘em.

In this podcast Rob Steward explains why architects, designers, programmers, or DBAs have overlooked the middleware to improve database performance, and why he wrote The Data Access Handbook to help educate the community on the middleware’s importance. The podcast runs for 2:42.

To listen to the podcast, please click on the following link: http://dataaccesshandbook.com/media/Rob6.mp3

Podcast text:

Why was there such latency in focusing on middleware for these performance and connectivity issues?

Rob Steward:

Well I think that the reason many people overlook middleware network as a performance issues is because you can walk into Barns & Noble, or any Boarders, or you can go on Amazon, and you’ll see book after book after book written on how to tune those databases. And you can go to lots and lots of sessions and seminars, and entire conferences built on how do I tune my Oracle database? Or how do I tune my SQL server database? So what you hear as an architect, designer, programmer, or as a DBA is that all the problems occur on the database. And so that’s what the focus has been in our industry. In fact, there is a whole industry built around tuning databases. We all know somebody, who that’s their job. They may be a consultant that gets hired for a couple of months and look over somebody’s database configuration and tuning, and figure that out. Granted, that’s a very important thing. You do need to tune your database.

What’s not been out there is the general knowledge of what the impact of middleware can actually be. Now I sell software. I work for a software company that makes database connectivity, which is part of why I know all these things about the middleware, but I see it over and over. Now I’ve sold a lot of software because that middleware is actually the problem, and not the database.

And again I think the reason why that people haven’t realized it – or as much as they should – is because everything you read, and if you listen to the experts, they’re going to tell you all your problems on your database. Then if they can’t solve it by tuning, or doing the things that they do, they’re going to say you need better hardware. Well I’ve seen hundreds and thousands of times, literally, that that’s not the answer. The actually problem is in that middleware layer.

So I think people tend to learn, but they learn it the hard way. They’ve learned that they’re application doesn’t perform well enough. They’ve done what all the experts say. They may have spent millions of dollars hiring people to come in to try to tune their environment, and it still doesn’t work. And the reason it doesn’t work, again, is because that’s not where their problem was, or it’s where a small part of their problem was.

I guess I would sum it up by saying it is education. And again, the reason I wrote a book on the subject is because there’s just not any information out there, and there’s not people talking about what kind of impact middleware can have.

In this podcast, Rob Steward explains why readers will find The Data Access Handbook useful. The podcast runs for 1:38.

To listen to the podcast, please click on the following link: http://dataaccesshandbook.com/media/Rob4.mp3

Podcast text:

What will someone get out of The Data Access Handbook?

Rob Steward:

What you would get from The Data Access Handbook is a whole lot of knowledge, as well as tips and tricks, on how to make your database application performance scale much better. The book is full of explanations about why middleware and the network impact your performance. And then there are a number of chapters that we go into in significant depth on how these things affect your performance.

We also have a number of chapters where we talk specifically about coding with standards based APIs. So if you’re using ODBC, or you’re using JDBC, or you’re using ADO.NET, what are the specific things that you can do within those data access APIs to make your performance significantly better?

Also, how do you tune those things? We talk about tuning databases, configuration options, and indexes, and all those kinds of things. But middleware typically has a lot of tuning options as well. That can have just as big of impact on your overall performance as those tuning options on your server.

We go through the concepts in the book, and how they overall affect your application’s performance. But we also go into detail to tell you exactly how you manipulate those things to make them work to make your database application work faster.