Hi,
Well, there are a couple of reasons that I think UUIDs are a better solution for me. But remember, of course, being a rookie, that I could be deluding myself, but the answers that I received from the Servoy U folks (and some discussion with my Servoy mentor) made sense. So, here goes…
In a standard multi-tenant environment being supported on a single server, integer keys are just fine. However, if the application has the potential to grow to multiple servers or make use of other types of distributed systems, then UUIDs eliminate any possibility of duplicate key problems. With that in mind…
My application is currently distributed as a Microsoft Access runtime app. As part of the move to Servoy, I’ll have the ability to distribute the app both as a web application with a shared database, and as a runtime with it’s own copy of the database. That creates at least the potential for duplicate keys if the owner of a runtime version decides to move over to the web application (which is what I hope every one of them will do). There are a couple of ways to handle this. One, I could create a “dummy key” of sorts in the web application whenever I sell a runtime version of the app, effectively reserving that primary key for later use if needed. Or, I could use UUIDs, in which case I always have unique keys.
Also, I have on the drawing board a number of new applications that have the potential to share information from my existing app. Although those are a still “a gleam in my mind’s eye”, I can foresee sharing information from one app to another, and using UUIDs gives me a unique key that is consistent across all of my applications, so I can move information from one system to another without having to worry about identifying information by combinations of name, address, etc.
For example, my current application supports artists on the business side of their art. It’s primarily meant to be single user application. I will be adding, say, a studio version of the software, and in that software, an artist could be a part of a studio, and would have created their art information there. They could later decide that they’d like to use one of my other products, and by having unique keys across applications, they could simply migrate their information from one system to another (I’m creating a standard protocol to allow the apps to talk to each other).
And, in my more delusional moments, I see a time when I might be so successful that I’ll need to run the apps on multiple servers. That, I’m told, is a good use of UUID keys.
So, there you have it. I’m certainly open to other thoughts, since I don’t consider myself anything approaching competent yet. This seemed like a reasonable approach. Now, the folk at Servoy U that I traded a couple of messages with didn’t seem to believe that the overhead from using UUIDs was anything to be overly concerned about, but I suppose that’s all relative.
Lastly, yes, I have had a couple of Servoy folks tell me that using the runtime is akin to dealing with the anti-Christ (actually, what they said was more like “it’s not our preferred method of distribution” ![:-)]( "Smile")
). For now, I can’t assume that my existing customer base are all going to come running to the web app, and so I have to account for that. In the long run, I’d like to have them all on the web app, but for now, I have a lot of flexibility.
Thanks again for your thoughts. Appreciate it.
Ron