Can someone tell me exactly what are table spaces?

Straight from the DB2 documentation, from the glossary:

table space
A logical unit of storage in a database. In DB2 for z/OS, a table space is a page set and can contain one or more tables. In DB2 Database for Linux, UNIX, and Windows, a table space is a collection of containers, and the data, index, long field, and LOB portions of a table can be stored in the same table space or in separate table spaces. See also page set, container.

Andy

What's the benefit of having table spaces?

so that you can start growing tables

It seems to me that you could grow tables without having table spaces. Here's a definition of table space from the IBM documentation:

table space
(1) An abstraction of a collection of containers into which database objects are stored. A table space provides a level of indirection between a database and the tables stored within the database. A table space has space on media storage devices assigned to it. The data, index, long field, and LOB portions of a table can be stored in the same table space, or can be individually broken out into separate table spaces.
(2) In DB2 Universal Database for z/OS and OS/390, a page set that is used to store the records in one or more tables.

How does having this abstraction help with growing tables?

show me how you grow tables without having tablespaces.


Here is another definition of a tablespace:
A table space is a database object that is used by DB2 to specify the physical
location of data in a database; it is the layer between the table metadata and the actual container that holds table data. Tables and indexes reside within tablespaces. A table space can contain one or many tables/indexes.

This thread reinforces my theory that people with a handle that contains the letters "db2" know almost nothing about DB2. db2girl is an exception, but a large percentage of the totally idiotic posts come from people with "db2' in their handle name.

You don't have a choice. All tables must be created in a tablespace. If you don't specify the tablespace when the table is created, then DB2 will pick one for you that was created by default when the database was created (or in the case of DB2 z/OS, when the DB2 sub-system was created).

If you are using DB2 for i/Series, then God help you.

The only sensible answer here is: RTFM

And maybe participate in a course that teaches the basics on relational database systems...

The only sensible answer here is: RTFM

And maybe participate in a course that teaches the basics on relational database systems...

@stolze & Marcus A: What's the point of posting self-important flame bait?

@db2girl: In some references table spaces are referred to as physical entities and in some references they are referred to as logical entities. In some refereces they are referred to as both. If a table space really is a logical entity -- an abstraction of other elements such as files -- then those elements exist regardless of the logical association provided by the abstraction. This is why it seemed to me that one should be able to grow tables without a table space -- provided that a table space really is just a logical entity. Since databases, and schemas within databases, already provide logical groupings of tables (and other objects) I wondered what extra value was being added by yet another logical grouping.

1. What is the point of asking stupid questions?

2. The value of an abstraction such as a tablespace is that it can consist of one or more containers (or VSAM files in z/OS), whose specifications are cumbersome to define. Once defined, the tablespace name (instead of the detailed specifications) can be referenced in the create table statement as the place where a table will physically reside. This is useful since a tablespace can hold more than one table.

3. What is meant by "grow"? You keep asking about growing a table. You need a tablespace to create a table, not just to grow it. I don't know if there is translation problem here, or where you got the terms "grow a table" from, but it makes no sense in the context of your question, so maybe you should elaborate. .

4. Just about all relational databases that I know have the concept of a tablespace that specifies the physical location of where the table resides, so it is not unique to DB2.

5. I would suggest you install DB2, and then add a tablespace, then add tables using that tablespace, and you will understand. Or you could read the DB2 manuals.

"grow" came from me...

db2 farmer "grows" db2 tables

Good, as if this person is not totally confused already...

On z/OS Table Spaces are simple and straight forward. They are the physical object that is created on disks (actually VSAM files as Marcus A states). A combination of Database.Tablespace gives a unique name. The table is the logical object contained in this physical space.

On LUW it is a little more complicated. Containers are the actual physical objects you will see on Disk. You can define a table space to use one or more containers. The Table spaces / Containers contain the logical Tables, indexes, etc. So the abstraction form the table point of view is not having to defined the containers to uses since the Table space takes care of this.

Now, a theoretical discussion could be made that you could do away with the Table spaces and just have Tables, Indexes, etc and Containers. But, I am guessing that, since z/OS was around a long time before LUW, that the Table Space / Table paradigm was already set and would just introduce some confusion (and complicate the already complicated Universal Database goal).

But the fact remains that DB2 uses the Table Space / Table structure and, I believe, Containers were added to deal with the different disk storage structures on LUW computers (as compared to z/OS).