Size: a a a

2019 December 30

AB

Anatolii Bogdanov in ГОРИ
так как я только изучаю программирование, бд и прочее, то сейчас нашел инфу о том, что есть relations между таблицами. в целом, когда игрок зайдет в локацию, можно посмотреть какие еще игроки там есть из локации. но, игрок же должен двигаться из одной локации в другую. в таком случае надо перебирать все локации и всех игроков (выглядит очень не очень). тогда остается выбор, и в игроке хранить локацию и наоборот, но тогда я не понимаю как применять relations of db
источник

АК

Андрей Каликин in ГОРИ
Нет не надо всех перебирать
источник

АК

Андрей Каликин in ГОРИ
Именно для этого существуют ключи и отношения
источник

АК

Андрей Каликин in ГОРИ
Иначе бы серваки Фейсбука просто вставали бы, когда надо было бы показать количество лайков под записью
источник

AB

Anatolii Bogdanov in ГОРИ
то есть в данном случае связь many to many и нужна связывающая таблица?
источник

АК

Андрей Каликин in ГОРИ
Таблица энтитей на карте
источник

АК

Андрей Каликин in ГОРИ
Этого достаточно
источник

АК

Андрей Каликин in ГОРИ
Зачем many to many, ты собрался одного игрока в несколько локаций пихать сразу?
источник
2019 December 31

AB

Anatolii Bogdanov in ГОРИ
Андрей Каликин
Таблица энтитей на карте
прочитал статей, но так и не понял 🙁
Поясните плиз для тугих
источник

S

Sasha S. in ГОРИ
источник

AB

Anatolii Bogdanov in ГОРИ
Отдельную таблицу связывающую location_id и player_id?
источник

S

Sasha S. in ГОРИ
Если у плеера может быть только одна локация, тогда можно же прямо в строке записи игрока хранить
источник

S

Sasha S. in ГОРИ
(и в той же таблице разумеется)
источник

S

Sasha S. in ГОРИ
Но можно... если доступ к локации часто требуется и часто перезаписывается, то вынести в отдельную таблицу с целью оптимизации (наверное), где ключём будет player_id
источник

AB

Anatolii Bogdanov in ГОРИ
Понял. Спасибо!
источник

A

Anton in ГОРИ
Anatolii Bogdanov
так как я только изучаю программирование, бд и прочее, то сейчас нашел инфу о том, что есть relations между таблицами. в целом, когда игрок зайдет в локацию, можно посмотреть какие еще игроки там есть из локации. но, игрок же должен двигаться из одной локации в другую. в таком случае надо перебирать все локации и всех игроков (выглядит очень не очень). тогда остается выбор, и в игроке хранить локацию и наоборот, но тогда я не понимаю как применять relations of db
хранить в строке локации всех монстров и игроков глупо. у тебя должны быть четкие разграничения статических сущностей и динамических, таблица с локациями у тебя по сути справочник, она заполняется один раз и потом только read-only. также можно иметь таблицу со списком всех возможноых монстров, тоже read-only. и уже потом ты создаешь таблицу типа monsters-in-locations, где у тебя будет ссылка на таблицу монстров и таблицу локаций для каждой записи
источник

A

Anton in ГОРИ
в этой таблице может быть время последнего спавна, позиция спавна и т.д., динамическая информация, которая может меняться после каждого убийства моба, например
источник

A

Anton in ГОРИ
вообще прочитай про нормализацию БД и про 3ю нормальную форму, вот её ты и будешь реализовывать для хранения данных
источник

AB

Anatolii Bogdanov in ГОРИ
полезно. спасибо
источник

OM

Oleg Morozov in ГОРИ
@Voidy @churchill_raccoon кого не хватает для золотого состава?
источник