views:

68

answers:

2

I'm experimenting with db4o as a data store, so to get to grips with it I thought I'd build myself a simple issue tracking web application (in ASP.NET MVC). I've found db4o to be excellent in terms of rapid development, especially for small apps like this, and it also negates the need for an ORM.

However, having come from a SQL Server/MySQL background I'm a little unsure of how I should be structuring my objects when it comes to relationships (or perhaps I just don't properly understand the way object databases work).

Here's my simple example: I have just two model classes, Issue and Person.

public class Issue
{
    public string ID { get; set; }
    public string Title { get; set; }
    public string Description { get; set; }
    public DateTime? SubmittedOn { get; set; }
    public DateTime? ResolvedOn { get; set; }
    public Person AssignedBy { get; set; }
    public Person AssignedTo { get; set; }
}

public class Person
{
    public string ID { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
    public string Password { get; set; }
}

The ID properties are just GUID strings generated by the .NET Guid.NewGuid() helper.

So here's how I initially thought the application would work; please ignore any security concerns etc and assume we already have a few Person objects stored in the database:

  1. User logs in. Query the database for the Person which matches the username and password, and store his/her GUID id as a session variable. Redirect to app home screen.
  2. Logged in user creates a new issue ticket, selecting the user to assign it to from a drop-down list. They fill in the other details (Title, Description etc), and then submit the form.
  3. Query the Person objects in the database (by their GUID ID's) to get an object representing the logged in user and one representing the user the ticket has been assigned to. Create a new Person object (populated with the posted form data), assign the Person objects to the Issue object's AssignedBy and AssignedTo properties, and store it.

This would mean I have two Person objects stored against each Issue record. But what happens if I update the original Person—do all the stored references to that Person in the various issue objects update, or do I have to handle that manually? Are they references, or copies?

Would it be better/more efficient to just store a GUID string for the AssignedBy and AssignedTo fields (as below) and then look up the original person based on that each time?

public class Issue
{
    public string ID { get; set; }
    public string Title { get; set; }
    public string Description { get; set; }
    public DateTime? SubmittedOn { get; set; }
    public DateTime? ResolvedOn { get; set; }
    public string AssignedByID { get; set; }
    public string AssignedToID { get; set; }
}

I think I'm just stuck in a certain way of thinking which is confusing me. If someone could explain it clearly that would be most helpful!

+2  A: 

Hi

Object-Databases try to provide the same semantics as objects in memory. The rule of thumb is: It works like objects in memory. Object databases store references between the objects in the database. When you update the object, that object is updates. And if you have a reference to that objects, you see the changed version.

In your case, the Issue-objects refer to the person object. When you update that person, all Issues which refer to it 'see' that update.

Of course, primitive types like int, strings, longs etc are handled like value objects and not a reference objects. Also arrays are handled like value objects in db4o, this means a array is stored together with the object and not as a reference. Everything else is stored as a reference, even collections like List or Dictionaries.

Gamlor
Thanks, that certainly makes sense.
Mark B