Clustered vs covering index

Question

Consider the following table in SQL Server 2008:

LanguageCode  varchar(10)
Language      nvarchar(50)

LanguageCode participates in relationships, so I cannot create a primary key index that includes both columns (LanguageCode, Language).

If I put a primary clustered key on LanguageCode, of course I can't include Language in the index (covering index). This means that I will have to create a second index for Language, or run the risk of having duplicates in it (plus force a table scan to retrieve its value).

Further, MS's documentation (as well as experts on the subject) indicate that a table should ideally have a clustered index.

In this case, a non-clustered covering index (LanguageCode, Language) would not only ensure that Language is unique, but would avoid the table scan. However, there would be no "ideal" clustered index.

Is this one of those cases where having no clustered index is in fact ideal?

Edit based on feedback:

The only query I wish to run is:

SELECT Language, LanguageCode FROM Languages where Language="EN"

Answer 1

Clustered index, by definition, covers all columns.

If you create a PRIMARY KEY CLUSTERED on LanguageCode and a UNIQUE INDEX on Language, it will allow you to search a language both by its code and its name with a single lookup, and, in addition, make Language unique.

Answer 2

1. There is no need to include columns on a clustered index. Since the clustered index is "the data", all columns are automatically included.

2. If you have a need to search by Language and/or ensure its uniqueness, then definitely create an additional index on it.