Re: Db2, Oracle, SQL Server

Mark A wrote:
> > > In some cases, leaving the locklist small and encouraging lock
> > escalation is
> > > good, because row locks are more expensive (time consuming) than
> > table
> > > locks, especially if concurrency is not an issue.
> >
> > When concurrency is not an issue, Access will usually provide an
> > acceptable solution.
> >
> > --
> > MJB
>
> Maybe you are not familiar with large data warehouse databases? You
can
> check the TPC-H benchmarks at http:/www.tpc.org to get some idea of
the size
> of a typical data warehouse database.

You should stop guessing. You are wrong.

> If you have a data warehouse (decision support) database, concurrency
is not
> a problem unless you are trying to load data a the same time as you
allow
> people to perform queries.

So concurrency is an issue, unless you never load data, which appears unlikely. Or you shut the thing down while it is being loaded. If its big then that could represent a lot of data being unavailable for a long time, which does not bode well for ROI numbers.

> In this sub-thread discussion (as well as the normal usage of the
term)
> concurrency means ability of multiple users to access the same data
with
> Locking Problems.
>
> The ability to access the same data without performance problems is a
> different subject, and not the same thing as concurrency.

I know what concurrency is, I am questioning whether it is viable to have any database that does not have to deal with it. Except a single user system, hence my suggestion.

-- 
MJB