168 lines
5.2 KiB
Plaintext
168 lines
5.2 KiB
Plaintext
=head1 NAME
|
|
|
|
DBIx::Class::Manual::Glossary - Clarification of terms used.
|
|
|
|
=head1 INTRODUCTION
|
|
|
|
This document lists various terms used in DBIx::Class and attempts to
|
|
explain them.
|
|
|
|
=head1 DBIx::Class TERMS
|
|
|
|
=head2 DB schema
|
|
|
|
Refers to a single physical schema within an RDBMS. Synonymous with the terms
|
|
'database', for MySQL; and 'schema', for most other RDBMS(s).
|
|
|
|
In other words, it's the 'xyz' _thing_ you're connecting to when using any of
|
|
the following L<DSN|DBI/connect>(s):
|
|
|
|
dbi:DriverName:xyz@hostname:port
|
|
dbi:DriverName:database=xyz;host=hostname;port=port
|
|
|
|
=head2 Inflation
|
|
|
|
The act of turning database row data into objects in
|
|
language-space. DBIx::Class result classes can be set up to inflate
|
|
your data into perl objects which more usefully represent their
|
|
contents. For example: L<DBIx::Class::InflateColumn::DateTime> for
|
|
datetime or timestamp column data.
|
|
|
|
See also L<DBIx::Class::InflateColumn>.
|
|
|
|
=head2 Deflation
|
|
|
|
The opposite of L</Inflation>. Existing perl objects that represent
|
|
column values can be passed to DBIx::Class methods to store into the
|
|
database. For example a L<DateTime> object can be automatically
|
|
deflated into a datetime string for insertion.
|
|
|
|
See L<DBIx::Class::InflateColumn> and other modules in that namespace.
|
|
|
|
=head2 ORM
|
|
|
|
Object-relational mapping, or Object-relationship modelling. Either
|
|
way it's a method of mapping the contents of database tables (rows),
|
|
to objects in programming-language-space. DBIx::Class is an ORM.
|
|
|
|
=head2 Relationship
|
|
|
|
In DBIx::Class a relationship defines the connection between exactly
|
|
two tables. The relationship condition lists the columns in each table
|
|
that contain the same values. It is used to output an SQL JOIN
|
|
condition between the tables.
|
|
|
|
=head2 Relationship bridge
|
|
|
|
A relationship bridge, such as C<many_to_many> defines an accessor to
|
|
retrieve row contents across multiple relationships.
|
|
|
|
The difference between a bridge and a relationship is, that the bridge
|
|
cannot be used to C<join> tables in a C<search>, instead its component
|
|
relationships must be used.
|
|
|
|
=head2 Schema
|
|
|
|
A Schema object represents your entire table collection, plus the
|
|
connection to the database. You can create one or more schema objects,
|
|
connected to various databases, with various users, using the same set
|
|
of table L</Result Class> definitions.
|
|
|
|
At least one L<DBIx::Class::Schema> class is needed per database.
|
|
|
|
=head2 Result Class
|
|
|
|
A Result class defines both a source of data (usually one per table),
|
|
and the methods that will be available in the L</Result> objects
|
|
created using that source.
|
|
|
|
One Result class is needed per data source (table, view, query) used
|
|
in your application, they should inherit from L<DBIx::Class::Core>.
|
|
|
|
See also: L<DBIx::Class::Manual::ResultClass>
|
|
|
|
=head2 ResultSource
|
|
|
|
ResultSource objects represent the source of your data, these are
|
|
sometimes (incorrectly) called table objects.
|
|
|
|
ResultSources do not need to be directly created, a ResultSource
|
|
instance is created for each L</Result Class> in your L</Schema>, by
|
|
the proxied methods C<table> and C<add_columns>.
|
|
|
|
See also: L<DBIx::Class::ResultSource/METHODS>
|
|
|
|
=head2 ResultSet
|
|
|
|
This is an object representing a set of conditions to filter data. It
|
|
can either be an entire table, or the results of a query. The actual
|
|
data is not held in the ResultSet, it is only a description of how to
|
|
fetch the data.
|
|
|
|
See also: L<DBIx::Class::ResultSet/METHODS>
|
|
|
|
=head2 Result
|
|
|
|
Result objects contain your actual data. They are returned from
|
|
ResultSet objects. These are sometimes (incorrectly) called
|
|
row objects, including older versions of the DBIC documentation.
|
|
|
|
See also: L<DBIx::Class::Manual::ResultClass>
|
|
|
|
=head2 Row
|
|
|
|
See Result.
|
|
|
|
=head2 Object
|
|
|
|
See Result.
|
|
|
|
=head2 Record
|
|
|
|
See Result.
|
|
|
|
=head2 prefetch
|
|
|
|
Similar to a join, except the related result objects are fetched and
|
|
cached for future use, instead of used directly from the ResultSet. This
|
|
allows you to jump to different relationships within a Result without
|
|
worrying about generating a ton of extra SELECT statements.
|
|
|
|
=head1 SQL TERMS
|
|
|
|
=head2 CRUD
|
|
|
|
Create, Read, Update, Delete. A general concept of something that can
|
|
do all four operations (INSERT, SELECT, UPDATE, DELETE), usually at a
|
|
row-level.
|
|
|
|
=head2 Join
|
|
|
|
This is an SQL keyword, it is used to link multiple tables in one SQL
|
|
statement. This enables us to fetch data from more than one table at
|
|
once, or filter data based on content in another table, without having
|
|
to issue multiple SQL queries.
|
|
|
|
=head2 Normalisation
|
|
|
|
A normalised database is a sane database. Each table contains only
|
|
data belonging to one concept, related tables refer to the key field
|
|
or fields of each other. Some links to webpages about normalisation
|
|
can be found in L<the FAQ|DBIx::Class::Manual::FAQ>.
|
|
|
|
=head2 Related data
|
|
|
|
In SQL, related data actually refers to data that are normalised into
|
|
the same table. (Yes. DBIC does mis-use this term.)
|
|
|
|
=head1 FURTHER QUESTIONS?
|
|
|
|
Check the list of L<additional DBIC resources|DBIx::Class/GETTING HELP/SUPPORT>.
|
|
|
|
=head1 COPYRIGHT AND LICENSE
|
|
|
|
This module is free software L<copyright|DBIx::Class/COPYRIGHT AND LICENSE>
|
|
by the L<DBIx::Class (DBIC) authors|DBIx::Class/AUTHORS>. You can
|
|
redistribute it and/or modify it under the same terms as the
|
|
L<DBIx::Class library|DBIx::Class/COPYRIGHT AND LICENSE>.
|