<p>I was reading the example chapter from <a href="http://www.manning.com/rahien/" rel="nofollow noreferrer">the book by Ayende</a> and on the website of <a href="http://boo.codehaus.org/" rel="nofollow noreferrer">the Boo language</a> I saw a reference to the <a href="http://specter.sourceforge.net/" rel="nofollow noreferrer">Specter BDD Framework</a>.</p>

<p>I am wondering if anybody is using it in their project, how that works out and if there are more examples and/or suggested readings.</p>

<p>Just in case you are wondering, I'm a C# developer and so I plan to use it in a C#/.NET environment.</p>

<hr>

<p>A few year later visiting this question. I think we can safely assume <a href="http://www.specflow.org/" rel="nofollow noreferrer">Specflow</a> and some others like <a href="http://nspec.org/" rel="nofollow noreferrer">NSpec</a> became the tools we are using.</p>

Create one Message table, containing a unique MessageId and the various properties you need to store for a message.
```
```
Table: Message
Fields: Id, TimeReceived, MessageDetails, WhateverElse...
```
```
Create two link tables - QuoteMessage and JobMessage. These will just contain two fields each, foreign keys to the Quote/Job and the Message.
```
```
Table: QuoteMessage
Fields: QuoteId, MessageId

Table: JobMessage
Fields: JobId, MessageId
```
```
In this way you have defined the data properties of a Message in one place only (making it easy to extend, and to query across all messages), but you also have the referential integrity linking Quotes and Jobs to any number of messages. Indeed, both a Quote and Job could be linked to the
same
message (I'm not sure if that is appropriate to your business model, but at least the data model gives you the option).