Should I put multiple related items in one field in one record or store them separately?
So the question LowlyDBA is likely to provide you some insight on how to implement a many-to-many relationship.  But I think there's a little more to your specific situation that should be expanded upon.
First how to model this.  Whenever you see &quot; has zero/one or more &quot;, this indicates a one-to-zero-to-one relationship.  The  doesn't necessarily need to be another entity as in the other question.
So you would have one table with your terms:
CREATE TABLE Term
(
  Term  VARCHAR(50)  NOT NULL  /* 50 is probably reasonable, but whatever works best for you */
 ,CONSTRAINT PK_Term PRIMARY KEY (Term)
 ,CONSTRAINT CK_Term_Length_IsValid CHECK (LENGTH(Term) &gt;= 1) /* Or some other reasonable length */
 /* You can/should define additional constraints to keep invalid characters out of this column */
)
;

Next we need a table to store the definitions for each Term:
CREATE TABLE TermDefinition
(
  Term        VARCHAR(50)   NOT NULL
 ,Definition  VARCHAR(250)  NOT NULL /* Or some other reasonable maximum length */
 ,CONSTRAINT FK_TermDefinition_Definition_Of_Term FOREIGN KEY (Term) REFERENCES Term (Term)
 ,CONSTRAINT PK_TermDefinition PRIMARY KEY (Term, Definition)
 ,CONSTRAINT CK_TermDefinition_Definition_Length_IsValid CHECK (LENGTH(Definition) &gt;= 1)
)
;

So you might ask why not replace the primary key with an integer row pointer like TermId and save some space?

In order for TermId to be a valid key, it has to replace an existing key which becomes an alternate key UNIQUE (Term).  This creates another copy of your data via an index.  Depending on the average number of definitions per term you might not really save a significant amount of space to begin with.
Any search for a definition now has to hit the index for Term (again, a copy of Term) to select the TermId before querying TermDefinition, versus just querying TermDefinition directly.  So extra code,  more index tuning/maintenance.
We should avoid creating meaningless objects when possible.

You might also ask why you would need a Term table in the first place, if all lookups would be performed against TermDefinition?

We may need a unqiue/distinct list of Terms in the future for other reasons, such as relating Terms to each other.
You may want to make it hard for people to add new Terms but not new TermDefinitions.

*Some may take umbrage with a VARCHAR primary key column, but the data has to stored somehow, the data has to be read somehow, and if that's a list of variable length characters, it is what it is.  We either create a primary key with varying characters forming the B-Tree, or an alternate key with varying characters forming another B-Tree.