I've got a question about my current database/business object design concerning the use of GUIDs for "lookup values". I have setup my NVL classes in CSLA to expect a GUID and a string. In some of my tables, I have GUID fields used for holding "lookup types". For instance, lets say I have a table called Fruit that has a field called fruitType of type GUID. That GUID would link back to a table called Lookup that stores this GUID, along with a string value that describes the lookup type (maybe "orange", "apple"....). Some of my tables have several of these "lookup fields" and I'm worried that the GUID column maybe be overkill because of it's size. Should I have just used an integer value?
Dustin
I'm not a db expert, but I think they are probably overkill. In your examples the 16 bytes of the GUID are bigger than the data itself, which seems bad.
GUID values are great for data where you are inserting, updating and deleting rows on a regular basis, especially if you need to use replication or anything like that.
But lookup tables rarely fit that scenario. They are usually quite static and are rarely altered. Even when using replication or synchronization, it is relatively unlikely that you'd allow the lists to be changed anywhere but your master database.
But as I say, I'm not a db expert, and others may have better educated views.
The only advantage you may gain in using GUIDs is that every one of your different lookups would have an absolutely unique identifier.
So you could, if you wanted, get just one of them individually. If that's a requirement for you, then you're fine. But that is not typical lookup-type NVL lists behaviour.
So I would probably agree that they are overkill.
I was pretty sure I would get that answer, but I just wanted to get somebody else to shoot it down so I didn't have too ![Sad [:(]](/emoticons/emotion-6.gif)
. I think the reason I went that way is that the CodeSmith templates created an NVL with a <Guid,String> combination, but I may be wrong. At any rate, looks like I'll be changing to integers. Thanks for the confirmation.
Dustin
Dustin,
When designing NVL lists for binding in a windows application I initially used long integers and could not get them to bind correctly to comboboxes for lookups. Eventually I found the binding only worked in my windows forms app if I changed the key to integers. I presumed this to be some failure in casting behind the scenes. By reverting to integers you will probably find your business objects more flexible in terms of UI otions.
Copyright (c) Marimer LLC