Alternative of Association?

[snig]

The Scenario.
<ol>
<li>An object (we are defining this object as a custom TYPE) has multiple addresses.</li>
<li>An address has the following details
<ol>
<li>Line 1</li>
<li>Line 2</li>
<li>Street</li>
<li>State</li>
<li>Country</li>
</ol></li>
</ol>

Given that we can have only a single property as MULTIPLE and cannot add an aspect more than once, how to define this address in the content model, so that
<ol>
<li>We are not creating another TYPE for address</li>
<li>And use Associations to add multiple addresses</li>
</ol>

One of the basic reason is, we have a lot of such objects to be maintained in the repository; and each of these objects will be having many addresses. We do not want to create that many nodes in the repository.

Any model, please?

[mrogers]

Nodes are cheap.  A node with assocs to the address is really the reccomended way to go. 

One bodge is to store csv or json data in a text field or a multi valued text string.
Another bodge is to have aspects for address1, address2, address3.

[snig]

Thanks so much Rogers for quick reply.
I understand assocs are really the recommended way to go. Even though nodes are cheap, still should we so many nodes?

If we store the full CSV or JSON, things won't be searchable (almost similar problem in case of assocs as well).

In case of address1, address2 etc, do you mean to create many aspects? Our address list however should be dynamic.

Thanks again Rogers.