[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3305) hbm2ddl: MS SQL Server 2005 defaults to Clustered Index on PK, lets use PRIMARY KEY NONCLUSTERED for hbm2ddl as a more reasonable default
j nadler (JIRA)
noreply at atlassian.com
Sun Oct 10 15:05:57 EDT 2010
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=38669#action_38669 ]
j nadler commented on HHH-3305:
-------------------------------
I agree entirely - we're seeing this same problem. Many users are probably not sophisticated enough with SQL Server to realize what a problem this can create.
I looked through the source. Here's what needs to happen IMO:
PrimaryKey.java: The string "primary key" at line 38 should not be hardcoded here; instead it should make a call to Dialect.
Dialect.java: Add a new method "getCreateTablePrimaryKeyConstraintString" and in the implementation just return "primary key".
SQLServerDialect.java: Override "getCreateTablePrimaryKeyConstraintString" to return "primary key nonclustered"
Sound reasonable?
> hbm2ddl: MS SQL Server 2005 defaults to Clustered Index on PK, lets use PRIMARY KEY NONCLUSTERED for hbm2ddl as a more reasonable default
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HHH-3305
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3305
> Project: Hibernate Core
> Issue Type: Bug
> Components: metamodel
> Affects Versions: 3.2.1
> Reporter: Jim Doyle
>
> In SQL Server 2005, PRIMARY KEY defaults to creating a Clustered Index for the PK column at table creation time.
> To confirm this behaviour Please see: http://msdn.microsoft.com/en-us/library/ms188066.aspx
> This default behaviour is un-desireable for a number of reasons:
> 1. No other databases default to a clustered IDX at the PK ; Not DB2, nor Oracle nor MySQL
> 2. There may only be ONE clustered IDX per table. By using this as a default makes it difficult
> for the app developer or DBA to quickly add or change the once-per-table opportunity to use
> the cluster to improve query performance.
> 3. The default cluster index that Microsoft applies seems only to benefit naive SQL server users with
> little to no DBA skills. Table insert of new rows onto a Clustered Index PK is always very fast and
> while this optimization may be impressive if your problem space is rapidly inserting new data into large tables,
> this optimization is often an antipattern to users with more plausible query patterns such as scan by non-primary
> key date, numeric amounts or alphabetical data.
> 4. Defaulting the PK to clustered creates SUBSTANTIAL burden for a DBA when the Clustered Index needs to be removed
> from the PK to be deployed on other columns on the table. As an example of the burden that this creates, for EACH TABLE
> one must:
> - Discover all tables and columns that link back to the table in question through FOREIGN KEY
> - Drop all foreign keys
> - Drop the PK
> - Add the PK back, with NONCLUSTERED
> - Put back all the dropped Foreign keys
> 5. Additional arguments against supporting Microsoft's unusual default is given here:
> http://tonesdotnetblog.wordpress.com/2008/05/26/twelve-tips-for-optimising-sql-server-2005-queries
> (Please See Section 2: Use Clustered Index).
> I propose ANY ONE of the following enhancements to the DDL generator for the SQL Server 2005 Dialect:
> 1. Change the generated SQL from colname coltype PRIMARY KEY TO colname coltype PRIMARY KEY NONCLUSTERED such that
> PK index generate conforms the the usual, sensible defaults of other database products.
> 2. Use a Properties attribute (i.e. hibernate.hbm2ddl.dialect.mssql.use_non_clustered_pk) that is evaluated at hbm2ddl runtime
> that will emit 'NONCLUSTERED' to the PK clause. If this Property is not defined, the hbm2ddl will simply emit PRIMARY KEY as it does
> now and MS SQL Server will use its peculiar and annoying default.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the hibernate-issues
mailing list