Question

Is delimiting data in a database field something that would be ok to do?

Something like

create table column_names (
  id int identity (1,1) PRIMARY KEY,
  column_name varchar(5000)
);

and then storing data in it as follows

INSERT INTO column_names (column_name) VALUES ('stocknum|name|price');

Answer 1

No. this is bad:

• in order to create new queries you have to track down how things are stored.

• queries that join on price or name or stocknum are going to be nasty

• the database can’t assign data types to the data or validate it

• you can’t create constraints on any of this data now

Basically you’re subverting the RDBMS’ scheme for handling things and making up your own, so you’re limiting how much the RDBMS tools can help you and you’ve made the system harder to understand for new people.

The only possible advantage of this kind of system that I can think of is that it can serve as a workaround to avoid dealing with a totally impossible DBA who vetoes all schema changes regardless of merit. Which can happen, unfortunately.

Of course there’s an exception to everything. I’m currently on a project with audit-logging requirements that are pretty stringent. the logging is done to a database, we’re using delimited fields for storing the fields because the application is never going to interact with this data, it gets written once and left alone.