Удобное хранение Item в инвентаре игроков, домов и автомобилей

[execution]

Хотел уточнить, как лучше всего хранить предметы для всех видов инвентарей.
В планах было сделать одну таблицу для Item (там будет: owner_type(игрок, автомобиль, дом), owner_idx(его sql_id или уникальный ид) и при загрузке уже расфасовывать в соответствующие массивы для домов, игрока и автомобиля?

[Pro_Coder]

Не поверишь, сам недавно писал вот прям точно что ты описал, но я сделал ячейки от домов в БД дома и т.д. Сначала тоже были мысли вывести все в отдельную таблицу, но передумал.

[punkochel]

Я бы сделал так: Все что касается данных, в которых необходимо хранить значение и количество - отдельная таблица (Телефон, скины, аксы, и так далее);
Для остальных данных создать отдельную таблицу, например транспорт, так как там необходимо хранить ид авто, два цвета, винилы и компоненты тюнинга, ибо за зря не использовать память в таблице;
Что касается домов, то лучше их вообще никак не связывать с игроком. Дом - это отдельный предмет, а игрок - это лишь владелец предмета.

[execution]

Я бы сделал так: Все что касается данных, в которых необходимо хранить значение и количество - отдельная таблица (Телефон, скины, аксы, и так далее);
Для остальных данных создать отдельную таблицу, например транспорт, так как там необходимо хранить ид авто, два цвета, винилы и компоненты тюнинга, ибо за зря не использовать память в таблице;
Что касается домов, то лучше их вообще никак не связывать с игроком. Дом - это отдельный предмет, а игрок - это лишь владелец предмета.
Ты о чем? Я имел ввиду, что можно предметы хранить и в доме, и в машине и на руках у игрока

[DeimoS]

Ну либо для каждого инвентаря создай отдельную таблицу и привяжи её к игроку/дому/автомобилю через ID строки, либо, если не напрягают таблицы с большим количеством столбцов - храни прямо в таблицах нужные данные.
Особой разницы тут в плане обработки данных нет. Всё лишь завязано на твоём будущем удобстве работы с данными в БД.

[execution]

Ну либо для каждого инвентаря создай отдельную таблицу и привяжи её к игроку/дому/автомобилю через ID строки, либо, если не напрягают таблицы с большим количеством столбцов - храни прямо в таблицах нужные данные.
Особой разницы тут в плане обработки данных нет. Всё лишь завязано на твоём будущем удобстве работы с данными в БД.
Просто немного смущает повторяющиеся значения во всех таблицах с инвентарём как в бд, так и хранения на сервере

[DeimoS]

Просто немного смущает повторяющиеся значения во всех таблицах с инвентарём как в бд, так и хранения на сервере

Какие повторяющиеся значения? У тебя будет отдельно система инвентаря со своим хранением, отдельно багажник, отдельно шкаф в доме и т.п. Тебе не нужно хранить данные инвентаря в таблице шкафа и т.п.

[execution]

Какие повторяющиеся значения? У тебя будет отдельно система инвентаря со своим хранением, отдельно багажник, отдельно шкаф в доме и т.п. Тебе не нужно хранить данные инвентаря в таблице шкафа и т.п.

Например: id, type, count, weight абсолютно везде будут.
Но в случае, если я захочу изменить какой-либо инвентарь, то в случае хранения в одной таблицы - придется нагораживать столбцами

[DeimoS]

Эмм, ну будут они везде, но информация-то в них будет разная. Не очень понимаю сути вопроса.

У тебя будет, допустим, 3 разных системы, которые могут хранить предметы, и для них ты сделаешь 3 разных таблицы. В каждой конкретной таблице ты будешь хранить исключительно содержимое каждой конкретной системы. Точно так же, как с массивами в моде.

[execution]

Эмм, ну будут они везде, но информация-то в них будет разная. Не очень понимаю сути вопроса.

У тебя будет, допустим, 3 разных системы, которые могут хранить предметы, и для них ты сделаешь 3 разных таблицы. В каждой конкретной таблице ты будешь хранить исключительно содержимое каждой конкретной системы. Точно так же, как с массивами в моде.

Меня просто очень смущает и никак не даёт успокоится тот факт, что все эти три системы будут однотипны и надо делать 3 разные системы.

[DeimoS]

Меня просто очень смущает и никак не даёт успокоится тот факт, что все эти три системы будут однотипны и надо делать 3 разные системы.

Только так делать и нужно - системы должны быть максимально самостоятельными, а все взаимосвязи уже должны строиться через дополнительные промежуточные функции. Ибо, банально, если в будущем ты решишь, например, изменить одну из систем, тебе не придётся придумывать костыли для того, чтоб не сломать две другие системы, которые ты написал в тесном взаимодействии с первой.

В общем, не о том ты сейчас переживаешь. Тебе, в самую первую очередь, сейчас нужно писать максимально понятный и структурированный код, в который, в будущем, удобно будет вносить правки и выискивать в нём баги. Оптимизация - это последнее, о чём ты должен сейчас думать. Оптимизируй ровно на интуитивно понятном уровне (то бишь, в плане оптимизации делай только те вещи, которые тебе сразу в голову приходят и которые не усложняют код). Если ты напишешь качественный код, то даже если в реальной работе он начнёт вызывать проблемы - тебе не составит труда его оптимизировать. А вот если ты изначально только и будешь, что пытаться оптимизировать то, что оптимизации особо не требует - ты будешь страдать с этим кодом в будущем, когда тебе потребуется его поддерживать.

UPD: Ну если прямо очень свербит вся эта ситуация, то, для начала, скинь хотя бы примеры кода или опиши более подробно те моменты, которые тебе не нравятся. Ибо описание "системы будут однотипные" не говорит ни о чём, так как даже инвентарь можно множеством разных способов реализовать.

[execution]

Только так делать и нужно - системы должны быть максимально самостоятельными, а все взаимосвязи уже должны строиться через дополнительные промежуточные функции. Ибо, банально, если в будущем ты решишь, например, изменить одну из систем, тебе не придётся придумывать костыли для того, чтоб не сломать две другие системы, которые ты написал в тесном взаимодействии с первой.

В общем, не о том ты сейчас переживаешь. Тебе, в самую первую очередь, сейчас нужно писать максимально понятный и структурированный код, в который, в будущем, удобно будет вносить правки и выискивать в нём баги. Оптимизация - это последнее, о чём ты должен сейчас думать. Оптимизируй ровно на интуитивно понятном уровне (то бишь, в плане оптимизации делай только те вещи, которые тебе сразу в голову приходят и которые не усложняют код). Если ты напишешь качественный код, то даже если в реальной работе он начнёт вызывать проблемы - тебе не составит труда его оптимизировать. А вот если ты изначально только и будешь, что пытаться оптимизировать то, что оптимизации особо не требует - ты будешь страдать с этим кодом в будущем, когда тебе потребуется его поддерживать.

UPD: Ну если прямо очень свербит вся эта ситуация, то, для начала, скинь хотя бы примеры кода или опиши более подробно те моменты, которые тебе не нравятся. Ибо описание "системы будут однотипные" не говорит ни о чём, так как даже инвентарь можно множеством разных способов реализовать.

Да, ты прав. Также обнумав на досуге понял, что разделение самое оптимальное для правок, спасибо.

[punkochel]

Почему бы не сделать, скажем переменную Place, создать константы INV_PLACE_HOUSE, INV_PLACE_CAR... которая будет отвечать за место в котором хранится предмет?

[DeimoS]

Почему бы не сделать, скажем переменную Place, создать константы INV_PLACE_HOUSE, INV_PLACE_CAR... которая будет отвечать за место в котором хранится предмет?

А зачем вообще указывать место, в котором хранится предмет, если об этом и так будет говорить то, в каком массиве хранятся данные?

[punkochel]

А зачем вообще указывать место, в котором хранится предмет, если об этом и так будет говорить то, в каком массиве хранятся данные?

Так это именно на тот случай, если человек хочет сделать один массив для всевозможных предметов.

[DeimoS]

Так это именно на тот случай, если человек хочет сделать один массив для всевозможных предметов.

Только в этом нет никакого рационального смысла.
Во-первых, в том же инвентаре обычно присутствуют ещё активные слоты, которых не будет у транспорта, домов и т.п.
Во-вторых, таким массивом даже управлять будет не особо удобно (особенно если количество ячеек будет разным для разных систем).
В-третьих, для получения данных, например, инвентаря придётся использовать цикл, отфильтровывая данные остальных систем, на что будет тратиться лишнее время.

И всё это ради того, чтоб потратить, в лучшем случае, столько же памяти, сколько и при отдельных массивах. Вспоминается фраза про стрельбу в собственную ногу.