diff options
Diffstat (limited to 'railties/doc/guides/migrations/scheming.txt')
| -rw-r--r-- | railties/doc/guides/migrations/scheming.txt | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/railties/doc/guides/migrations/scheming.txt b/railties/doc/guides/migrations/scheming.txt index 1ec423c923..8dd58f12d6 100644 --- a/railties/doc/guides/migrations/scheming.txt +++ b/railties/doc/guides/migrations/scheming.txt @@ -1,7 +1,7 @@ == Schema dumping and you == [[schema]] === What are schema files for? === -Migrations, mighty as they may be, are not the authoritative source for your database schema. That role falls to either `schema.rb` or an sql file which Active Record generates by examining the database. They are not designed to be edited, they just represent the current state of the database. +Migrations, mighty as they may be, are not the authoritative source for your database schema. That role falls to either `schema.rb` or an SQL file which Active Record generates by examining the database. They are not designed to be edited, they just represent the current state of the database. There is no need (and it is error prone) to deploy a new instance of an app by replaying the entire migration history. It is much simpler and faster to just load into the database a description of the current schema. @@ -33,9 +33,9 @@ end In many ways this is exactly what it is. This file is created by inspecting the database and expressing its structure using `create_table`, `add_index` and so on. Because this is database independent it could be loaded into any database that Active Record supports. This could be very useful if you were to distribute an application that is able to run against multiple databases. -There is however a trade-off: `schema.rb` cannot express database specific items such as foreign key constraints, triggers or stored procedures. While in a migration you can execute custom sql statements, the schema dumper cannot reconstitute those statements from the database. If you are using features like this then you should set the schema format to `:sql`. +There is however a trade-off: `schema.rb` cannot express database specific items such as foreign key constraints, triggers or stored procedures. While in a migration you can execute custom SQL statements, the schema dumper cannot reconstitute those statements from the database. If you are using features like this then you should set the schema format to `:sql`. -Instead of using Active Record 's schema dumper the database's structure will dumped using a tool specific to that database (via the `db:structure:dump` rake task) into `db/#\{RAILS_ENV\}_structure.sql`. For example for postgresql the `pg_dump` utility is used and for mysql this file will contain the output of SHOW CREATE TABLE for the various tables. Loading this schema is simply a question of executing the sql statements contained inside. +Instead of using Active Record 's schema dumper the database's structure will be dumped using a tool specific to that database (via the `db:structure:dump` rake task) into `db/#\{RAILS_ENV\}_structure.sql`. For example for PostgreSQL the `pg_dump` utility is used and for MySQL this file will contain the output of SHOW CREATE TABLE for the various tables. Loading this schema is simply a question of executing the SQL statements contained inside. By definition this will be a perfect copy of the database's structure but this will usually prevent loading the schema into a database other than the one used to create it. |