Linux SE vs IDS
For a simple vertical to be installed in relatively small sites (4-10 users max), should I consider using SE instead of IDS on LINUX despite the major price difference? Reliability is the main factor and sites all lack dba skills. So low maintenance/support is vital. Comments?
Hi! Use SE, if your tables are not going to be very large, I say less than 1M rows and will fit on 2 GB partitions. This limit may be for SCO only - I am not using Linux yet. SE is very reliable and stable for small systems like this. Regards, Michael Joel Robinson wrote: > For a simple vertical to be installed in relatively small sites (4-10 users > max), should I consider using SE instead of IDS on LINUX despite the major > price difference? > > Reliability is the main factor and sites all lack dba skills. So low > maintenance/support is vital. > > Comments?
Joel Robinson wrote: > > For a simple vertical to be installed in relatively small sites (4-10 users > max), should I consider using SE instead of IDS on LINUX despite the major > price difference? > > Reliability is the main factor and sites all lack dba skills. So low > maintenance/support is vital. > > Comments? Well SE is rock solid and fine for smaller installations with a requirement for minimal maintenance. HOWEVER, it is NOT a 24x7 database server. You cannot safely archive it while there are active connections, for example. Crashed user programs can leave objects locked and that requires DBA intervention to clean up. There are several other similar minor gotchas to using SE in a production environment, it's just been too long since I've used it extensively to remember them all. If you can live with the limitations (like no variable length data types) SE is fine. Art S. Kagel
On Wed, 25 Aug 1999 18:44:41 GMT, "Joel Robinson" <joel@askjoel.com> wrote: >For a simple vertical to be installed in relatively small sites (4-10 users >max), should I consider using SE instead of IDS on LINUX despite the major >price difference? > >Reliability is the main factor and sites all lack dba skills. So low >maintenance/support is vital. > >Comments? > I'm using SE on Sun systems for sites with 10-30 users and database size of <= 1GB. It's very easy to install and to use (compare the 300 page manual of SE to 3000 page manual of IDS) and runs stable. Just install and run without complex configuration. If you don't have a 7/24 system you can backup the database files at night with a simple 'tar' or 'cpio' command (but you should do an "unload" over all tables, too). So a restore is no problem. You don't have to fiddle around with logical or physical logs, so the database administration is very easy. Axel
My feelings too but it is very hard to believe that I will be paying a PREMIUM for this - list price IDS $99 for the ongoing special deal vs list price SE runtime $250. There is thus a cost for simplicity. But given the typical site is 3-5 simultaneous users on a good day, the incremental cost is quickly offset by siteadmin problems with a more complicated environment. Perhaps, one day Informix will REALISTICALLY price the Linux port, but then why should they do something sensible like that. Axel Sander <axsander@okay.net> wrote in message news:7q479v$2qkv$2@news.okay.net... > On Wed, 25 Aug 1999 18:44:41 GMT, "Joel Robinson" <joel@askjoel.com> wrote: > > >For a simple vertical to be installed in relatively small sites (4-10 users > >max), should I consider using SE instead of IDS on LINUX despite the major > >price difference? > > > >Reliability is the main factor and sites all lack dba skills. So low > >maintenance/support is vital. > > > >Comments? > > > > I'm using SE on Sun systems for sites with 10-30 users and database size of > <= 1GB. It's very easy to install and to use (compare the 300 page manual > of SE to 3000 page manual of IDS) and runs stable. Just install and run > without complex configuration. If you don't have a 7/24 system you can > backup the database files at night with a simple 'tar' or 'cpio' command > (but you should do an "unload" over all tables, too). So a restore is no > problem. You don't have to fiddle around with logical or physical logs, so > the database administration is very easy. > > Axel >