http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Because the last is a generic method that saves me a cast, it has no other meaning. http://ayende.com/2594/case-sensitive-optimization#comment5http://ayende.com/2594/case-sensitive-optimization#comment5Mon, 25 Jun 2007 08:28:14 GMTOT: Why is the type specified twice, and with different syntax? First with: CreateCriteria(typeof(Post)), Then with: UniqueResult<Post>() http://ayende.com/2594/case-sensitive-optimization#comment4http://ayende.com/2594/case-sensitive-optimization#comment4Mon, 25 Jun 2007 08:25:29 GMTFrans, It is actually there for a good reason, because: CUSTOMER_IS_DOFUS key is shown as "Documentation Issue" to the user http://ayende.com/2594/case-sensitive-optimization#comment3http://ayende.com/2594/case-sensitive-optimization#comment3Mon, 25 Jun 2007 08:07:16 GMTSame here, string / date based PK fields are evil if you use them for things like descriptions. A customerID as a string... ok, but this example perfectly proofs that an ID should have been used: Your whole Status table is redundant. It looks like a normalized table but the attribute that identifies a status is identical to the name attribute :) http://ayende.com/2594/case-sensitive-optimization#comment2http://ayende.com/2594/case-sensitive-optimization#comment2Mon, 25 Jun 2007 07:41:53 GMTYet another reason I prefer surrogate keys for ids in databases. ;) http://ayende.com/2594/case-sensitive-optimization#comment1http://ayende.com/2594/case-sensitive-optimization#comment1Mon, 25 Jun 2007 00:23:02 GMT