колонок это UserId.
То есть нужно отдавать на фронт только данные конкретного юзера.
Есть вопрос по Id. У каждой строки в таблице с данными Id как я понимаю должен быть уникальным. То есть даже для данных для разных юзеров айдишники в таблице данных не должны повторяться. Как такое решается?
Сейчас айдишник гененируется инкрементом на клиенте, для множества юзеров такой вариант не подходит из-за дубликатов.
Делать айдишник случайной строкой, или запрашивать его с сервера, или при создании объекта отправлять его на сервер, в базу, а потом получат его же с айдишником? Или может вообще убрать PRIMARY KEY с Id в таблице данных? Как правильно?
Потому что есть разница в опыте)
Наверно, но все же блин основные основы то нужны, есть вероятность что парень до этого вопроса всегда данные в файл сохранял?)
Нет основ, 14 месяцев работы в геймдеве и скоростной переезд в веб. Я вроде понимаю что айдишник нужно генерить на сервере, поэтому и спрашиваю блин :)
а, ну тогда ладно, окей. Желаю успеха и роста , с кайфом)
Извиняюся за офтоп, а чего с геймдева сбежал?)
Есть два (три) подхода. 1 - генерация id в бд при создании записи (обычно int32/int64 - порядковые номера. Запись создана позже - ее Id больше. На это можно полагаться при сортировке). Можно не париться - бд сама сгенерирует новый уникальный id и позаботиться о том, что одинаковые Id не будут созданы. 2 - генерация уникальных id на клиенте. Можно генерировать уникальный 128битный ключ - guid. Он тяжелее int32/int64 и по нему нельзя сортировать (в последних версиях Guid вроде можно, но я не пробовал). С другой стороны это даёт удобство и безопасность - guid почти не возможно перебрать. 3 - использовать ключи int32/int64, которые Бд из последовательности выделяет для клиента, который планирует создавать новые сущности. Не видел на практике, но такой подход существует.
Обсуждают сегодня