Commit | Line | Data |
24105556 |
1 | =head1 NAME |
2 | |
880a1a0c |
3 | DBIx::Class::Manual::Glossary - Clarification of terms used. |
24105556 |
4 | |
5 | =head1 INTRODUCTION |
6 | |
9e7b9292 |
7 | This document lists various terms used in DBIx::Class and attempts to |
8 | explain them. |
24105556 |
9 | |
92fcfd01 |
10 | =head1 DBIx::Class TERMS |
24105556 |
11 | |
784b08ba |
12 | =head2 DBIC |
13 | |
14 | Shorthand for L<DBIx::Class>. |
15 | |
db2b2eb6 |
16 | =head2 DB schema |
17 | |
18 | Refers to a single physical schema within an RDBMS. Synonymous with the terms |
19 | 'database', for MySQL; and 'schema', for most other RDBMS(s). |
20 | |
21 | In other words, it's the 'xyz' _thing_ you're connecting to when using any of |
22 | the following L<DSN|DBI/connect>(s): |
23 | |
24 | dbi:DriverName:xyz@hostname:port |
25 | dbi:DriverName:database=xyz;host=hostname;port=port |
26 | |
9e7b9292 |
27 | =head2 Inflation |
28 | |
29 | The act of turning database row data into objects in |
784b08ba |
30 | language-space. L<DBIC result classes|DBIx::Class::Manual::ResultClass> can |
31 | be set up to inflate your data into Perl objects which more usefully represent |
32 | their contents. For example: L<DBIx::Class::InflateColumn::DateTime> for |
92fcfd01 |
33 | datetime or timestamp column data. |
9e7b9292 |
34 | |
92fcfd01 |
35 | See also L<DBIx::Class::InflateColumn>. |
9e7b9292 |
36 | |
92fcfd01 |
37 | =head2 Deflation |
9e7b9292 |
38 | |
784b08ba |
39 | The opposite of L</Inflation>. Existing Perl objects that represent |
40 | column values can be passed to L<DBIC|DBIx::Class> methods to store into the |
41 | database. For example, a L<DateTime> object can be automatically |
92fcfd01 |
42 | deflated into a datetime string for insertion. |
9e7b9292 |
43 | |
92fcfd01 |
44 | See L<DBIx::Class::InflateColumn> and other modules in that namespace. |
9e7b9292 |
45 | |
24105556 |
46 | =head2 ORM |
47 | |
9e7b9292 |
48 | Object-relational mapping, or Object-relationship modelling. Either |
49 | way it's a method of mapping the contents of database tables (rows), |
784b08ba |
50 | to objects in programming-language-space. L<DBIC|DBIx::Class> is an ORM. |
9e7b9292 |
51 | |
7cf4ae7a |
52 | =head2 Relationship |
53 | |
784b08ba |
54 | In L<DBIC|DBIx::Class>, a relationship defines the connection between exactly |
7cf4ae7a |
55 | two tables. The relationship condition lists the columns in each table |
56 | that contain the same values. It is used to output an SQL JOIN |
57 | condition between the tables. |
58 | |
59 | =head2 Relationship bridge |
60 | |
61 | A relationship bridge, such as C<many_to_many> defines an accessor to |
8273e845 |
62 | retrieve row contents across multiple relationships. |
7cf4ae7a |
63 | |
92fcfd01 |
64 | The difference between a bridge and a relationship is, that the bridge |
65 | cannot be used to C<join> tables in a C<search>, instead its component |
66 | relationships must be used. |
24105556 |
67 | |
92fcfd01 |
68 | =head2 Schema |
24105556 |
69 | |
92fcfd01 |
70 | A Schema object represents your entire table collection, plus the |
71 | connection to the database. You can create one or more schema objects, |
72 | connected to various databases, with various users, using the same set |
73 | of table L</Result class> definitions. |
74 | |
75 | At least one L<DBIx::Class::Schema> class is needed per database. |
76 | |
77 | =head2 Result class |
78 | |
79 | A Result class defines both a source of data (usually one per table), |
fb13a49f |
80 | and the methods that will be available in the L</Result> objects |
81 | created using that source. |
92fcfd01 |
82 | |
83 | One Result class is needed per data source (table, view, query) used |
84 | in your application, they should inherit from L<DBIx::Class::Core>. |
24105556 |
85 | |
fb13a49f |
86 | See also: L<DBIx::Class::Manual::ResultClass> |
87 | |
24105556 |
88 | =head2 ResultSource |
89 | |
92fcfd01 |
90 | ResultSource objects represent the source of your data, these are |
91 | sometimes (incorrectly) called table objects. |
92 | |
93 | ResultSources do not need to be directly created, a ResultSource |
94 | instance is created for each L</Result class> in your L</Schema>, by |
95 | the proxied methods C<table> and C<add_columns>. |
24105556 |
96 | |
97 | See also: L<DBIx::Class::ResultSource/METHODS> |
98 | |
92fcfd01 |
99 | =head2 ResultSet |
100 | |
101 | This is an object representing a set of conditions to filter data. It |
102 | can either be an entire table, or the results of a query. The actual |
103 | data is not held in the ResultSet, it is only a description of how to |
104 | fetch the data. |
105 | |
106 | See also: L<DBIx::Class::ResultSet/METHODS> |
107 | |
24105556 |
108 | =head2 Record |
109 | |
fb13a49f |
110 | See Result. |
24105556 |
111 | |
112 | =head2 Row |
113 | |
fb13a49f |
114 | See Result. |
115 | |
116 | =head2 Result |
117 | |
118 | Result objects contain your actual data. They are returned from |
119 | ResultSet objects. These are sometimes (incorrectly) called |
784b08ba |
120 | row objects, including older versions of the L<DBIC|DBIx::Class> |
121 | documentation. |
fb13a49f |
122 | |
123 | See also: L<DBIx::Class::Manual::ResultClass> |
24105556 |
124 | |
125 | =head2 Object |
126 | |
fb13a49f |
127 | See Result. |
24105556 |
128 | |
92fcfd01 |
129 | =head2 join |
24105556 |
130 | |
fb13a49f |
131 | See Join. |
132 | |
92fcfd01 |
133 | =head2 prefetch |
134 | |
fb13a49f |
135 | Similiar to a join, except the related result objects are fetched and |
136 | cached for future use, instead of used directly from the ResultSet. This |
137 | allows you to jump to different relationships within a Result without |
138 | worrying about generating a ton of extra SELECT statements. |
92fcfd01 |
139 | |
140 | =head1 SQL TERMS |
141 | |
fb13a49f |
142 | =head2 CRUD |
143 | |
144 | Create, Read, Update, Delete. A general concept of something that can |
145 | do all four operations (INSERT, SELECT, UPDATE, DELETE), usually at a |
146 | row-level. |
147 | |
92fcfd01 |
148 | =head2 Join |
149 | |
150 | This is an SQL keyword, it is used to link multiple tables in one SQL |
151 | statement. This enables us to fetch data from more than one table at |
152 | once, or filter data based on content in another table, without having |
153 | to issue multiple SQL queries. |
154 | |
155 | =head2 Normalisation |
156 | |
157 | A normalised database is a sane database. Each table contains only |
158 | data belonging to one concept, related tables refer to the key field |
159 | or fields of each other. Some links to webpages about normalisation |
160 | can be found in L<DBIx::Class::Manual::FAQ|the FAQ>. |
161 | |
162 | =head2 Related data |
163 | |
164 | In SQL, related data actually refers to data that are normalised into |
fb13a49f |
165 | the same table. (Yes. DBIC does mis-use this term.) |
166 | |
167 | =head1 AUTHOR AND CONTRIBUTORS |
168 | |
169 | See L<AUTHOR|DBIx::Class/AUTHOR> and L<CONTRIBUTORS|DBIx::Class/CONTRIBUTORS> in DBIx::Class |
170 | |
171 | =head1 LICENSE |
172 | |
173 | You may distribute this code under the same terms as Perl itself. |