Subject | AW: [firebird-support] binary or string? |
---|---|
Author | Alexander Gräf |
Post date | 2004-12-11T18:27:45Z |
> -----Ursprüngliche Nachricht-----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.
> 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.
> First and foremost the database needs to remain fast, myNo, 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):
> 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.
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