Because unique indexes can be (implicitly) added as constraints. Non unique indexes are not constraints so cannot be added as part of the create table statement. T-SQL I'm talking about here - I would imagine (but don't know since I am one of Bill's b*tches) that most RDBMSs are the same.
I prefer specifying the constraints in-line (inside the create table statement), as it keeps the definition all together as one unit. But I was wondering what motivation people had for the out-of-line style. One thing I don't like about the in-line option is I feel it clutters the create table statement so it's harder to see at a glance what columns the table has.
Nope - that isn't necessary. This is my create table template. I keep ALL constraints at the bottom, in strict order (PK, Alt Key, check, foreign key), except defaults - but only because I can't move these. It is also more consistent - if your key is composite you can't declare it as part of the column definition anyway.
IF NOT EXISTS (SELECT NULL FROM sys.schemas WHERE name = 's_name') BEGIN
EXEC ('CREATE SCHEMA s_name')
IF EXISTS (SELECT NULL FROM sys.tables WHERE object_id = OBJECT_ID('s_name.t_name')) BEGIN
DROP TABLE s_name.t_name
CREATE TABLE s_name.t_name
c_name INT IDENTITY NOT NULL
, c_2_name VARCHAR(10) NULL CONSTRAINT df_c_2_name DEFAULT ('def val')
, CONSTRAINT pk_t_name_u_c PRIMARY KEY CLUSTERED (c_name) WITH (FILLFACTOR = 100)
, CONSTRAINT ix_t_name_c_2_name_u_nc UNIQUE NONCLUSTERED (c_2_name) WITH (FILLFACTOR = 100)
, CONSTRAINT ck_t_name_c_2_name CHECK (c_2_name IN('def val'))
, CONSTRAINT fk_t_name_t_2_name FOREIGN KEY (c_2_name) REFERENCES s_name.t_2_name (c_2_name) --ON DELETE CASCADE