Hi
I'm implementing an EditableRootCollection/EditableChild portion of our object model and as the subject suggests am curious as to how to implement GetIdValue() for data that does not have a single uniquely identifying integer key (surrogate key?).
In this particular case the Root has 2 keys and the Child has 3 keys of which 2 are shared with the root.
Having not fully read your book although I've read chapters 1,2 and skimmed most of the rest of it, the only dependencies on this method to my knowledge are Equals(), GetHashCode() and ToString() in BusinessBase<T>.
I was thinking of implementing 2 public structures say RootKey and ChildKey and use these inplace of the integer type ID in the templates.
Will this work? Is this best practice CSLA?
Any help much appreciated.
Thanks in advance
Howard
Hi Howard,
I would suggest revising the data model and making a single uniquely identifying integer the primary key for both the root and the child. If your requirements require you to have unique values in a set of columns, then create a unique constraint/index on those columns in the root or child table but keep the primary key a unique integer column in both the root and child data sets.
Thank you,
Cosmic Ovungal
Thanks for the response, I'll pass this on to the DBA.
However, if the DBA turns round and says no, is the approach I outlined still valid/workable?
Hi Howard,
The approach you outlined may work but it will not be standard CSLA practice. It will also lead to maintenance nightmare later on down the road. Thats because you are using composite key as a primary key. In my experience, the primary key should always be a single column, usually a unique integer which is given the identity property in SQL Server.
If you are planning for replication or inserting data from other table, then you would choose a RowGuid as your primary key which generates a primary key based on NIC card on your machine.
Cosmic Ovungal
Andres,
There's is nothing wrong in having composite PKs but it complicates matters a lot. Its best to avoid having composite PKs because you have to take all the columns that compose a PK and import it into another table as a FK.
Its best to keep matters simple by having a single column PK and implementing business requirements of uniqueness among columns by creating a unique index/constraint on such columns. This has been my practical experience.
But if a composite key is required, then your method would be the way to go.
Cosmic Ovungal
Cosmic - What kind of maintenance nightmare you are referring to? Surely everything is encapsulated within the structure itself? With Equals() implemented and perhaps an operator override for =, I don't really see how this makes life any harder other than having to code a handful of very simple structures and having more parameters to pass around? Also, the structures and parameters themselves would be inherently more readable rather than surrogate integers or guids thus making debugging easier. Am I missing your point?
Andres - having just read the help on Object.GetHashCode() I think your solution is the only option short of actually implementing a custom hashing algorithm and I for one don't want to go there :)
Although of course you would need to make some effort to ensure that clashes do not occur perhaps by introducing a delimiter character between the strings?
Rockford - What is your stance/advice on this?
Yeah, doh (slaps head). Quite right. Just got off messenger with designer and came to exactly the same answer (with delimiter character tho.).
Thx.
Absolutely - just concatenate the parts of the key with a delimiter and you should be all set. That's what I do. Sometimes compound keys are the right answer, no doubts there.
Alternately, GetIdValue() doesn't necessarily need to reflect the database at all. You could keep a Guid value private to your object as its "id" value while in memory. This can get confusing, so I don't know that it is always the right answer, but in the case that you don't have any other unique identifier for your object this can be the right answer.
Natural keys are great in theory but are usually lousy in practice. This is why I usually use surrogate keys now. If the user is able to change any of the values of the key, you will need to store the old values of the key in the object so you can update the key in the db. DBA’s with little to no programming experience are probably more likely to use natural keys. However, you should not change your db structure to fit your code. I have used concatenation and GUIDs in the past. Both methods work; however they are a hassle when compared to the alternative.
![Smile [:)]](/emoticons/emotion-1.gif)
Can't a composite key be a natural key? And vice versa can't a natural key be a composite key? Just wondering. And is SSN a natural key. I would think the DNA fingerprint would be the only natural key for humans. Again, just wondering.
Cosmic Ovungal
Ajj3085,
The reason why I brought up natural keys is because composite keys are usually made up of natural keys. If you use surrogate keys instead of composite keys, you have no need for composite keys. BTW, I did not say all natural keys are bad.
Copyright (c) Marimer LLC