Hi Rick,

I think you are on the right track in following the examples from other tables. I would name your tables with a different prefix than we use in mojoPortal code to make it easier to keep them grouped separate from core tables.

By using a Guid for your primary key you are able to leverage other things in the system for your feature like content rating, content versioning, etc. You can store your ratings and history using your guid as the content guid.

SiteGuid allows building a method on your class to delete your content if the site is deleted using a SitePreDeleteEventHandler.

Redundant guids like ModuleGuid vs ModuleId, PageGuid vs PageId and SiteGuid vs SiteId make it possible in the future to import data from one installation into another, the rows may get a different integer id (in some tables) but the presence of the guid makes it possible to re-establish relationshhips if the integer ids change during import. Originally we started with integer ids  and still use them for joins for the main core features like modules, pages, sites because its slightly faster to join on integers. In newer development I'm generally not adding new integer id columns and just using the guids.

Hope it helps,

Joe

Hi Rick,

I think they will be making a mistake to drop it, they should keep it for backward compatibility or they will break existing apps and make customers angry. I really doubt they will actually drop it I think they just want everyone to start using varchar(max).

However varchar(max) is not supported in SQL 2000 so if we were to change to use varchar(max) we would immediately abandon support for SQL 2000.

I'm not going to change anything for now, if/when I see them actually drop it in a new version of MS SQL then I will make a decision about it.

For your own custom feature development you can use it if you don't care about SQL 2000 support, but really it needs to be NVarChar(max) to support multiple languages.

Best,

Joe