> > I'd like to create another table with
> > "AverageSalaries" combining the ID's from (a) and (b)
> > into a unique 8 byte ID. I'm thinking that the
> > columns would be "SuperID" (8 bytes integer created by
> > combining each ID from the city table with the ID from
> > each job table and
--- Andrew Piskorski <[EMAIL PROTECTED]> wrote:
> That seems bizarre. Typical RDBMS practice would be
> to just use a
> two-column composite primary key.
>
>
> Did you measure a serious performance problem when
> joining on two
> separate columns?
>
You're right. It feels bizarre to me too.
On Wed, Sep 07, 2005 at 07:23:59AM -0700, Jay Siegel wrote:
> I'd like to create another table with
> "AverageSalaries" combining the ID's from (a) and (b)
> into a unique 8 byte ID. I'm thinking that the
> columns would be "SuperID" (8 bytes integer created by
> combining each ID from the city
On Wed, 2005-09-07 at 07:23 -0700, Jay Siegel wrote:
> 1. Is numeric column storage maintained in an
> endian-independent way?
Numbers are stored on disk in big-endian byte order.
> Can an 8 bytes
> numeric key be used or must if be treated as an 8 byte
> text field?
>
SQLite uses 64-bit
I have two questions. I'm starting a large project
with SQLite on multiple platforms. I'm hoping I can
get some ideas about two issues:
1. Is numeric column storage maintained in an
endian-independent way? I need to port SQLite to a
platform that is in Motorola format (big endian) but
haven't
5 matches
Mail list logo
