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::Core/;

Load any additional components you may need with the load_components() method, and provide component configuration if required. For example, if you want automatic row ordering:

Ordered will refer to a field called 'position' unless otherwise directed. Here you are defining the ordering field to be named 'rank'. (NOTE: Insert errors may occur if you use the Ordered component, but have not defined a position column or have a 'position' field in your row.)

Set the table for your class:

__PACKAGE__->table('album');

Add columns to your class:

__PACKAGE__->add_columns(qw/ albumid artist title rank /);

Each column can also be set up with its own accessor, data_type and other pieces of information that it may be useful to have -- just pass add_columns a hash:

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 "deploy" in DBIx::Class::Schema 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 module (DBIx::Class::Schema::Loader) is an external module, and not part of the DBIx::Class distribution. It inspects your database, and automatically creates classes for all the tables in your schema.

The concept of a primary key in DBIx::Class warrants special discussion. The formal definition (which somewhat resembles that of a classic RDBMS) is a unique constraint that is least likely to change after initial row creation. However this is where the similarity ends. Any time you call a CRUD operation on a row (e.g. delete, update, discard_changes, etc.) DBIx::Class will use the values of of the primary key columns to populate the WHERE clause necessary to accomplish the operation. This is why it is important to declare a primary key on all your result sources even if the underlying RDBMS does not have one. In a pinch one can always declare each row identifiable by all its columns:

__PACKAGE__->set_primary_keys (__PACKAGE__->columns);

Note that DBIx::Class is smart enough to store a copy of the PK values before any row-object changes take place, so even if you change the values of PK columns the WHERE clause will remain correct.

If you elect not to declare a primary key, DBIx::Class will behave correctly by throwing exceptions on any row operation that relies on unique identifiable rows. If you inherited datasets with multiple identical rows in them, you can still operate with such sets provided you only utilize DBIx::Class::ResultSet CRUD methods: search, update, delete

For example, the following would not work (assuming People does not have a declared PK):

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