Well, externally (inside my application) I would rarely, if ever, need to
compare one OID to another, they're used for primary keys *only*.

My main concern is how efficiently they're stored in the DB. If joining two
64-bit integers together in a query is faster than two char(16) octets, than
I'll take your advice. I would imagine it would be much faster as numeric
comparisons are generally faster than character-based comparisons (in
probably most modern databases).

Portability is my priority, performance is second but of course, you're
right, any modern DB has a 64-bit int option.

-v

_____

From: Alexander Gräf [mailto:graef@...]
Sent: Saturday, December 11, 2004 11:28 AM
To: firebird-support@yahoogroups.com
Subject: AW: [firebird-support] binary or string?

> -----Ursprüngliche Nachricht-----
> Von: Storage Box [mailto:spam@...]
> Gesendet: Samstag, 11. Dezember 2004 19:20
> An: firebird-support@yahoogroups.com
> Betreff: RE: [firebird-support] binary or string?
>
> This is exactly the approach I went with due to maximum
> portability. I already wrote a class in C# that handles the
> conversion in a very efficient way (binary to string, string
> to binary, I'm happy w/ the benchmarks.

You told us about 8-byte/64 bit. In this case you would need to use CHAR(8)
CHARACTER SET OCTETS. And in your case, you should *absolutely* use a
numeric 64bit type, which is provided by any modern database system I know.
You should not store it in CHAR(8), even on SQL Server.

> First and foremost the database needs to remain fast, my
> application is much more flexible for performance/scalability
> tuning so I'll worry about that next. Char(16) is probably
> the best option at this point.

No, use 64 bit BIGINT. Only use CHAR(xy) CHARACTER SET OCTETS if you have
more than 8 bytes to store. For example, to give you an example of what
needs to be done to compare to values (pseudo code):

Int64 val1, val2;
If (val1==val2) ....

Vs.

Byte val1[16], val2[16];
If (memcmp(val1, val2, 16) == 0) ...

First approach is much faster, so if there is any chance to get data into a
natively support datatype, you should use it. Only use byte/char-arrays if
the datatype is too big, and then only store the binary represantion. Never
store stringified Hex-representation, because you're wasting much space and
performance.

Regards, Alex


Yahoo! Groups Sponsor

ADVERTISEMENT

<http://us.ard.yahoo.com/SIG=129v7sp8u/M=295196.4901138.6071305.3001176/D=gr
oups/S=1705115386:HM/EXP=1102876061/A=2128215/R=0/SIG=10se96mf6/*http://comp
anion.yahoo.com> click here

<http://us.adserver.yahoo.com/l?M=295196.4901138.6071305.3001176/D=groups/S=
:HM/A=2128215/rand=314811374>

_____

Yahoo! Groups Links


* To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/


* To unsubscribe from this group, send an email to:
firebird-support-unsubscribe@yahoogroups.com
<mailto:firebird-support-unsubscribe@yahoogroups.com?subject=Unsubscribe>


* Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .




[Non-text portions of this message have been removed]