One to X relationship constrained by the database

[Sgraffite]

Are you going to maintain validation logic in 3 or more places if your application has to support more than one DBMS -- with different syntax, no less? Development tools and support are considerably better for application code. Now you're stuck trying to implement mocking and unit tests for constraints on each platform.

There are times where you could make an argument for putting business logic into the database, like for data warehousing systems, but even that's debatable. The OP described his app as a "game" so I'm going to assume this isn't one of those times. Dividing responsibility into several application layers is a no-no.

I guess I don't think of it as business logic as it's just enforcing a relationship for the sake of data integrity. I don't unit test one to one or one to many relationships as I figure the foreign keys are enough to guarantee data integrity.

 

[Mr.IncrediblyBored]

I understand that, and if that's the biggest downside I'll take it over the alternative. The ORM I'm using does database table mapping to C# objects and I prefer to the syntax Object.Id instead of Object.ClassNameID when referencing the ID of an object.

What are the downsides of the alternative? Don't give somebody the noose to hang themselves so they can't do something stupid like this:

Gem g = new Gem();

What does g.Id give me? Or g.getId(), or however your ORM handles the mapping.

 

[Sgraffite]

What are the downsides of the alternative? Don't give somebody the noose to hang themselves so they can't do something stupid like this:

Gem g = new Gem();

What does g.Id give me? Or g.getId(), or however your ORM handles the mapping.

In C# the default for a non-nullable int is 0, so g.Id would be 0 with a newly created Gem object. I don't see how that is stupid as that is pretty normal syntax for creating an object.

 

[Mr.IncrediblyBored]

Sorry my point was unclear. I was referring to the vague naming, not the initialized value.

If I have an object g of type Gem, the line g.Id is completely nondescriptive in what it returns.

 

[Sgraffite]

I'm sorry I'm still not following it seems. If I know g is of type Gem and I'm specifying the Id property, that seems clear to me.

 

[Mr.IncrediblyBored]

I admit this is a lot less important than the time I'm spending but here goes anyway. It's about making it clear for other people reviewing your code. If I'm quickly scanning through code and see this:

int i = g.Id;

By itself this line explicitly says nothing besides "Id" being an integer. How can I tell what g is without hovering over it or backtracking to where it's declared? Now compare it to this:

int i = g.GemId;

GemId implies g is an instance of Gem or one of it's related models. Ideally nobody would use obscure variable names like that, but it happens. Make your data model and underlying schema descriptive enough to be self-documentating so it's never unclear what you are looking at. What's the worst that could happen? Something like this?

int i = myGem.GemId;

The redundancy is worth the additional clarity. Just my opinion.

 

[Merad]

Or, you know, use variable names that are more descriptive than "g". The main problem with your approach is that you lose any obvious distinction between the table's local key and foreign keys. But it's very bordering on a po-tay-to po-tah-to thing.

 

[Ken g6]

i prefer to name columns based on what they contain, rather than what table they're in. ItemGem's foreign keys contain ItemIDs, GemIDs, and GemSlotIDs. Why not name the columns in other tables that contain the same contents the same way?

 

[Sgraffite]

i prefer to name columns based on what they contain, rather than what table they're in.

Does that mean you don't prefix the primary key column with the table name because you're not naming it based on the table it is in, or you do because you want to be specific about the data it contains? I feel like that sentence can be read both ways.


If you wanted to use generics in C# land it is convenient to have them all of the primary keys named ID. In this case when the ORM maps the database tables to C# objects I can then add an interface to each class that represents a table, such as IHasIdentity, and then when I use generics my type T I know for sure has the property ID. I'm not sure how the generics would would if every primary key had the table name prefixed to it in the C# class, maybe you could do it with a data annotation for aliasing?

Sure there are ways around this, other ways of doinbg things, different ORMs, etc. This is a matter of opinion really as there is no obvious best way.

 

[Ken g6]

I want to be specific about the data a column contains. Though I may not use the entire table name. I suppose I picked up that habit - good or bad - from Drupal, where Node IDs are in "nid" columns.

 

[Sgraffite]

It sounds like we're both making decisions that make sense based on our environment, so differences are to be expected because the environments are different.