Я бы порекомендовал последний вариант, который вы упомянули, создайте одну зависимую таблицу с пятью столбцами:
CREATE TABLE Items (
user_id INTEGER NOT NULL,
item_id INTEGER NOT NULL DEFAULT 1,
numeric_property1 INTEGER,
numeric_property2 INTEGER,
referential_property INTEGER,
PRIMARY KEY (user_id, item_id),
FOREIGN KEY (user_id) REFERENCES Users(user_id)
ON DELETE CASCADE,
FOREIGN KEY (item_id) REFERENCES num_items(item_id),
FOREIGN KEY (referential_property) REFERENCES some_other_table(some_column)
);
Я показываю таблицу num_items выше, которая содержит цифры от 1 до 10, если вы хотите ограничить пользователей максимум 10 элементами:
CREATE TABLE num_items (item_id INTEGER NOT NULL );
INSERT INTO num_items (item_id)
VALUES (1), (2), (3), (4), (5), (6), (7), (8), (9), (10);
Преимущества этого дизайна в том, что легко COUNT() сколько элементов у данного пользователя, легко вычислять такие вещи, как MIN() и MAX() для данного свойства, вы можете принудительно использовать внешний ключ для ссылочного собственность и т. д.
В некоторых базах данных есть функция для объявления второй части составного первичного ключа (в данном случае item_id) с автоинкрементом, поэтому, если вы укажете значение для entity_id, но опустите item_id, он автоматически получит следующее неиспользуемое значение (но не заполняет пробелы, если вы удалите одно). Вы не указываете, какую марку базы данных вы используете, поэтому я предоставлю вам возможность выяснить эту функцию.
edit: Как говорит Тони Эндрюс в своем ответе, количество строк не является проблемой. Вы не указываете, какую марку базы данных вы собираетесь использовать, но если вы не выберете особенно слабый продукт, такой как MS Access, вы можете положиться на базу данных, чтобы легко обрабатывать миллионы строк. Если вы хорошо выбираете индексы и пишете запросы, использующие эти индексы, эффективность не должна быть проблемой.