Specificness of Tablespace I'm fairly new to working with databases and am trying to fully understand the purpose of a tablespace. 

Lets say I have a system where a user will input a schedule of tasks that need to be performed. This schedule is stored in my database and sent to a process which will distribute the tasks. As tasks are completed, the results are sent to a separate process which will store the raw result data, correlate the results, store a correlation summary, and then send it out. 

Would I keep all of this data in a single tablespace or would it make more sense to separate it into two tablespaces - one for the schedules and one that will store the raw results and correlated result summary?

In general, how related should tables/indexes be to be stored in the same tablespace?
Despite being answered 10 years ago, I don't think I could improve on Justin Cave's very applicable answer from this similar question on SO: Should an Oracle database have more than one tablespace for data storage?


  My bias (and this is largely a matter of personal preference) is that
  if there is no compelling benefit to creating additional tablespaces,
  life is easier with a single tablespace.
  
  
  There is no performance benefit to putting objects in different tablespaces.  There is an old myth that separating tables and indexes
  would have some performance benefits.  There is a potential benefit to
  spreading I/O over all available spindles, but that's better done with
  multiple data files in a single tablespace then with multiple
  tablespaces since Oracle does a round-robin allocation of extents in
  different data files assuming that your SAN isn't already doing
  something to even out I/O.
  If you have large, static lookup/ history tables such that you could bring a new copy of the database to the client site by just bringing
  the smaller transactional tablespaces, that would be a reason to
  consider multiple tablespaces.  But there are very few applications
  that have this sort of setup.  If you'll have to bring all 200 GB, it
  doesn't matter how many tablespaces you have.  
  Along the same lines, if you have large read-only objects, putting them in a read-only tablespace can vastly decrease the time and space
  required for backups.  Again, though, this isn't particularly common
  in practice outside of data warehouses.
  If your application could run without some subset of objects, there may be a benefit to creating separate tablespaces so that you could
  take one offline and do a tablespace-level restore.  Again though, few
  applications could run without a set of objects-- if you lose the
  index tablespace, for example, the application is likely just as dead
  as had you lost everything.
  If you have a large number of empty or mostly empty tables and a number of very large tables, separate tablespaces with different
  extent allocation policies may be preferrable from a space utilization
  standpoint.  This happens occasionally with packaged apps where any
  given installation is using a relatively small percentage of the
  available tables and you don't want each of the empty tables to have a
  relatively large extent assigned to it.  With automatic extent
  management in a locally managed tablespace, this tends not to be a
  major concern, it may be more concerning if you want to use uniform
  extents.
  If different objects have different priorities for disk performance, and you have different types of disk available, separate tablespaces
  can allow you to put different objects on different sets of disks.  In
  a data warehouse, for example, you may want to put older data on
  slower, cheaper disk and newer data on more costly disk.  This doesn't
  happen much with OLTP applications.
  
  
  Unless your application falls into one of these special cases, the
  only benefit to having separate tablespaces is to appeal to a DBA's
  sense of organization.  Personally, I'm more than happy to be able to
  avoid specifying a tablespace name every time I create an object or to
  spend cycles moving objects from the "wrong" tablespace when they
  inevitably get created in the default tablespace mistakenly. 
  Personally, I'm not overly concerned if a few tens of MB of space are
  "wasted" when using locally managed tablespaces with automatic extent
  management over a hand-optimized set of tablespaces with different
  uniform extent sizes.  On the other hand, good DBA's tend to be very
  concerned about things being organized "just so" so I'm not militantly
  opposed if a DBA wants to have separate index and data tablespaces
  just because that appeals to someone's sense of aesthetics.