On 4 Nov 2012, at 5:26pm, "Dominguez Bonini, David"
wrote:
> I have an application where a table is filled with elements whose primary key
> is specified at insertion, and is actually a combination of several
> independent IDs. Example: ItemID = (id0 << 32) + (id1 << 16) + (id2).
> The range
I'd say generally speaking your way of storing data has no significant
downsides. There's just one "but": if each row in your table stores pretty
significant amount of data (blobs, long text fields or just lots of
different fields) you'd better not make your ItemID INTEGER PRIMARY KEY.
Because SQLi
Hi,
I have an application where a table is filled with elements whose primary key
is specified at insertion, and is actually a combination of several independent
IDs. Example: ItemID = (id0 << 32) + (id1 << 16) + (id2).
The range covered by each ID guarantees that their sum will never exceed th
3 matches
Mail list logo