clustered-index

We have a database in which all the PKs are GUIDs, and most of the PKs are also the clustered index for the table. We know that this is bad (due to the random nature of GUIDs). So, it seems there are basically two options here (short of throwing out GUIDs as PKs altogether, which we cannot do (at least not at this time)). We could change the GUID generation algorithm to e.g. the one that NHibernate uses, as detailed in this post , or we could, for the tables that are under the heaviest use, change to a different clustered index, e.g. an IDENTITY column, and keep the "random" GUIDs as PKs. Is

I am working on database standards for a new database my company is starting. One of the things we are trying to define is Primary Key and Clustered Index rules in relation to UniqueIdentifiers. (NOTE: I do not want a discussion on the pros and cons of using a UniqueIdentifier as a primary key or clustered index. There is a ton of info on the web about that. This is not that discussion.) So here is the scenario that has me worried: Say I have a table with a UniqueIdentifier as the clustered index and primary key. Lets call it ColA. I set the default value for ColA to be NewSequentialId().

I'm trying to import data from DWH SQL server table which is using Clustered Columnstore Index into kudu through flume . However, after my custom flume source retrieves a certain number of rows from the database, this exception occurs: SqlExceptionHelper: Cursors are not supported on a table which has a clustered columnstore index I'm using JDBC SQL Server driver type 4, and apparently it uses cursors to iterate resultset. Therefore, I tried setting fetch size to the number the query is limited to, but nothing changed. How can I stop the JDBC driver from using cursors and thus get all rows

Consider the following composite clustered index: CREATE UNIQUE CLUSTERED INDEX ix_mytable ON mytable(a, b) Obviously, a separate index on b will make searching for a particular value of b faster. However, if a separate index on b is not employed, it seems to me that the composite index can still be used to find tuples with a particular value for b instead of a table scan, by traversing the tree of discrete values of a and do a local search for b , jump to the next value of a , etc. Is this how SQL Server works? (It would not be, for instance, if MSSQL uses a single hash value for indexes with

Folks, I would like to understand the answer for the following questions: Can I have a primary key without clustered index ? ( I am aware that when we create primary key constraint on a column, it by default creates a clustered index. So in that case, how should I deactivate clustered index ?) Can I have a clustered index with multiple columns together ? (Like in non-clustered where I can join different columns for a single non-clustered index). (This answer is for SQL Server 2005+ only. I know nothing about MySQL.) Can I have a primary key without clustered index? Yes. As you mentioned, a