Re^3: DBIx::Class with two kinds of otherwise identical table types

Just a couple minor clarifications on partitioned tables:

First, as far as the application is concerned, there's a single table. While it *could* access the subordinate tables individually, it normally wouldn't. When you submit your query, the database server has the task of converting your query against the main table into queries against the subordinate tables: so your application doesn't get more complicated--only the database management does.

Secondly, MS SQL Server doesn't keep a table of pointers to the other tables: Instead there's a function that returns the table. I doubt that other database servers use a table of pointers, either, as that would be another table and index to maintain.

Another advantage of partitioned tables is that a single query on your table can break into a query per subordinate table, and those can be queried in parallel. So many queries are faster that would occur in a non-partitioned table.

...roboticus

Comment on Re^3: DBIx::Class with two kinds of otherwise identical table types

Replies are listed 'Best First'.
Re^4: DBIx::Class with two kinds of otherwise identical table types by dwm042 (Priest) on Sep 15, 2010 at 16:51 UTC
roboticus, Clarification much appreciated! I know I'm otherwise thinking in terms of analogies to files in file systems, with blocks containing pointers to blocks. David.	[reply]