From what I have read (check out Understanding DB2: Learning Visually with Examples), IBM recommends that you place data, indexes, and long data (meaning LOB type data as well as deprecated types like LONG VARCHAR) into their own tablespaces.
Main reason is for maintenance and support. If the data is in different tablespaces you can backup/restore based on your needs. For example, table data is "more" important than indexes (as indexes have no purpose without data in the tables). So if your indexes are in a separate tablespace and end up corrupted or needing a restore, you only have to restore the indexes, not the whole table (of course you may need to run reorgs and runstats to make sure your indexes are up to date).
Regarding LOB's - unless they are declared INLINE, they are not stored directly with the table data anyway (and INLINE only works for LOB's of a certain size). Hopefully you don't have too much update activity occuring on your LOB (as that can be a little costly seeing as LOB's are never cached in a bufferpool and always retreived from disk). So having them in another tablespace can help there as well. You have a separate space to store the data and if the table data is corrupted/needing a restore, but the LOB's are fine, again, you could restore just the table data without losing your LOBs.
So if you think of IBM's recommendation. They would recommend you build your table as such:
CREATE TABLE MY_TABLE (
ID BIGINT NOT NULL GENERATED BY DEFAULT AS IDENTITY,
TEXT VARCHAR(100),
...
primary key (ID))
IN TS_DAT
INDEX in TS_IND
LONG in TS_LOB; --or TS_LONG if you wish.
As for size....I would recommend that you only put your tables and indexes and long/LOB data in the right sized page. If your indexes don't require a 32K tablespace, why put them there? It just wastes pages (a lot of space on the page will be ununsed) and thus waste disk. If you need to later move the indexes or the tables or the long/lob to a higher page size tablespace, it isn't too hard to do that later. (Of course you may need to have a maintenance window to do it in, but again, I think...even though disk is "cheap" so to say...why waste money?).
We used to put the tables in whatever size they needed and put the indexes only in a 4K unless they needed larger, figuring we could always change them later. But we recently have started to make sure the indexes are in the same tablespace size as the table data and LOB data. Reason being is you cannot change a tablespace after a table is created. To move the data you essentially have to create a new table and move all the data from one to the other.
Same goes for a few LOB's we have in other tables. I figured out their size and put them in an appropriately sized tablespace.
I have found the following pages on Space requirements for storage very helpful for understanding what sizes for tables and LOB's determine the required page size (and thus tablespace). The Space requirements for indexes link is helpful for indexes. Note: this is for DB2 9.7. If you need a different version, trying changing the number in the link, or start from IBM's main page.
DB2 shouldn't have issues at all with storage of large files. Some of how you store them will depend on what exactly you are storing. Are you storing XML files? Large text files? Word documents or PDFs? Video? Audio?
You have several options available to you. Graphic strings, binary strings, your large objects (CLOB, BLOB, and DBCLOB), and just plain XML.
If you are using just character data I would side with a CLOB. But check your sizes, if you are consistently lower than 32K it might just be better to use a VARCHAR. (Reason being is that large objects in DB2 are stored outside the table by default (unless you use the INLINE option, but even then it only works to certain sizes of LOBs), and they are also not cached in bufferpools. DB2 always retreives LOB's straight from disk (unless they are INLINE'd as mentioned above). If you are storing XML documents, you might want to look into the XML type as DB2 has a more optimal way to store and retrieve XML. You can set up special XML indexes on XML types too. And you can query the XML using SQL/XML or XQuery using XPath.
If you are storing binary objects, then I'd go with BLOB.
I think you may be right about the compression piece. (Although it wouldn't hurt to test it. There are about four or five different compression levels in DB2 and I know I can do at least backup compression with 9.7 Express-C).
Here is a 10.1 Edition comparison chart. And here is a article on the different editions and what they all offer.
Also take a look at space requirements for tables to help you better pick what you need.
Best Answer
Check out the general answer I gave to you on your other question.
If you are storing your XML as a LOB, then I guess I'd see what is the common average size per table. If the average size is 4MB or less (which it sounds like), then you'd only need a 4K tablespace (see Space requirements for table, table 1).
If you are storing the XML as an XML data type in DB2, then you actually get some performance gains over LOB, especially if you inline the XML (and aren't doing updates to it all that often). This may be the best since you mention sizes less than 32K. You may wish to check out XML storage page for in-lining XML within the table vs outside for XML storage.