|
| Best practice storing GUID's in tables |
| Iniciado por Ulrich, 19,dic. 2017 17:41 - 3 respuestas |
| |
| | | |
|
| |
Miembro registrado
36 mensajes |
|
| Publicado el 19,diciembre 2017 - 17:41 |
Hello,
I am wondering if there is a best practice on how to store GUID's in an HFSQL table.
Two methods come to mind:
- store the 32 characters in a normal string or
- convert it into a 16 byte ASCII string
Any of you using this?
Glad for comments/suggestions
Ulrich |
| |
| |
| | | |
|
| | |
| |
| Publicado el 19,diciembre 2017 - 18:39 |
Hi
I'm storing them as a 24bytes ansi string, encoded in base64...
As for transforming them in binary (which is what I think you are
hinting at), you couldn't store the result into a string field, as there
may be a binary zero in the result (ie end of string)
Which means that the only way to store such a value would be in a
buffer, and it couldn't be used as key.
Now, if you find a way to store a GUID as 16 bytes only and still use it
as key, I'm all ears...
The reason why I'm doing it as 24 bytes stirng intead of 32 is that I
used them extensively along with my replication system, so the decrease
in size helps the communication speed.
And there is a collection of procedures available for the base64 buid
(and conversions) in the open source section of my web site
Best regards
--
Fabrice Harari
International WinDev, WebDev and WinDev mobile Consulting
Ready for you: WXShowroom.com, WXReplication (open source) and now WXEDM
(open source)
More information on http://www.fabriceharari.com
Le 12/19/2017 à 11:41 AM, Sollberger a écrit :
Hello,
I am wondering if there is a best practice on how to store GUID's in an
HFSQL table.
Two methods come to mind:
- store the 32 characters in a normal string or
- convert it into a 16 byte ASCII string Any of you using this?
Glad for comments/suggestions
Ulrich |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
36 mensajes |
|
| Publicado el 19,diciembre 2017 - 22:58 |
Hi Fabrice,
I thought you might reply as you are the one who gave me the GUID in the first place.
Concerning the potential of a double zero occuring could a small routine returning a valid GUID in 16 bytes look something like this:
PROCEDURE GetMyGUID():string
s is string
WHILE length(s)<>16
s = HexaToBuffer(GetGUID(guidRough))
END
RETURN s
solve the problem? Maybe needs to cater for endless loop but I doubt it.
Ulrich |
| |
| |
| | | |
|
| | |
| |
| Publicado el 20,diciembre 2017 - 10:47 |
Hi Ulrich,
as I have no idea how frequently a GUID would contain a binary zero, I
suppose that part COULD work, but I would still test that solution like
crazy on several android devices before using it in the wild... and of
course, you would need to TYPE the strings as ANSI.
the potentially problematic points: would the resulting guid...
- be searchable (as a key) on android, on iOS and everwhere else (need
to test on all platform)?
- be transferable easily from a string into another (windows, android,
iOS, web)
- be usable easily as a URL parameter (URLencode mandatory, on that one)
so yes, potentially, you would save 8 extra bytes compared to my current
solution... which is good in case of heavy
transfer/communication/replication.
However, the amount of testing needed before I would feel comfortable
that it would work in every situation I need it to work for an universal
replication may not be worth it...
So, FOR ME, it's a case of cost/benefit analysis, right there
Best regards
--
Fabrice Harari
International WinDev, WebDev and WinDev mobile Consulting
Ready for you: WXShowroom.com, WXReplication (open source) and now WXEDM
(open source)
More information on http://www.fabriceharari.com
Le 12/19/2017 à 4:58 PM, Sollberger a écrit :
Hi Fabrice,
I thought you might reply as you are the one who gave me the GUID in the
first place.
Concerning the potential of a double zero occuring could a small
routine returning a valid GUID in 16 bytes look something like this:
PROCEDURE GetMyGUID():string
s is string
WHILE length(s)<>16
s = HexaToBuffer(GetGUID(guidRough))
END
RETURN s
solve the problem? Maybe needs to cater for endless loop but I doubt it.
Ulrich |
| |
| |
| | | |
|
| | | | |
| | |
|