When should I consider representing the primary-key ...?

Question

When should I consider representing the primary-key as classes?

Should we only represent primary keys as classes when a table uses composite-key?

For example:

public class PrimaryKey
    { ... ... ...}

Then

private PrimaryKey _parentID;
        public PrimaryKey ParentID
        {
            get { return _parentID; }
            set { _parentID = value; }
        }

And

public void Delete(PrimaryKey id)
        {...}

When should I consider storing data as comma-separated values in a column in a DB table rather than storing them in different columns?

Answer 1

When should I consider representing the table-id columns as classes?

Much more difficult to answer without knowing your application architecture. If you use an ORM such as nhibernate or linq to sql, they will create classes for you automatically.

In general - if your primary key is a composite and has meaning in your domain, create a class for it.

If it is not a composite, there is no need for a class.

If it has no meaning in your domain it is difficult to justify a class (if creating one, I would probably go with a struct instead of a class, as it would be a value type). The only reason I would use one is if the key needs to be used as is in your code and the constituent parts do not normally need to be accessed separately.

When should I consider storing data as comma-separated values in a column in a DB table rather than storing them in different columns?.

Never. You should keep your tables normalized, so different columns and tables for the different data. Using comma separated is bad practice in this regards, especially considering the fairly bad text manipulation support in SQL.