Removing unnecessary section in the second step of the tutorial

docs/intro/tutorial02.txt

@@ -256,75 +256,7 @@ they're designed to be human-editable in case you want to manually tweak how
 Django changes things.
 
 There's a command that will run the migrations for you and manage your database
-schema automatically - that's called :djadmin:`migrate`, and we'll come to it in a
+schema automatically - that's called :djadmin:`migrate`.
-moment - but first, let's see what SQL that migration would run. The
-:djadmin:`sqlmigrate` command takes migration names and returns their SQL:
-
-.. console::
-
-    $ python manage.py sqlmigrate polls 0001
-
-You should see something similar to the following (we've reformatted it for
-readability):
-
-.. code-block:: sql
-
-    BEGIN;
-    --
-    -- Create model Question
-    --
-    CREATE TABLE "polls_question" (
-        "id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
-        "question_text" varchar(200) NOT NULL,
-        "pub_date" timestamp with time zone NOT NULL
-    );
-    --
-    -- Create model Choice
-    --
-    CREATE TABLE "polls_choice" (
-        "id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
-        "choice_text" varchar(200) NOT NULL,
-        "votes" integer NOT NULL,
-        "question_id" bigint NOT NULL
-    );
-    ALTER TABLE "polls_choice"
-      ADD CONSTRAINT "polls_choice_question_id_c5b4b260_fk_polls_question_id"
-        FOREIGN KEY ("question_id")
-        REFERENCES "polls_question" ("id")
-        DEFERRABLE INITIALLY DEFERRED;
-    CREATE INDEX "polls_choice_question_id_c5b4b260" ON "polls_choice" ("question_id");
-
-    COMMIT;
-
-Note the following:
-
-* The exact output will vary depending on the database you are using. The
-  example above is generated for PostgreSQL.
-
-* Table names are automatically generated by combining the name of the app
-  (``polls``) and the lowercase name of the model -- ``question`` and
-  ``choice``. (You can override this behavior.)
-
-* Primary keys (IDs) are added automatically. (You can override this, too.)
-
-* By convention, Django appends ``"_id"`` to the foreign key field name.
-  (Yes, you can override this, as well.)
-
-* The foreign key relationship is made explicit by a ``FOREIGN KEY``
-  constraint. Don't worry about the ``DEFERRABLE`` parts; it's telling
-  PostgreSQL to not enforce the foreign key until the end of the transaction.
-
-* It's tailored to the database you're using, so database-specific field types
-  such as ``auto_increment`` (MySQL), ``bigint PRIMARY KEY GENERATED BY DEFAULT
-  AS IDENTITY`` (PostgreSQL), or ``integer primary key autoincrement`` (SQLite)
-  are handled for you automatically. Same goes for the quoting of field names
-  -- e.g., using double quotes or single quotes.
-
-* The :djadmin:`sqlmigrate` command doesn't actually run the migration on your
-  database - instead, it prints it to the screen so that you can see what SQL
-  Django thinks is required. It's useful for checking what Django is going to
-  do or if you have database administrators who require SQL scripts for
-  changes.
 
 If you're interested, you can also run
 :djadmin:`python manage.py check <check>`; this checks for any problems in

docs/topics/db/models.txt

@@ -48,7 +48,9 @@ The above ``Person`` model would create a database table like this:
 Some technical notes:
 
 * The name of the table, ``myapp_person``, is automatically derived from
-  some model metadata but can be overridden. See :ref:`table-names` for more
+  some model metadata but can be overridden, normally are automatically
+  generated by combining the name of the app (``myapp``) and the lowercase
+  name of the model (``person``) . See :ref:`table-names` for more
   details.
 
 * An ``id`` field is added automatically, but this behavior can be
@@ -58,6 +60,15 @@ Some technical notes:
   syntax, but it's worth noting Django uses SQL tailored to the database
   backend specified in your :doc:`settings file </topics/settings>`.
 
+* The foreign key relationships are made explicit by a ``FOREIGN KEY``
+  constraint.
+
+* It's tailored to the database you're using, so database-specific field types
+  such as ``auto_increment`` (MySQL), ``bigint PRIMARY KEY GENERATED BY DEFAULT
+  AS IDENTITY`` (PostgreSQL), or ``integer primary key autoincrement`` (SQLite)
+  are handled for you automatically. Same goes for the quoting of field names
+  -- e.g., using double quotes or single quotes.
+
 Using models
 ============