|
|
| GeoCommunity Mailing List |
| |
| Mailing List Archives |
| Subject: | RE: GISList: Microsoft SQL Server Vs Oracle Spatial9i |
| Date: |
12/11/2002 02:34:12 PM |
| From: |
Dimitri Rotow |
|
|
>
> Dimitri Rotow wrote:
> > Sure. The fundamental architectural mistake is to embed the "spatial"
> > functionality within the DBMS.
>
> Bollocks. Once a seamless spatial dataset exceeds a certain size, your
> database needs at least a minimal spatial understanding to do real
> spatial indexing, or you will spend alot of time twiddling fingers
> waiting for your data to arrive at the amazing geoprocessing engine
Absolutely true. There are many scenarios for using Enterprise data so it
is important to consider the pluses and minuses of each case using "real
life" considerations.
So, for example, as you have pointed out if you have a huge data set with
100 users it won't be efficient to throw that data set into each of the 100
clients for a short, five second job of local geoprocessing.
But, there are many tricks that can help. For example, many data sets in
use by enterprises (such as standard base maps) do not change anywhere near
as rapidly as they are used. A smart, high level caching strategy can
retain data in a local cache so that once you've fetched data for local use
there is zero bandwidth or time required for retransmission.
So, the general balance is that small jobs done in an adhoc, occasional way
are better for the older approach. Big jobs done frequently in intensive
ways are better with the newer approach.
> idling on your desktop. Does everyone have data this size? No. Do even
> most people have data this size? No. But don't claim the application
> requirement does not exist at all.
>
> > A more modern approach is to distribute the geospatial computing within
> > spatially aware clients and to use the DBMS as, basically, a
> file cabinet.
> > In this scenario if you have 100 users doing geoprocessing you have the
> > power of 100 machines available.
>
> It's not a more modern approach, it is the same old approach, basically
> a glorified filesystem. :)
>
Yep. :-) It's a question as to whether the marketing efforts of DBMS vendors
(or "vendor" I should say since it is Oracle that is working this wedge with
Oracle Spatial) to convince people to take a DBMS-centric approach to GIS
spatial processing is the right thing, or whether one should continue using
a DBMS as a glorified file cabinet and keep the spatial action happening in
a GIS.
> I read the rest of your arguments and found them quite compelling. There
> is a large user segment who would do well to stuff their ears to the
> arguments of the large vendors and actually examine their business needs
> before committing to certain technology architectures. But there is also
> a small user segment (of very large organizations) for whom a
> centralized system with open access standards makes more sense. I don't
> think Manifold is trying to be all things to all people, just most
> things to most people, right? :)
>
Well, not quite yet. :-) I 100% agree that the centralized approach with
access mediated by things like SF-SQL makes more sense for many people. In
fact, I would go so far as to say that it might make more sense for the
*majority* of Enterprise users today simply because the majority of such
Enterprise applications today appear to be systems that provide access to
GIS data through relatively simple web interfaces.
By definition, such web interfaces are hopelessly primitive and low
bandwidth (see URL below), and most seem to be classic examples of small, ad
hoc retreivals. For example, "show me a small context map of the nearest
dealer". For that OGC's approach is fine. In fact, as the data set becomes
very, very large and the retrieval becomes very small the OGC approach may
well dominate.
However, we are more interested in a different type of "Enterprise" GIS,
where people are working together using the same data, where the power of
the system is used to enforce some common versioning, protect from
incompatible edits, etc. The OGC approach is less persuasive there.
For the record, I don't think Manifold's Enterprise Edition will be right
for everyone (it lacks, for example, elaborate automated roll-back as one
might find in a highly-evolved, multi-user source code control system such
as Microsoft's Visual Source Safe), but it certainly opens the door to high
performance, group GIS work for teams of a few dozen or few hundred users.
For that matter, at the price it makes sense for single users with large
data holdings to use it.
For the official rant on why web interfaces are hopelessly primitive
compared to modern desktop interfaces, see
http://exchange.manifold.net/manifold/manuals/5_userman/mfd50GIS_and_Network
ing.htm
Regards to all,
Dimitri
To unsubscribe, write to gislist-unsubscribe@geocomm.com
__________________________________________________
|
|
Sponsored by:
For information
regarding
advertising rates
Click Here!
|
