Според моя опит това зависи до голяма степен от данните, които се съхраняват. И двата начина имат предимства и недостатъци. Ако това е MMORPG уеб игра след това кажете, че имате компютър който има колан. И компютърът може да постави отвари в този колан за бърз достъп по време на битка. Така че искаме да запазим идентификаторите на отвари, които се съхраняват в колана на героя.
Най-често срещаната молба би била "вземете всички отвари, които има герой X". И това ще стане доста бързо и в двата случая.
Предимствата от съхраняването на тези идентификатори на отвари като отделна таблица:
- Можете да търсите определен идентификатор на отвара и това е много бързо. Пример в играта:администраторите премахнаха някаква отвара от играта и затова трябва да актуализирате коланите на всички
- Можете да получите хубави статистически данни. Пример по време на игра:потърсете най-използваната отвара сред всички играчи
- Базата данни ще поддържа целостта на данните. Пример в играта:никога няма да срещнете ситуация, когато сте използвали отварата и играта казва „Ами сега, отвара с този идентификатор не съществува“
- Добър е за последователност. Пример по време на игра:взехте отвара от колана и я сложихте в раницата. Играта може да го приложи чрез извикване на транзакция с две прости ясни SQL израза.
- Можете да правите JOIN. Пример по време на игра:трябва да получим списък с отвари в колана заедно с техните имена, тегла и изображения, които се съхраняват в отделната таблица.
- Можете да актуализирате един елемент, без да е необходимо да актуализирате целия колан. Принуден-пример в играта:имате милион отвари в колана си и сте изпили една.
Предимствата на съхранението като json:
- Ако това е браузърна игра, която използва javascript от страна на клиента, тогава получавате обекта Belt json с една проста заявка, вместо да правите Select-заявка и след това да конвертирате в json.
- Много по-лесно е да поддържате реда на елементите, тъй като json масивите вече са подредени. С подхода на таблицата ще ви е необходима допълнителна колона, наречена "поръчка", и да я актуализирате всеки път и да проверявате дали два елемента нямат еднакъв ред и т.н.
- Можете да направите няколко пренареждания в колана от страна на клиента, след което щракнете върху „Прилагане“ — бум, с една заявка можете да актуализирате целия колан. Докато при подхода към таблицата ще ви трябват поне две заявки за това (DELETE + INSERT)
- Освен това популярните СУБД имат приставки които поддържат json функции в базата данни
В крайна сметка:те не са основни предимства и некритичнини проблеми. Всички те са разрешими и при правилен дизайн на приложението и двете решения ще работят добре. Преди да решите как да съхранявате данните, попитайте се кои са най-често срещаните случаи на употреба на тези данни и след това изберете решението.
