On Tue, 9 Feb 1999, Zeugswetter Andreas IZ5 wrote:
> > and solving the data distribution as a separate effort.
>
> I also think, that this issue can not be solved with splitting the
> table extents to different directories. I would leave that issue to a
> Tablespace implementation. What I like though is the idea that all
> table files have the extent number in the filename, starting with
> tabname.1, and not having tabname (1. extent) tabname.1 (2. extent).
This is something we need to thrash out here ;-)
> Asside from that, I think anybody having a (non blob) table of 2-4 Gb
> and above should start thinking of a redesign of his data model. Often
> the solution is to have e.g. one table per year and a union all view,
> so that clients can access all data without even noticing. I think
> smart rewrite rules can be implemented, so that updates, inserts and
> deletes are routed to the correct table (let's call it fragment).
The senario I can think of, is a database containing astronomical
observations (aka tass http://www.tass-survey.org)
You have one row per object, and this table is indexed against not just
the position of the object, but its observed photometric properties, etc.
It would be pretty difficult to maintain seeing what the expected volume
of data is going to be.
--
Peter Mount, IT Section
petermount@it.maidstone.gov.uk
Anything I write here are my own views, and cannot be taken as being the
official words of Maidstone Borough Council