This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I don't know which of those two statements is the one you want. But yes, it does take a long time to build an index over a huge table. There's no getting around that. The good thing is, you're only going to build the index once. If you were going to do it on a daily basis, that might be a problem.
The difference is what the database does in the background. Both enforce a uniqueness constraint, but the "INDEX" guarantees a database-backed index is available. Often "UNIQUE KEY" does this too, so its not a huge difference. For indexes, you shoul[d specify whether you want a hash or tree depending on what you need. You can have indexes seperate from primary keys. Primary Keys (and other keys like foreign/unique) are more about referential integrity whereas Indexes are about performance.
You need to read your database documentation. Its hard to say what its doing behind the scenes. I would think in order to best enforce a uniqueness constraint you would want a hash index, but its really up the DBMS.
Joined: Oct 13, 2007
I see. Thanks Scott.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com