Mike

If you have a database on your webserver I would strongly recommend a replication-based solution.

ie keep a copy of the database on the webserver, create a second copy in another location, and run updates between the two sites to keep them synchronized. There is always latency with a replication-based system, but you could manage it so data was at most minutes out of date.

Once you have the data local, you can do whatever you like generating VIEWs and so on. I am pretty sure you could optimize these so that they would not be too slow. From what you have said the local data could be read only so that the update process would only need to be one-way.

Roy Lambert wrote:

> Here we still don't really know the problem or what is to be achieved

Very much so. We have a classic "X-Y problem" here, in that the solution is being discussed, but the real problem is not known. The size of the data seems teeny to be causing a problem. I cannot understand how that little data could be the cause of the problem. As you say Roy, what is the data? And what is the view, and what is the plan to show the performance.

I would then go further, and ask where the data is coming from, and all sorts more. For example, I had one system where I could have thousands of clients asking for the latest info. But most of the time it wasn't changing, so I changed the code to ask "what is the current revision number". Then when the data changed, the revision was incremented, and if it didn't match the client's current version, they'd do the full request. But it improved performance very much. And also the data was cached, so the database was touched only once a revision.

But in general, you should be able to do a database lookup without any performance worries. Thus the "VIEW" is the next question - what is it doing, and could it delay some of that? For example, get a basic list of the fast data, but don't fetch the CLOBs until specifically asked for. That cuts a lot of time and data out.

So, more about the problem, then the best solution can be found.

--

Matthew Jones

Matthew


> I cannot understand how that little data could be the cause of the problem.

300 baud dial up modem on a bad line <vbg>

Roy

ps been there got the T shirt

Roy Lambert wrote:

> on a bad line

Mum! I'm on the computer! Put it down!

--

Matthew Jones

Matthew

>Mum! I'm on the computer! Put it down!

Youngster - however, I do remember my wife asking why we had so much fizzing on the line!

Roy

I have replaced the queries (VIEW) with stored procedures and performance is much better.