Re: UUID data type
Re: UUID data type
- Subject: Re: UUID data type
- From: Ramsey Gurley <email@hidden>
- Date: Tue, 22 Mar 2016 09:16:41 -0700
The readability pro/con you mention is actually reversed IMO. The gid is a database artifact and should be treated as such. Attaching any meaning to it is only asking for trouble. The only thing one should ever need to do with it in a query is join on it.
Opinions out of the way, I would test it. I suspect 16 bytes is just better. I would generate two tables with several million rows of each, then check to see if the index size and speed is significantly different. That should be easy enough to do in an hour or two and save you a lot of grief in the long run.
On Mar 22, 2016, at 7:03 AM, Samuel Pelletier <email@hidden> wrote:
> Hi,
>
> I'm working on adding uuid support as primary key with a prototype and ERRest support. Actually, my implementation uses a 16 bytes NSData as the adaptor value type. Before going too far in this, I would like to validate my choices...
>
> I see 2 options:
>
> 1- A 16 bytes NSData
>
> Pro: It seems the most efficient and adapted data type.
> Cons: Hard to read and type in SQL queries. GlobalIds are cryptic.
>
> 2- A 32 char hex string (or a 36 one if pretty printed with the dashes).
>
> Pro: Easier to read, especially with the dashes.
> Cons: Uses more spaces, maybe less fast. Seems a bit awkward to deal with hex strings.
>
>
> For the ERRest part, I managed to format the uuid in a primary key by detecting if it is a 16 bytes NSData in the formatted hex representation. I also found a way to get objects using the hex representation.
>
> Any though on this ? Something I missed ?
>
> Finally, is a presentation on using uuid for primary key in next WOWODC would be a good topic ?
>
> Samuel
>
>
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden