DBIx::Class needs to know what your Table structure looks like.
You do that by defining Result classes.
Result classes are defined by calling methods proxied to DBIx::Class::ResultSource.
Each Result class defines one Table,
which defines the Columns it has,
along with any Relationships it has to other tables.
(And oh,
so much more besides) The important thing to understand:

So, we've got some ResultSources defined. Now, we want to actually use those definitions to help us translate the queries we need into handy perl objects!

Let's say we defined a ResultSource for an "album" table with three columns: "albumid", "artist", and "title". Any time we want to query this table, we'll be creating a DBIx::Class::ResultSet from its ResultSource. For example, the results of:

SELECT albumid, artist, title FROM album;

Would be retrieved by creating a ResultSet object from the album table's ResultSource, likely by using the "search" method.

DBIx::Class doesn't limit you to creating only simple ResultSets -- if you wanted to do something like:

SELECT title FROM album GROUP BY title;

You could easily achieve it.

The important thing to understand:

Any time you would reach for a SQL query in DBI, you are
creating a DBIx::Class::ResultSet.

DBIx::Class tends to wait until it absolutely must fetch information from the database. If you are returning a ResultSet, the query won't execute until you use a method that wants to access the data. (Such as "next", or "first")

The important thing to understand:

Setting up a ResultSet does not execute the query; retrieving
the data does.

By default this loads all the Result (Row) classes in the My::Schema::Result:: namespace, and also any resultset classes in the My::Schema::ResultSet:: namespace (if missing, the resultsets are defaulted to be DBIx::Class::ResultSet objects). You can change the result and resultset namespaces by using options to the "load_namespaces" in DBIx::Class::Schema call.

It is also possible to do the same things manually by calling load_classes for the Row classes and defining in those classes any required resultset classes.

Next, create each of the classes you want to load as specified above:

package My::Schema::Result::Album;
use base qw/DBIx::Class/;

Load any components required by each class with the load_components() method. This should consist of "Core" plus any additional components you want to use. For example, if you want serial/auto-incrementing primary keys:

DBIx::Class doesn't directly use most of this data yet, but various related modules such as DBIx::Class::WebForm make use of it. Also it allows you to create your database tables from your Schema, instead of the other way around. See SQL::Translator for details.

Accessors are created for each column automatically, so My::Schema::Result::Album will have albumid() (or album(), when using the accessor), artist() and title() methods.

Define a primary key for your class:

__PACKAGE__->set_primary_key('albumid');

If you have a multi-column primary key, just pass a list instead:

__PACKAGE__->set_primary_key( qw/ albumid artistid / );

Define this class' relationships with other classes using either belongs_to to describe a column which contains an ID of another Table, or has_many to make a predefined accessor for fetching objects that contain this Table's foreign key:

This is an external module, and not part of the DBIx::Class distribution. Like Class::DBI::Loader, it inspects your database, and automatically creates classes for all the tables in your database. Here's a simple setup:

There used to be an issue with the system perl on Red Hat Enterprise Linux 5, some versions of Fedora and derived systems. Further information on this can be found in DBIx::Class::Manual::Troubleshooting