Site-wide comments with different type of pages and special requirements

I am interested in designing the database (well, I'm only concerned about one table really) for a site with the following requirements:

1. There is an items page, which lists items. items.xyz?id=t displays the item with ID t. I need the IDs of the items to be consecutive. The first item has ID 1, the second ID 2 and so on. Each item page has comments on that item.
2. There are other pages, such as objects, where objects.xyz?id=t displays the object with ID t. The IDs here need not necessarily be consecutive (and they can overlap with item IDs, but it's ok if you suggest something that forces them not to overlap). These also have comments.

My question is how to design the Comments table? If I have an EntityID in it that represents the page the comment should be displayed on (be it an item page or an object page), then should I make it so that the ItemID never overlaps the ObjectID by making all ObjectID start from, say, 10⁹ and using a GUID table? (The ItemIDs increase very slowly). Is this acceptable practice?

Right now I'm doing it by having a bunch of nullable boolean fields in each comment: IsItem, IsObjectType1, IsObjectType2, ..., which allows me to know where each comment should be displayed. This isn't so bad since I onl开发者_如何学运维y have a few objects, but it seems like an ugly hack.

What is the best way to go about this?

I see three solutions (assuming it is impossible or undesired to put Pages and Objects in one table). Either:

1. Tell the comment which it belongs to by giving it two columns: PageId and ObjectId. That way you can also give these columns foreign keys to the respective tables and add proper indexes.

2. Introduce a table 'Entity' that has a unique id, a PageId and an ObjectId. Either columns are optional off course, exactly one of them must be filled, not 0 or both. This way, you move all the potential garbage of having separate entities to this table, not polluting the Comments table, which should contain just comments. You isolate the mess.

3. Create a link table between Comments and Items and another table between Comments and Objects. Items and Objects are completely unrelated, and you don't have to pollute the Comments table with a lot of NULL values in multiple columns. When you create a comment, you decide if it links to an Item or an Object by inserting a link in either ItemComments or ObjectComments. Reading comments for an item or object is a matter of two simple joins.

The comments table can then contain only a single EntityId that refers to the Id in the Entity table.

The big advantage to this approach is twofold:
a) You can link other things to the same table too, whichout much hassle.
b) You can add other kinds of Entities and they will automatically support Comments and other things you might add, as mentioned in a).