Question: I have an important Object which have loads of properties. Now few of the properties could have multiple values for example consider, A Channel Object having one or mulitple producers (Now our client think that there could be only few producers like mostly 1 or 2 ). The same issue exist with almost 7 properties. 

Now i have two solutions;

> 
> 1. Embed them as link objects in design and create seperate tables in
>  the db hence implementing them as
>  entity (considering each producer a
>  unique). But this solution means this
>  one table will be dependant upon 8
>  further tables to have this ability.
> 2. Embed them as link/reference objects in domain but dont create the
>  seperate tables for them instead store
>  them as CSV format and let the DAL to
>  do the access/retrieval logic. Hence
>  saving the space and relations on DB
>  side as well as DAL side. But also
>  having OOP power.
> 
> 
> 

Although 2nd solution seems to be appear cheaky and working but it has design limitions and loose flexibility but again client is insisting that they just want free text properties for this nothing else. 

to further explain the issue the structure could be like that

```
Channel
  Name, (free text)
  Vanue, (free Text)
 .......
  Producer1, Producer2...... (each producer is just a name)
  OpeningDay1,OpeningDay2,..... (each entry is just time slot)

```

etc

Answer: 
I think you can combine both approaches to give a good overall result. Create seperate tables for Producer etc, and then use domain objects to read the values from those tables once only and cache the results. In that way you can 

1) maintain ref integrity in the DB, take advantage of DB backups etc, 
2) remove the performance hit of a join across 8 tables to return a single entity
3) reduce your reliance on seperate persistance methods, CSV files etc. 

This approach is common with reference data tables, these values are typically small, 'slow changing' tables, that can be safely cached.
How about create a single relationship to an entity that also knows its type. i.e. Producer or Entry etc.