home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!gossip.pyramid.com!pyramid!unify!Unify.com!jde
- From: jde@Unify.com (Jeff Evarts)
- Newsgroups: comp.databases
- Subject: Re: 500'000 records - who does best?
- Message-ID: <0g3avp6@Unify.Com>
- Date: 5 Jan 93 18:09:00 GMT
- References: <18971@mindlink.bc.ca> <0t0avvy@Unify.Com> <brent.725766347@cc.gatech.edu>
- Sender: news@Unify.Com (news admin)
- Organization: Unify Corporation (Sacramento)
- Lines: 64
-
- In article <brent.725766347@cc.gatech.edu>, brent@terminus.gatech.edu (Brent Laminack) writes:
- >
- > >I believe that this thread started out as a "can anyone do this REASONABLY"
- >
- > >UNIFY 2000 can handle this (500K rows @ 30K per row). If you have the disk space,
- > >we have the database. :-)
- >
- > >Mischa is right... its not the users, it's the size of the database. The
- > >UNIFY 2000 database package can have individual table segments in the 16+Mb
- > >category, allowing over 500 rows per segment, so the table would only require
- > >10000 segments.
- >
- > Is this the same Unify company that tells me to try to keep all tables
- > to 16 or fewer segments? After that performance is said to degrade? If
- > memory serves, 10000 >>> 16
-
- Cute... but
-
- Performance _can_ degrade by one _virtual_ read per row access IF:
-
- 1. You have more than 16 segments in a table, AND
- 2. You are short on ram, AND
- 3. The row requested is not in a recently used segment.
-
- On a system wanting to keep 1.5TB of data
-
- 1. A lack of RAM is not likely.
- 2. Other latencies will overshadow the additional read.
-
- So it should not be a problem.
-
- >
- > >You would still have plenty of room for indices and the rest.
- >
- > >Performance is impossible to judge without getting your hands a little dirty.
- > >It depends on hardware, access patterns, indexing strategies, and a whole lot
- > >more, but in general UNIFY 2000 is very hard to beat in the performance area.
- >
- > There are other considerations, however. Ask Unify to do an outer join.
- > They can't.
-
- Hmmm. not _strictly_ true. There are many ways to do this in UNIFY, from within
- SQL and out. We do not have a DIRECT mechanism to do this because we try to be
- ANSI SQL compliant and ANSI SQL uses UNIONs to do what other database companies
- use outer joins to do. So although we do not have a nifty way to do this directly,
- you can get the job done (often more efficiently) by taking other routes.
-
- >
- > No brag, just facts.
- >
- > Brent Laminack (brent@cc.gatech.edu)
- >
- >
- >
- > -Brent Laminack (brent@cc.gatech.edu)
-
- Really, though. The base conversation was "can anyone handle this", and
- "can they handle it REASONABLY". The answer is still yes to both questions.
-
- Disclaimer: I'm a techie, not a sales-ie
-
- -Jeff Evarts
- --jde@unify.com
- ---#include <sys/disclaimer>
-