How do you represent "secondary keys" in SQL - sql

Question

I have a list of data that I want to relate to some ownerId, but the list can exceed row size limits, so I want to split this list across multiple rows. Each entry in this list has its own id, which is unique per owner. I was looking at composite keys (ownerId:entryId), but the main operation I need is to read this data in bulk (read all entries for ownerId). What is the best way to go about structuring this data?
Example:
ownerId | entryId | data
--------|---------|--------
OwnerA | 1 | aaaaa
OwnerA | 2 | bbbbb
OwnerB | 1 | ccccc
Note that ownerId here is a SQL generated id, and entryId is an externally set id.

Answer 1

If you know that consumers of your query will filter on ownerId instead of entryId (i.e. the vast majority of WHERE clauses in your table will filter on ownerId as opposed to entityId), then you could get significant mileage simly by creating a composite clustered key/index on (ownerId,entryId). I say this because relational indexes use the first column as the primary sort criteria, so as long as you're filtering based on ownerId, under-the-hood, rows can be retrieved with INDEX UNIQUE SCAN operations as opposed to TABLE FULL SCAN operations.
That being said, if you'll have to be filtering both on ownerId and entityId independently (i.e. you'll have several queries in which the WHERE clause will be of the format WHERE ownerId = {specific_owner_id} and several other queries in which the WHERE clause will be of the format WHERE entityId = {specific_entity_id}, you might want to consider having both a PRIMARY KEY/CLUSTERED INDEX on (ownerId, entityId) and a unique index on (entityId, ownerId):
CREATE TABLE t (
ownerId INT NOT NULL,
entityId INT NOT NULL,
/*
...all other values ...
*/
CONSTRAINT PK_t PRIMARY KEY (ownerId, entityId)
);
CREATE UNIQUE INDEX t_entity_owner ON t (entityId, ownerId);
If you do this, both queries which filter on ownerId and entityId can take advantages of INDEX SCAN operations.
That being said, this type of configuration will be most optimal if table t
is used more for READ operations than for WRITE operations. Should your table be more WRITE heavy, then the time taken to modify each of the indexes could outweigh the benefits of more efficient query reads.

Answer 2

You probably need a composite primary key, i.e.:
CREATE TABLE t (
...
PRIMARY KEY (ownerId, entryId)
);
and some separate index for ownedId, for example in postgres hash index might be a good fit.