Question Type 1 Storage Areas.

[ron]

OE 11.7.4 on Linux.

As per best advice -- I have always set-up Storage Areas as Type 2 -- and appreciate the various reasons why Type 1 Areas should never be used (except of course for Area 6).

However .... the system I look after is a package and like nearly all cases of using packaged systems -- we do not use every feature that is available. As a result there are 121 tables that are never used -- they are empty. There are also 20 tables that do get used but only ever have a single record in them.

If all of those tables and their indexes were put into a Type 1 Storage Area -- would there be any down-side? I can't see any.

It might seem like an exercise of "penny-pinching" -- but there are 30 copies of this database on the same server and I'm always scratching-around to save a bit of space.

Ron.

 

[Rob Fitzpatrick]

In a Type I area, records from different tables aren't segregated. They can reside together in a single record block. Index entries are segregated; a given index block contains entries from one index.

In a Type II area, I put small/empty tables in an area with small clusters (eight blocks per cluster). So the storage cost of a table (or any storage object) is 32 KB for a database with 4 KB blocks. Those 141 tables will cost you a total of 4.5 MB; about three floppies. Add 32 KB per index. So, roughly 10 MB all told. For all 30 databases, that's only 300 MB. Double those numbers for an 8 KB database block size.

When storage is pennies per GB, I don't see value in that level of frugality.

I much prefer to have storage area design rules that I can create, enforce, and report on programmatically. That way, unexpected exceptions (e.g. you're on vacation and someone else adds a Type I area) will jump out at you, rather than being lost in the noise. I don't use Type I for anything, given the choice.

 

[TomBascom]

In addition to what Rob said (which is 100% on target):

If some currently unused feature starts to be used you will find it much easier to move tables and indexes from an existing type 2 area to a more appropriate type 2 area. Even if you don't move them - having them in type 2 areas from the start is way better than having them be in the schema area when they unexpectedly start to be used.

Also the small tables may not be lightly used just because they are small. It is very, very, very common for tiny "control" tables to turn into bottlenecks precisely because they are small but very active. When the connection count and the activity level scale up these tables often see exponential increases in usage and serious LRU, BHT, and BF* latch contention can quickly develop. Having such tables in type 2 areas is beneficial because it spreads that activity over more blocks (by not mixing them) even though, from a "space" perspective, that might not be perfectly optimal.

No user objects in the schema area. No exceptions.