I completely agree that performance is a a big deal. As long as an ID using a GUID is not configured as a clustered index, the hit should be negligible relative the performance constraints of web applications in general.ACDC wrote:There are pros and cons of moving to GUID, all you have to do is google GUID VS INT and see the concerns of using GUID as the ID, specifically regarding database performance.
Specifically within the AwareIM stack of moving parts, the performance bottleneck is never going to be using GUID as an ID.
1. Business Rules Engine rule processing
2. Queries - FIND is always translated to a "Select *"
3. The extra database call to increment and select the new id from the BAS_IDGEN table for every insert
4. The client-side parsing and rendering of every part of the UI
5. The generation of the XML containing the data sent over the wire which is then parsed on the client.
If we're looking for top-end performance, AwareIM isn't the right platform.
In any event, you can have an Identity column for sequential numbering that is the clustered index if you like.ACDC wrote: If AwareIM decides to go with GUID it should be optional, so a developer can choose based on the circumstance and type of application. I use the ID number for numbering and naming of documents and transactions. I can't imagine using a GUID for that purpose. The simplicity of using the ID for its uniqueness and ordered sequence across the DB is compelling.