<div class="gmail_quote">2011/11/17  <span dir="ltr"><<a href="mailto:michael.vancanneyt@wisa.be">michael.vancanneyt@wisa.be</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="HOEnZb"><div class="h5">I really don't see why you think SQL databases are slow. We have lots of</div></div>
queries running on our system, huge amounts of updates, and Firebird does an extremely good job of it, and we do almost only multi-table select queries. Concurrency is not an issue at all with their multi-generational architecture - no locking is needed.<br>
</blockquote><div><br></div><div>I believe your DBs are fast but I have seen really slow ones. I think the complexity of queries, the amount of data and amount of users are the key factors.</div><div><br></div><div>The delayed response of many web-sites is caused by slow DB access, not by slow program code or slow network connection.</div>
<div><br></div><div>In a big company I was involved with PDM, eMatrix object DB which was built on top of Oracle relational DB. It created mystical table structure for the objects. Normal queries took seconds but if your query would return tens of thousands of items it practically halted and the process had to be killed.</div>
<div>Another DB was an Oracle ERP. It also had complex table structure and lots of data, and queries typically took seconds. It was running in a computer that was the fastest in our country when it was bought!</div><div>The table indexes could not be wrong because many people had optimized them.</div>
<div><br></div><div>I in fact created a solution for browsing and searching the PDM data quickly, using VirtualTreeView + data dumps read into memory.</div><div>In many cases the reading should be optimized and fast because it happens often. Writing can be slow, in most cases nobody cares.</div>
<div><br></div><div>Juha</div><div><br></div></div>