This project is read-only.

GUID primary keys

Mar 11, 2009 at 5:16 PM
In my experience, using GUIDs as primary keys becomes very inefficient as the size of the DB grows.
Is there any particular reason you opted for this approach?

As I understand, you've already identified all the appropriate entities to allow for multiple sites and multiple blogs (areas) etc. So why can't a identity seeded int PK column be used?

Mar 11, 2009 at 7:13 PM
Yes, there are performance differences, but they're minor until you get into huge amounts of data.  If someone is running a site on Oxite so huge that GUIDs as PKs become a problem, we can look into it.  But I can promise you there will be other performance issues much more important than GUIDs as PKs that would need to be addressed first.  Are you having performance issues?
Mar 11, 2009 at 9:19 PM
Hey Erik,
No I haven't been having any performance issues.
I guess it was just more a design decision question than anything else.
It's also much easier to compare integers at a glance than it is GUIDs etc. So I was just interested to see if there was an underlying reason for the choice.

But that all aside (and it goes without saying) - cool fu*kin' app!
I'm still at the exploritory phase. I'm trying to decide how I can fit the S#arp Architecture idiom (I don't know if you're aware of the project) into the Oxite framework . So combine Oxite functionalities with the S#arp approach for CRUD and unit testing.

Mar 11, 2009 at 9:39 PM
It was mostly just a personal preference.  With everything being the same type for IDs you can do some interesting things around logging.  That's not reason enough to do it, but since I like it, I went with it.  :)  To be honest, this project started out of me extracting what our team built for into something more generic we could share with others.  Sometimes design decisions are made very quickly.  ;)