I don't plan to use a clustered index on my table, will I regret it?

I don't plan to use a clustered index on my table, will I regret it?

pFor simplicity, let's say I have a table 'Car' in Sql Server. It has 2
columns. 'Id' is a uniqueidentifier/Guid and is the primary key. 'Name' is
a nvarchar/string. The database will be for a lightly used app that peaks
at maybe 10 concurrent users. 'Car' could have thousands of rows. It will
be queried, inserted, and updated regularly./p pI know it's bad in general
to have a clustered index on a Guid column, so my plan is to leave the
table as a heap and have no clustered indexes. I'd have a non-clustered
index on Id./p pIn this very simple scenario, is there any reason I would
regret not having a clustered index? If you say yes, please explain the
reasoning behind your answer. I've seen posts where people say things like
I'd add an int column just to add a clustered index. I can't figure out
why anyone would do that if you don't plan on querying against the int
column anyways, what value does it add?/p pAlso for this example, please
assume newsequentialid() isn't an option. I'm using Entity Framework model
first and it's a pain to use (unless someone can point to an easy way to
do this I missed). Also assume a Guid PK is a requirement (it's an
existing system)./p