03.03.2016 17:57, Jim Starkey wrote: > The place to start is with a clear, well understood, and agreed set of > requirements. Here is a suggested starting point. > > First, some definitions. A "data space" is the collection of pointer and > data pages that hold the data from a single table. An > "index" (in this context), is the set of index pages that compromise a single > index on a table. A "database object" is either a > data space or an index. A "table space" consists of a page structured file, > a collection of management pages, and a page number > space that can hold zero or more database objects. > > The minimal requirements: > > 1. To extend the theoretical number of database pages in a database beyond > 2^32. > 2. To be as inobstrusive as possible so that no explicit configuration is > required for databases that don't use table spaces. In > other words, a default (root) table space. > 3. To allow a user to define and manage additional table spaces. > 4. To allow a user to define tables spaces for individual tables and > individual indexes. In other words, while indexes may default > to the same table space of the table data space, indexes may reside in > different table spaces. > 5. A user should be able to move a table data space or index from one table > space to another. Whether this is an on-line or > off-line operation is deferred to specific proposals. > 6. It should be possible to bring up a database with some or all table > spaces unavailable other than the root. > 7. A table space should have sufficient internal integrity to tolerate > operational problems resulting improper management of > database files. > 8. It must be necessary to allow the filename of an offline table space to > be changed.
Basically, i agree with above. > Personally, I think the following are also important, but not requirements: > > 1. There should be minimal changes to the on-disk structure. More > specifically, pages references in the ODS should remain as 32 > bits. This precludes allowing a database object to straggle table spaces. > 2. There should be as few changes as possible to internal page, index, and > data handling mechanism other than tracking the table > space for database objects for the CCH interface. > 3. It should be anticipated that table spaces will be abused, for example > replacing table space files with older versions. To the > degree feasible, this should be supported, and where not supported, > detected. I would add 4. Allow to specify FW and Read-Only settings on per tablespace level 5. Ability to bring individual tablespace off-line (and back online, of course) > Non-goals: > > 1. Change the size of record numbers > 2. Store blobs in other than the table's data space. Why not allow blobs to be separated from regular data ? > 3. Implement any ODS change other than those required to support table > spaces (other projects are fine, but should be layered on, > not part of, table spaces). Regards, Vlad ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
