<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>

[{'answer_id': 19521, 'author': 'Ian Nelson', 'author_id': 2084, 'author_profile': 'https://Stackoverflow.com/users/2084', 'pm_score': 3, 'selected': True, 'text': "<p>Create one Message table, containing a unique MessageId and the various properties you need to store for a message.</p>\n\n<pre><code>Table: Message\nFields: Id, TimeReceived, MessageDetails, WhateverElse...\n</code></pre>\n\n<p>Create two link tables - QuoteMessage and JobMessage. These will just contain two fields each, foreign keys to the Quote/Job and the Message.</p>\n\n<pre><code>Table: QuoteMessage\nFields: QuoteId, MessageId\n\nTable: JobMessage\nFields: JobId, MessageId\n</code></pre>\n\n<p>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 <em>same</em> message (I'm not sure if that is appropriate to your business model, but at least the data model gives you the option).</p>\n"}, {'answer_id': 19545, 'author': 'Mark Brackett', 'author_id': 2199, 'author_profile': 'https://Stackoverflow.com/users/2199', 'pm_score': 1, 'selected': False, 'text': '<p>About the only other way I can think of is to have a base Message table, with both an Id and a TypeId. Your subtables (QuoteMessage and JobMessage) then reference the base table on both MessageId and TypeId - but also have CHECK CONSTRAINTS on them to enforce only the appropiate MessageTypeId.</p>\n\n<pre><code>Table: Message\nFields: Id, MessageTypeId, Text, ...\nPrimary Key: Id, MessageTypeId\nUnique: Id\n\nTable: MessageType\nFields: Id, Name\nValues: 1, "Quote" : 2, "Job"\n\nTable: QuoteMessage\nFields: Id, MessageId, MessageTypeId, QuoteId\nConstraints: MessageTypeId = 1\nReferences: (MessageId, MessageTypeId) = (Message.Id, Message.MessageTypeId)\n            QuoteId = Quote.QuoteId\n\nTable: JobMessage\nFields: Id, MessageId, MessageTypeId, JobId\nConstraints: MessageTypeId = 2\nReferences: (MessageId, MessageTypeId) = (Message.Id, Message.MessageTypeId)\n            JobId = Job.QuoteId\n</code></pre>\n\n<p>What does this buy you, as compared to just a JobMesssage and QuoteMessage table? It elevates a Message to a first class citizen, so that you can read all Messages from a single table. In exchange, your query path from a Message to it\'s relevant Quote or Job is 1 more join away. It kind of depends on your app flow whether that\'s a good tradeoff or not.</p>\n\n<p>As for 2 identical tables violating DRY - I wouldn\'t get hung up on that. In DB design, it\'s less about DRY, and more about normalization. If the 2 things you\'re modeling have the same attributes (columns), but are actually different things (tables) - then it\'s reasonable to have multiple tables with similar schemas. Much better than the reverse of munging different things together.</p>\n'}, {'answer_id': 19670, 'author': 'Guy', 'author_id': 993, 'author_profile': 'https://Stackoverflow.com/users/993', 'pm_score': 1, 'selected': False, 'text': "<p>@burns</p>\n\n<p>Ian's answer (+1) is correct <em>[see note]</em>.  Using a many to many table <code>QUOTEMESSAGE</code> to join <code>QUOTE</code> to <code>MESSAGE</code> is the most correct model, but will leave orphaned <code>MESSAGE</code> records.</p>\n\n<p>This is one of those <em>rare</em> cases where a trigger can be used.  However, caution needs to be applied to ensure that the a single <code>MESSAGE</code> record cannot be associated with both a <code>QUOTE</code> and a <code>JOB</code>.</p>\n\n<pre><code>create trigger quotemessage_trg\non quotemessage\nfor delete\nas\nbegin\n\ndelete \nfrom [message] \nwhere [message].[msg_id] in \n    (select [msg_id] from Deleted);\n\nend\n</code></pre>\n\n<p><em>Note to Ian, I think there is a typo in the table definition for <code>JobMessage</code>, where the columns should be <code>JobId, MessageId</code> (?).  I would edit your quote but it might take me a few years to gain that level of reputation!</em></p>\n"}, {'answer_id': 20935, 'author': 'Blorgbeard', 'author_id': 369, 'author_profile': 'https://Stackoverflow.com/users/369', 'pm_score': 0, 'selected': False, 'text': '<p>Why not just have both QuoteId and JobId fields in the message table? Or does a message have to be regarding either a quote or a job and not both?</p>\n'}]
['https://Stackoverflow.com/questions/19517', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/4367/']