Mongodb Schema design help c# driver

[Ali]

I am working on a system where mongodb has been chosen as the backend db. The system stores adverts for cars. There are the following collections so far:- cars - list of adverts posted by users userprofile - list of users in the system containing names,address,phone no etc.

Now the issue I have here is that the users can be of different types e.g, private user, dealer user, admin user etc.enter code here

My thinking is that the userprofile collection can embed details of dealers where required and leave them empty when not in use so as an example:-

public class userprofile
{
public string Username{get;set;} 
public string UserFirstname{get;set;}
....
public UserType UserType{get;set;}
public Company Company{get;set;}
}

Using this model would it be ok to decide who the user is by checking the UserType, i.e UserType == UserType.Dealer then I can look into the Company object otherwise ignore it.

Or would it be best to do this some other way.

Any suggestions appreciated.

[Robert Stam]

That approach will work. If the Company property is null in C# then it will be stored as a BSON null in the database. You could also tag it with [BsonIgnoreIfNull] if you didn't want the null value stored in the database.

You could also set up a class hierarchy where the subclasses add properties that are relevant to that type of user.

For example:

[BsonKnownTypes(typeof(Dealer)] // tell the driver about the known subclasses

public class UserProfile

{

    // properties common to all types of users

}

public class Dealer : UserProfile

{

    public Company Company { get; set; }

}

When you call GetDatabase provide the root type as the document type of the collection:

var collection = database.GetCollection<UserProfile>("users");

var dealer = new Dealer { ... };

collection.Insert(dealer);

When you save an instance of a subclass (like Dealer) to  a collection where the default document type is a base class (like UserProfile), the driver automatically adds what's called a discriminator to the stored document:

{ _id : ???, _t : "Dealer", ..., Company : "Acme" }

The discriminator is stored in the element called "_t".  The ... represents the fields common to all user types (they came from the base class).

The discriminator serves more or less the same purpose as your UserType property, but there is harm in having both of them.

--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com
To unsubscribe from this group, send email to
mongodb-user...@googlegroups.com
See also the IRC channel -- freenode.net#mongodb

[Ali]

Thanks for that.

I guess the question is now as follows, would it be a bad design decision to use two different collections in this case as they mare me lots more private than dealers for example, or would it be best to stick with the inheritance approach you have mentioned.  Also ifyou mentioned the discriminator _t and said "there is harm in having both" was that "there is no harm is having both"?

I would rather this this right as there may be many types of users and I want performance gain when the size increases but then again I also want a good design that can later be switched if required.  Also if the discriminator is there and I do not have a UserType property would I still do

if(userprofile == dealer) to determine the user type?

Thanks

[Robert Stam]

Nothing wrong at all with using two collections if you would rather segregate the data. That's fine.

If you omit your UserType property and are still using a polymorphic inheritance tree and storing all the users in a single tree, you would have to use some other way to test what type of user you just read. Probably something like:

if (user.GetType() == typeof(Dealer)) // test the C# type of user

{

    // user is a Dealer

}

Of course if Dealers are in their own collection you wouldn't have to test at all since you would just know that all users in that collection are Dealers.

I did mean "no harm" rather than "harm" in my last sentence. Sorry for the unfortunate typo!

--

[Ali]

Thanks for the help I will end up using one of these ways and just see what happens.

On Friday, October 5, 2012 2:06:33 PM UTC+1, Ali wrote: