LarchDatabase < LIAS

r6 - 02 Aug 2005 - 18:29:30 - BobKrzaczekYou are here: TWiki >

LIAS Web > LiasArchitecture > LarchDatabase

This topic hosts the discussion on the database platform on which we host the LiasArchitecture. Note: you should definitely review LarchDataIndexing to see what's driving this discussion. You might also want to see LarchOverview and LarchHurdles.

You can quickly skip to the most recent part of this conversation by following this link: LarchDatabase#LastComment

The initial part of this discussion occurred in email. I've transcribed it here to the wiki for reference. Please, I encourage feedback and further discussion; add your responses onto the end of this note. If you're curious or new, you might be interested to know that this topic is following an overall style called Wiki:ThreadMode which is common in many wiki communities. -- BobKrzaczek - 26 Jul 2005

Howdy... I'm gonna need some database access as soon as y'all can get to it. I'd prefer to have a user and database under PostgreSQL. I don't know if you'd like to set up a separate server, or just add me to the one that's already there. Either way is cool with me. I'll probably be accessing it mostly from lias.cis.rit.edu. -- PatrickStein - 10 Jul 2005

We only have a MySQL database installed. If you want PostgreSQL, Bob has one of them running on his machine, but his machine isn't backed up at this point. -- SjM - 10 Jul 2005

Unfortunately, that reply was captured by a spam filter embarrassment

and never seen by PatrickStein. So, the conversation repeated again on July 19. -- BobKrzaczek - 26 Jul 2005

I hadn't realized it, but Bob had installed the PostgreSQL stuff in /cis/. Actually, it doesn't look like it's the latest version... but I think it's an acceptable version.

I can just use stuff right out of there. And, I can create the database myself. But, there are still some things that I need from y'all. If there are any problems with any of the following, let me know:

a place to put the database.... I'm thinking somewhere on /lias... probably /lias/db/ and preferably mounted in from somewhere big like /export/lias on pegasus. (Actually, the database shouldn't be too very big by itself, but it will have lots of collected images along with it... and it would be good if both the DB and the images were physically attached to the same machine.)

a Unix-user (liasdb?) so that I don't have to run the database as me... having the user in group lias would be nice.

an entry in /etc/rc?.d on the machine that's serving things up to restart the db after reboots.

it'd also be extra spiffy if the PostgreSQL install in /cis/bin went from 7.3.3 up to 8.0... but you should check with Bob before tackling that one to make sure that won't wreck what he's already got.

Let me know if there will be any problem with any of this... or if you think there's a better way to arrange it or something.... -- PatrickStein - 21 Jul 2005

[ I've cc'd Nina here, since DIRS might have interested in a GIS enabled database...]

Just some quick points, responding to the recent thread between Pat and you all...

LIAS requires a database that supports spatial, or geometric, data types. We're managing images that are mapped onto ground coordinates, flight lines, swaths, and so on. We need to be able to query for intersections of these data sets with various location and other identifiers. I know that PostgreSQL supports this as "geometric data", that Oracle supports this as "spatial data", and that MySQL has an extension for "OpenGIS Geometry Model". If you know of other databases with that functionality that you'd prefer us to use, Pat and I are all ears.
The PostgreSQL installation on the CIS Solaris package drive is
1. 3.3, or 7.3.4, or something around there. It's been a while since I built and deployed it. This is the version that's running on chapman right now. The current PostgreSQL version is 8.0.
While Pat certainly could set up and deploy his own database, and it's very nice of him to offer, this is exactly the sort of thing that's been a problem in the past. It's unfair to the CIS admins to expect them to be responsible for something they didn't set up, and it's unfair for Pat to suddenly become a part-time administrator. We should have no interest in seeing the events that unrolled with chapman's PostgreSQL, DIRS, and myself being replayed with LIAS and Pat.
I can set Pat up with access to chapman's existing database, and he can co-exist with the DIRS folks. This should be no problem, assuming the geometric datatypes are present in PostgreSQL 7.3. But, this database is supposed to be going away, isn't it? DIRS is supposed to be migrating to another database somewhere else in the Center (not that I know much about where they are with that). When they're done, I plan to turn this chapman database off. So, putting Pat on this database is, at best, a temporary solution.
The existing database in question on chapman is backed up every night to titan:/lias/home/chapman. There's no point in backing up the tree on chapman, since you can't dump/restore a running database.

So, we're asking for help. We want to work within the existing support structure (rather than the "do it yourself" approach from the past). Plus, maybe there's some potential synergy here with DIRS' needs?

What should we do to move forward? Is there a database with this functionality ready to be rolled out somewhere? Or should Pat start developing on chapman until it's ready? Since RIT's all about Oracle these days, does it make sense to deploy one of those, instead of you building a MySQL with OpenGIS support, or building a more recent PostgreSQL, or is there another database you'd prefer we look at?

What's your advice? -- BobKrzaczek - 22 Jul 2005

I seem to be mis-understanding something. Are you saying that Pat can't use MySQL (which I told him we could give him an account on) or does he want more support for it? We have MySQL working on our Saturn, Jupiter and Pegasus. I know DIRS is trying to get off of Chapman (your installation of PostgreSQL) also, so I agree putting Pat on there is not a good solution.

I would also prefer that we don't have 2 different databases to support on different machines.

I apologize if I seem confused. -- SjM - 22 Jul 2005

MySQL has geometric functions. But, at this point in their lifetime they take terrible shortcuts. If you ask, "is this point inside this polygon?" they instead answer the question "is this point inside the coordinate-aligned bounding box of that polygon?" That's a very different question if the polygon is somewhat thin and oriented diagonally across the coordinate system.

Bob's mail implied that there might be a way to compile MySQL with some other package to get real functions for those things. That'd be much better. I don't know anything about this. From the MySQL documentation online:

"The OpenGIS specification defines the following functions. Currently, MySQL does not implement them according to the specification. Those that are implemented return the same result as the corresponding MBR-based functions."

Where MBR is 'minimum, bounding (coordinate-aligned) rectangle'.

On the other hand, PostgreSQL also has some features that MySQL just doesn't have that it would be nice to take advantage of. It has a mechanism whereby one table can inherit from another table. It's essentially an optimized version of making a view that combines the info from two different tables. I can hack around the inheritance with views, I think. However, MySQL has only started supporting views as of version 5.0. which is still marked as the "Development release" (as opposed to the "Generally Available (GA) release (recommended)" one). I can hack around it even without views, but it'd be really ugly. (Actually, I'm not sure I can insert into views the way that I want since I'm running MySQL 4.1.3 not 5.0).

I would also prefer that we don't have 2 different databases to support on different machines

Understood. Sadly, MySQL and PostgreSQL have some differences and most of the Open Source world has built for MySQL. PostgreSQL is an all-around better product. *argle* -- PatrickStein - 22 Jul 2005

Note: This message is probably truncated; I've recovered what I can _of it. Mea culpa. -- BobKrzaczek - 26 Jul 2005

As I mentioned I'd really like to get a picture of all of LIAS database/GIS needs. From my understanding you need some GIS tools and some database tools. It sure would be nice if they were all interconnected to avoid unnecessary duplication.

The industry standard in GIS are ESRI products. Their products can connect to some external databases.

For example supported database connections for ArcInfo^? Workstation 9.1 on Sun Solaris 9 (SPARC) For Database Integrator (DBI):

INFORMIX Dynamic Server 9.40.UC2
Oracle 8i (32 bit) 8.1.7.0.0 (Oracle8i Server)
Oracle 9i (32 bit) 9.2.0.3.0

-- NinaRaqueno - 22 Jul 2005

Yes... all of those databases cost large sums of money. RIT has licenses for some Oracle stuff, I'm not sure which yet. And, from my SOFIA experience, we should avoid INFORMIX.

ArcInfo^? Workstation also costs a bunch, too, right?

I'll have to look into what ArcInfo^? actually uses the Database Integrator for. From the overview you gave me in March of how one would interface with ArcInfo^? Workstation, I'm not sure exactly what ArcInfo^? Workstation would want with a database.... how it would know what tables were relevant and what data in those tables is useful, etc.

So... Harvey and/or Bob can correct me if I'm wrong. But, the initial major goals from my point of view are this:

Index the collected WASP/MISI/other data
Make it easy to add a new collect to the above indexes
Provide some tools to browse what's there
Provide some tools to select/download subsets of what's there

One aspect of #3 and #4 should be exporting layers for ArcInfo^? to use. But, it would be very nice if we could also put together something useful for those without an ArcInfo^? license. There are some freeware GIS tools that will probably also be able to use the layers. But, my plan was also to employ Google Maps to let you do #3 and #4 entirely in your web browser if you wanted.

For #1 and #2, it matters that the database have at least a minimum amount of functionality. I don't think MySQL has that functionality. I know PostgreSQL has it. I suspect Oracle 9i does too. I don't have an Oracle license myself.... so if it's going to have to be Oracle, then I'm in a holding pattern until someone hooks me up with a db.

One of the goals of #1 is to let it be distributed a bit so that maybe the WASP stuff lives on one machine and the MISI stuff lives on another and some group in Boise, Idaho hosts their own, etc. So, it'd be nice if the DB licenses weren't too pricey. Plus, if we go with a DB that I can have installed on my home machine, too, it'll make development tons simpler.

Another side goal of #4 is to keep track of which data you've downloaded/used etc. so that when it comes time to review the results of your processing, you've got a complete record of what data went into it.

So, if you've got any pointers about what ArcInfo^? Workstation does with the Database Integrator, that'd be cool. I'll poke around myself on the matter.

Here's the thing though... part of my goal is to mesh nicely with ArcInfo^? so that those who have it can use our data with it well, completely, fully, etc. The larger part of my goal though is to recreate enough functionality so that one can get to all of our data without having to buy an ArcInfo^? WS license. I'm not sure how much such a license costs since they won't give a price on their website. But, the "Single Use Licenses" (single user?) for their extensions range in price from $2,500 - $18,495. So, there may be some duplication involved. -- PatrickStein - 22 Jul 2005

We are checking to see if we have the OpenGIS module installed. If not, that should be easy to do. I agree with you about most of the Open Source being built for MySQL, that is one of the reasons we choose that over PostGres, the other reason is that we were forced to do it because of the undergraduate recruitment page. It was built using MySQL without ever talking to any of the sysadmins about what functionality was available. So no matter what, we either need to stick with MySQL or have someone port over the web pages.

I'll let you know about the OpenGIS module. SjM - 22 Jul 2005

Actually, I'm pretty sure there isn't an OpenGIS module. I think Bob got mislead by the MySQL documentation which documents a bunch of functions that are unimplemented. But, I dunno... maybe there is one and I got distracted by the documentation's claim that it's "supported but not implemented" whatever that means.

I know that with my install of MySQL 4.1.10, it silently fails a bunch of functions that the documentation says will work.

CREATE TABLE test (
    spot POINT
);
INSERT INTO test VALUES ( POINT(3,5) );

Says:

Records:1 Errors:0 Warnings:0
Rows Affected: 0

And, the table's still empty.

Brilliant.... no errors... no warnings... no insertion. The following works though:

INSERT INTO test VALUES ( PointFromText( 'POINT(1 3)' ) );

So... the MySQL documentation is a bit wonky on the GIS stuff. Some of it's documented but not implemented. Some of it's implemented as long as all of your polygons are coordinate-aligned rectangles or can be approximated as such.

Anyhow... let me know if you find otherwise.... -- PatrickStein - 22 Jul 2005

Actually, I'm pretty sure there isn't an OpenGIS module. I think Bob got mislead by the MySQL documentation which documents a bunch of functions that are unimplemented.

Awesome. MySQL just continues to impress me more and more...

So, unless there's something else for MySQL to make it work, I guess we can scratch it off the list of candidates. Pat's recent emails list the functionality that DIRS and LIAS requires: things like actual geospatial/geometric functionality, table inheritance, etc.

MySQL's functionality is a subset of PostgreSQL's and Oracle's functionality in just about every way that matters. I would assume that the people who built the recruitment page wrote it using PHP, or Perl's DBI, or similar abstractions; these cover up the overwhelming bulk of the differences between the databases. Depending on how important running a single database platform in the Center is to you, you may well want to consider migrating the undergrad recruitment to another database. It's fairly straightforward to do: dump, import.

Tech note: Because MySQL doesn't follow the SQL standards as closely as other databases, migration isn't as straightforward as a dump/restore. After you dump a MySQL database, you then edit the dumps slightly: adding semicolons where they belong, tweaking the column type fields in CREATE TABLE statements, fixing the ways that quote characters are handled, that sort of thing. You could probably even write a Perl script to do it automagically. Then you can just pour the edits into the other database.

This is just a suggestion, I'm not trying to tell anyone what to do. Unless the recruitment page makes extensive use of triggers or other fancy db hacks, there's no practical reason why they couldn't be moved off MySQL. If they're the only ones requiring MySQL, it's just something to think about. I remember questioning their MySQL "requirement" because it didn't make sense to me back then (I think Carl had similar questions), but I don't recall any answer other than "that's what they want"; that's a shame, it could have saved us from at least some of the present thrashing about. shrug

We're open to other database choices. Just to clarify and summarize, we named...

PostgreSQL because it seems to be able to do what we need.
Oracle was brought up because RIT is already a licensee, and Nina mentions it works with DIRS' GIS needs.
MySQL was brought up because it's also running in CIS, but that's clearly not going to work for us.
Informix was also brought up as a GIS candidate, but Pat and I would save you from that sad mess (based on our SOFIA experience) if we could.

That's where we stand, I think... -- BobKrzaczek - 23 Jul 2005

Actually, I wouldn't assume that the people who built the recruitment page wrote it using PHP's DB abstractions. PHP makes available a full suite of functions whose names start with mysql_ for dealing with MySQL dbs... a full suite of functions whose names start with pg_ for dealing with PostgreSQL, a full suite of functions for dealing with msql, etc.

For most PHP installs, you'd actually have to include the DB abstraction as part of your application. It's not something that's standardly installed.

So... depending... the recruitment page more than likely has code that explicitly says:

$db = mysql_connect( ..., ... );
$results = $db->mysql_query( "SELECT * FROM gorfo" );
$nn = mysql_count_results( $results );
for ( $ii=0; $ii < $nn; ++$ii ) {
    $item = mysql_fetch_row( $results );
}
mysql_free_results( $results );

So... it could be non-trivial to port it to a DB abstraction layer.

That said, I can't imagine that it would take me more than a day to convert the code to using an abstraction layer. How big is the recruitment page? -- PatrickStein - 24 Jul 2005

So, there's another option. If supporting another database is too much of a chore, Pat's offering to port the recruitment pages over for us. Sue, Jim, can one of you point us at all the pages that were delivered from the people who developed the recruitment pages? That way, we can look it over before making any committment/decisions. -- BobKrzaczek - 25 Jul 2005

Building the remote sensing GIS archiving capability is a core element of our technology plan. It is fundamentally important that we be able to provide potential sponsors with prototype systems built on our technology. To me that closes the door on proprietary databases such as Oracle or Informix. If a sponsor would like to use Oracle or Informix and could be supported by an interface based on open standards then we may consider it. However, it does not make sense for us to go the proprietary route with our in-house technology, especially when there is a good open-source alternative, even should the RIT Oracle license be "free" to us. Given the MySQL limitations for GIS, this seems to make PostgreSQL the obvious choice. I support providing some pro bono time from LIAS to help convert the UG pages to PostgreSQL if it is not more than a day or two of work. -- HarveyRhody - 24 Jul 2005

Today, NinaRaqueno, HarveyRhody, and myself had a brief meeting. Mostly, we just wanted to get DIRS and LIAS in better sync with each other about what's needed in a database, what's need in a GIS application, and what's available in the intersection of those topics (i.e., a GIS database).

Nina had a lot of interesting information; I wish more people were available at this meeting (which was totally impromptu, not scheduled, not formal...)

Some interesting points:

ESRI offers a database solution that not only serves GIS information but probably offers standard SQL (SQL99?) functionality. Nina is going to chase this one down further for us.
Delivering any kind of GIS data to any customer that involves ESRI tools would raise no eyebrows. Apparently, ESRI is the industry standard.
RIT has a site license for most, if not all, ARC* products from ESRI. There should be no problem setting up an instance of ESRI's database for our use in CIS. Nina notes that a license might have to be converted from Windows to Unix (Solaris?), but that should only take time, not funds.
If all this is true, we could deliver the LIAS Archive on top of a database from ESRI, couldn't we? I mean, we have no intention (yet) of doing things outside the standards, and thus a simple database abstraction could be created for this database as easily as one for, say, Oracle or PostgreSQL, right?

We should bear LarchDataIndexing in mind here: it's important that the database itself support table inheritance, insertion into views, and similar functionality, as well as the GIS data types (points, shapes) and queries (intersection, etc).

So, I admit it, I couldn't help myself. smile I was intrigued enough by what Nina told us, that I went out to http://www.esri.com/ and started reading. This is what I've gleaned so far...

It seems like their ArcSDE^? product is hosted on top of a standard database. It doesn't provide its own database, but instead all of its GIS functionality is mapped onto the underlying database.
If I'm right, this means that we can mine that database to our hearts content, and no worry about getting a chunk of data we can't understand. Everything that ESRI offers rides in this underlying database, which by the nature of these things, is available for our use.
Of the databases they support, the only one that makes any sense for us is Oracle, I think. I have to guess that there's no interest in setting up IBM's DB2, Informix, or Microsoft SQL Server. Sadly, there's no support for PostgreSQL or MySQL.

Going this way seems to have a distinct advantage: DIRS needs a full blown GIS database, as well as LIAS. This works for both of our groups. We'll have little trouble trading data with external clients and contract sponsors. Plus, all the other ARC* products work directly with this database.

Pat, I'd really like you to take a look at this and evaluate it for use on the LIAS Archive project. We also need someone to find out just what the licensing deal for Oracle to RIT is right now; Sue, can you or Jim follow up on that? -- BobKrzaczek - 26 Jul 2005

Looking things over, here's the list of popular GIS enabled databases. Obviously, ESRI's database is the leading contender since it's so widely deployed in the GIS world. Others?

ESRI
PostGIS
PostgreSQL (which is what PostGIS is built on)
Oracle (with spatial support)

-- BobKrzaczek - 26 Jul 2006

Hmmm... so something in this meeting swayed Harvey away from the earlier: "It does not make sense for us to go the proprietary route with our in-house technology, especially when there is a good open-source alternative, even should the RIT Oracle license be "free" to us." ??

I like the ArcSDE^? description. I'll have to dig more into the literature/features/FAQ/etc. I'm somewhat concerned that it's going to hurl data all around the database in such a way that I'm effectively not going to be add stuff to the database through JDBC on my own. On the other hand, it firmly claims that it's not a storage model. So, hopefully it will still allow me good control over what tables I have to work with. I wish I knew what "ensures well-formed geometric integrity of all spatial data" meant...

And, to correct a statement above... I want table inheritence, but I could make do with view if inserting into views works the way that I hope it does (but I haven't tried it yet). I don't need both inheritence and inserting into views. I want inheritence and views. But, inserting into views is only a requirement if I can't get inheritence.

Another thing from above that I'd like to call out is: "Delivering any kind of GIS data to any customer that involves ESRI tools would raise no eyebrows." For the most part, we're dealing in the data... not the GIS-ness, no? A geolocated image is what most of our users will want, yes/no? (and, for that matter, many will only care that the geolocation is approximately right...)

-- PatrickStein - 26 Jul 2005

To be fair to Harvey, nothing in the meeting really "swayed" him towards or against an open-source. Earlier in the day, we were discussing databases in general. I pointed out that, so long as we stick to a standard like SQL99, and use a database abstraction layer, there's really no reason for us to be writing something that's utterly specific to PostgreSQL or Oracle or... If I dump a PostgreSQL database (into files of CREATE and COPY statements), barring minor syntax cleanup, there's no reason it can't be imported into an Oracle database, for example. Indeed, I'd be really worried if the LIAS Archive was somehow specific to one database vendor.

I understand that data types vary between databases, and that there might be more variation between them regarding, say, a POINT datatype, than for a more common datatype. For example, some databases have a STRING type even though VARCHAR is standard. So, there's bound to be a little bit of "specific to a database" in the implementation. But, in my mental model, that's a lot different from stored procedures and other database-specific hacks.

I agree, the ArcSDE^? description is really appealing. I'll let NinaRaqueno answer here in more detail, but I think the overall intent was that DIRS is going to roll out a GIS database. They need one, they've got the license(s) for one, and they're going to get one to manage the ever-increasing data they've got. It makes sense for us to use the same platform. I suspect, but I don't want to put words in her mouth smile that if/when DIRS gets a GIS database going, they won't mind if we plink around in it for a little bit, testing and trying things out.

Thanks for the clarification regarding table inheritance vs. INSERT into views. As you put it, it makes sense. I think, in general, going with a modern database that seriously attempts to implement recent standards solves this for everyone.

You're right about what we're delivering to end-users, as well; but there's more to it than that. From Nina, I get the distinct impression that we might deliver imagery/data to end users, sure; but that we might also deliver, instead, "references" (of some sort) to the data in the database who will then connect to the database and hack on it with various ARCview tools. Apparently, this latter model is popular; we'd limit it to our own users at RIT, probably, but there you go. -- BobKrzaczek - 26 Jul 2005 - 9:55am

"I pointed out that, so long as we stick to a standard like SQL99, and use a database abstraction layer, there's really no reason for us to be writing something that's utterly specific to PostgreSQL or Oracle or..."

That's a good point. Until I've got a more permanent database setup somewhere, I'm starting to write stuff using PostgreSQL. But, I'm taking special care to do as little PostgreSQL-specific stuff as possible. Unfortunately, PostgreSQL explicitly says that SQL1999 provides table inheritence, but that PostgreSQL doesn't implement it the same way. I'll have to re-read the PostgreSQL docs and see if I can track down the SQL1999 spec to see if the part of it that matters to me still works.

Here's a snippet of PostgreSQL:

CREATE SEQUENCE people_id_seq;
CREATE TABLE people {
    id INTEGER DEFAULT nextVal( 'people_id_seq' ) NOT NULL,
    name VARCHAR(64)
};

CREATE TABLE cshers {
    nickname VARCHAR(64)
} INHERITS ( foo );

INSERT INTO people ( name ) VALUES ( 'Harvey Rhody' );
INSERT INTO cshers ( name, nickname ) VALUES ( 'Bob Krzaczek', 'Boba' );

With the above setup, PostgreSQL will return Harvey & Bob if you select from people but will only return Bob if you select from cshers [CSHers Are People, Too!]. As long as SQL1999 does something similar, then bonus. If, for some reason though, SQL1999 has INHERIT just mean... have fields with the same name as those in the base-table (so that selecting from people will not return Bob [CSHers Share Some Attributes With People!])... then I'm not sure what I'm gonna do. I'll have to look into the SQL1999 spec.

One thing though that SQL1999 leaves entirely up to the implementation though is users. Most of that problem is obviated by adding on a layer of our own users rather than making each of our users a separate database user. PostgreSQL supports user groups and then granting (or revoking) privileges to a group. It won't be a big deal if Oracle doesn't support them.... we can just graft on our own user layer and make client applications interact through servers that will enforce the permissions.

-- PatrickStein - 27 Jul 2005

It turns out that PostgreSQL's old behaviour was the "CSHers Share Some Attributes With People". Their new behaviour, to bring them in line with SQL1999, is that "CSHers Are People, Too". Bonus.

There's also a line in the PostgreSQL docs that says PostgeSQL^? supports multiple-inheritence but SQL1999 does not. That's fine by me.

More troubling though with PostgreSQL (at least) is: "Unique constraints and primary keys are not inherited in the current implementation." I'll have to play with this a bit. I'm not sure what that means. Can I have name be a UNIQUE field in people and then add the same name once as a person and once as a CSHer? twice as a CSHer?

-- PatrickStein - 27 Jul 2005

Ughh... the answers are: yes and yes. I can specify UNIQUE or PRIMARY KEY in both tables, but that only turns it into: yes and no. Wheee... Ah, well... I'm going to make them from the same sequence anyhow... so... while it would be possible to put two things in with the same key, it shouldn't happen.

-- PatrickStein - 27 Jul 2005

After a good chat with Gurcharan this morning, I think it might be useful to summarize our position.

LIAS initially made a request for a database with specific modern SQL features (e.g., table inheritance). We suggested PostgreSQL, but we're quite willing to work with other databases if recommended by the CIS sysadmins.
We've since learned from NinaRaqueno that DIRS is definitely heading towards a GIS enabled database for their own use.
Such a database, as we understand it, is leveraged on top of databases like Oracle and Informix. These satisfy our technical requirements above.
Why ask for multiple database platforms when one will do? Thus, LIAS will use the same db that DIRS uses.
The GIS tools that DIRS intends to use are licensed for the campus from ESRI. NinaRaqueno is looking into getting at least one of the PC licenses converted to Solaris or some other Unix-y system.

Open questions:

How has RIT licensed its use of Oracle?
Is Oracle provided by ITS, or has it been outsourced?
Can we use an Oracle that is managed by ITS, rather than deploying it locally in CIS? Should we?
- What's acceptable to LIAS may not be acceptable to DIRS.
- LIAS is in the early design stages of a new kind of GIS database system. We can accept occasional downtime and such.
- DIRS is an established user of modern GIS technology, using it to support existing contract sponsors. I doubt they have the time to put up with experimentation. ITS will have to support them as a production database.

My gut feel is that we should consider letting ITS provide an Oracle database for us, if they want, providing that they offer sufficient uptime and space for our use. The frequency that the RITSTAFF mailing list gets "Oracle is down until..." messages is cause for concern. -- BobKrzaczek - 01 Aug 2005

Insert your comments and responses here. Be sure to start it with a line that has a bunch (at least 6) dashes on it. When you're done, sign it with your name and date. You can cut and paste from the field right under your editing window. Thanks! -- TWikiGuest - 26 Jul 2005

LIAS

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback