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

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开发者_StackOverflow)
        {...}

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

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.

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

what do you mean?

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

According to Normalization Rules you shouldn't store multiple values in the same column.

Comma separated values in fields (or any other similar trick) is poor practice and often resorted to either as a stopgap measure (i.e. you find out that you needed a multi-value when it's too late to change the data model) or some legacy cruft.

By having multivalues "encrypted" in a field you lose all the benefits of having a RDBMS model: in particular you make finding/sorting/comparing values in the comma-separated field(s) hard if not impossible to use along with the rest of your data.

In almost all cases one should store each comma-delimited value in its own column. This enables SQL selects to filter rows by specific comma-delimited values.

E.g., if 12 comma-delimited values were available for each table row representing sales per month (Jan-Dec) then storing the numbers in 12 columns enables manipulation; such as: return all rows where August sales > $100,000.00. Had one 'stuffed' all 12 values into a single column then all rows would need to be returned and the column parsed for each row to pull out the August figure.

One example where 'stuffing' may be considered... where the values in a comma-delimited data set cannot be be related or compared with data from another row.

E.g., in a multi-choice questionnaire the answer will be one or more options. Given a question with the correct answer being OPTION A & OPTION B and a second question with a correct answer of OPTION B & OPTION C then one could consider stuffing each answer into a single column. In this example would could store "B,C" and "B & C" if one accepts there is no required case to compare answers with each other.

The only situation I may consider using a custom class as the 'primary key' is using a OR/M against a legacy database that uses composite keys.

On the first not sure what you are looking for. I create business objects as classes that map to the my data layer, which is typically a datatable containing the data.

The second question is never. There are very few situations where I would store a comma separated list instead of creating a normalized data structure.