Rsa97

Смотрим здесь. Получаем для обычного INT 4 байта на одно число, для BIGINT 8 байт.
200 * 4 * 10'000'000 = 8'000'000'000 или 8Gb.
200 * 8 * 10'000'000 = 16'000'000'000 или 16Gb.
По нынешним меркам сущие пустяки.
Хранить, конечно же, нужно в нормальной форме, иначе суммирование придётся делать в приложении.

Создаёте запись в первой таблице без указания связи, получая ID созданной записи через RETURNING. Создаёте запись во второй таблице, указывая связь с первой и получая ID созданной записи через RETURNING. Меняете запись в первой таблице, прописывая ID связанной записи из второй таблицы.
Но, по большому счёту, одна из ссылок лишняя. Она ничего не даёт, только добавляет необходимость дополнительного контроля, чтобы не оказалось, что столица Китая - Пекин, но Пекин - столица США.

На ум приходит решение создать вторую таблицу где для каждого товара указывать id других товаров с которыми он может продаваться

Правильно приходит. Это стандартное решение - таблица связи для отношения многие-ко-многим.

А что вам мешает в таблицу questions_tags добавить несколько записей с одним question_id и разными tag_id?

Если вас в схеме есть связь один-к-одному, то, с большой вероятностью, вы что-то сделали неправильно.
В данном случае нет необходимости в отдельной таблице `refferal`, достаточно поля `referrer_id` в таблице `users`, так как пользователь может зарегистрироваться только по одному приглашению.
Аналогично, не имеют смысла таблицы `inventory` и `item_inventory`, достаточно поля `user_id` в таблице `items`.

Нужна таблица с состояниями полей, как описал Владимир Коротенко и таблица с общим состоянием игры (game_id, user1_id, user2_id, next_move_user_id).
0. Сервер генерирует новую игру и рассылает её id обоим игрокам.
1. Игрок расставляет на своём поле корабли и сообщает расстановку серверу.
2. Сервер проверяет корректность расстановки и сохраняет её в базу данных.
3. Когда расстановка обоих игроков сохранена, сервер выбирает, за кем будет первый ход, и посылает сообщение о начале игры.
4. Игрок присылает на сервер свой ход (id_игры, id_игрока, строка, столбец).
5. Сервер проверяет корректность и результат хода, сохраняет новое состояние и посылает результат хода обоим игрокам.
6. Повторять с 4 пункта до выигрыша какого-либо игрока.

1. Зачем в билете поле "зал", когда оно есть в сеансе?
2. Зачем в билете поле "сектор", когда оно есть в цене?
3. Зачем в цене поле "сектор" ни с чем не связанное?
4. Зачем в сеансе Поле1?
5. Из чего определяется цена? Возможно, должна быть таблица вида (зал, сектор, интервал дат, цена) или (сеанс, сектор, цена)?

Храните начало и конец срока действия подписки, и пусть покупают хоть посуточно.

IMHO, самый простой вариант - временны́е слоты по 15 или 30 минут и SQL.