This is the second part of the series which discusses the issues around modeling M:1 (many-to-one) relationships. If you've not read the first part, then its advisable that you read that first before continuing with this part. To keep up to date with this and other blog's you might consider registering with the RSS feed.

Part I: The Problem

Part III: BusinessKey as a value type

Suggested Solution

Having covered the issues with M:1 relationships and the three different types I'll now present a potential solution which provides the necessary foreign key information, but in a more domain model fashion. I'll also point out yet another issue with the original logical model when it comes to actually using it, which I'll also offer up a solution for. More...

Designing a domain model can be a tough job and if you're lucky enough to start from scratch then it becomes even tougher once you apply it to the physical database model. Over the next few posts I' like to discuss the issues we encounter when modeling this relationship type, examine the way its 'normally' done and then present an alternative that I believe presents a more domain model centric view of the world. The series will be broken up into the following sections, with this being the first. To keep up to date with this and other blog's you might consider registering with the RSS feed.

Part I: The Problem

Part II: Suggested Solution

Part III: BusinessKey as a value type

The main issue when designing a domain model is that they don't have these oddities called foreign keys, as the relationships are known by association. However, once you turn your domain model into a database schema we have to start adding all these extra keys, which get worse when you have a M:M (many-to-many) relationship! In this post I'd like to discuss how we normally model the M:1 (many-to-one) relationship and its pitfalls. More...

For anyone that's read my blog entries you've seen me make mention to a framework that I've been working on. Well today marks the release of the first beta of part of that framework. The Database Explorer API, is a database schema API that is designed to make accessing database schema information easy and intuitive. More...

While I don't normally get involved with deploying web applications (we normally have 'people' for that) however I did have to deploy the application you're using now. Which brings me to the blog post I recently found which discusses the top 10 best practices for ASP.NET which I've linked to on my toolbox page. The main one that concerned was of concern to me was forgetting to switch off debug mode.

   1: <system.web>

   2:   <compilation debug="false" />

   3: </system.web>

This setting appears to have a large impact on production web sites so I'd check out the detail in the this post to get all the details. Also you might want to check the config files of the production apps you work on or blog if you host your own; lets just say we may need to update a few of ours!

In many application be they web or otherwise it can be important to secure parts of the configuration files incase the file is compromised by a hacker or you simply don't want anyone to know what the true values are. It turns out that this is fairly easy to do using the ASP.NET IIS Registration Tool (Aspnet_regiis.exe) (obvious right?). To illustrate the point I'll show you a typical config file and what's required to encrypt parts of it. More...

When I work with collections I’ll often want to retrieve information from the collection by its key. So my options are usually to make use the following generic collection (who uses any other type of collection now? Unless you’re stuck on .NET 1.1):

   1: System.Collections.Generic.Dictionary<TKey,TValue>

This is great collection except if you want to ever serialize it! Then you’ll have some problems. So the issue becomes do I want a collection which is searchable via an index and is serializable or one that is keyed but can’t be serialized. The problem however, is that in a lot of cases you actually want to be able to use both methods, that is search by ordinal number or index and be able to search by a key, which maybe a business key. To solve this issue many have resorted to inheriting from IList<T> then adding another item overload which iterates through the collection until you find a match. This works, but is probably not too efficient on large collections. Also it’s a pain to have to write this code each time.

With the introduction of .NET 2.0 Microsoft released a collection object which doesn’t get a lot of press. The reason why it’s not discussed very often is because it’s only provided in an abstract form. That is you have to create a concrete implementation before you can use it. As it turns out this is not that hard to do. For example the following C# code is an example of a simple implementation for an Order class: More...