Comments by "" (@moodcraft8198) on "Михаил Омельченко | Django School"
channel.
-
1
-
"если плохое может случиться, то оно случиться"
слушайте, с таким аргументом конечно трудно спорить, но если вы так рассуждаете, то если случится так что злоумышленник получит секретный ключ которым вы парсите токены и достаете пермишены, то он нарисует вам любые плохие события, но давайте будем честны, таких "плохих" событий может быть масса и в таком контексте у вас миллион уязвимостей
предлагаю подключать криптографа который настроит цепочку шифрования ключей .env файла, а то плохое произойдет и будет ай яй яй
предлагаю пойти дальше. чтобы злоумышленник случайно не получил доступы к докер образам и на подкорректировал код, предлагаю настроить тройную обфускацию исходного кода с компиляцией байткода питона в бинарный код, чтобы точно никому не оставить шансов
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
зачем корзина на беке? - crates
разве в стиме ордер создается до момнта оплаты?
почему order и sales не обьденить в одно ведь фцнкциональное назначение одно и тоже
есть список sales которое демонстрирует список продаж. в каждом sale должны быть все данные продажи в том числе список купленных продуктов. subtotal, total, fee.
libraries нужно переименовать в profile games. order id вообще убрать. зачем в libraries order_id? где вы видели в стиме в библиотеке указание на ордеры? если смысл в том чтобы показать списоей платежей и игр то для этого есть Sales который уже имеет список группы купленных продуктов одним платежем
libraries после переименовывания в ProfileProducts и удалением поля order_id становится более гибкой и семантически понятной.
ProfileProducts должно иметь ссылк на профиль в одном поле и список игр профиля в другом. иначе Libraries будет содержать по одной записи на одну игру на одного юзера, тем самым иметь сложность по памяти в N в степении 100 млн при условии что игру купили 100 млн людей. ведь при таком условии нужно создать 100 млн записей на 100 млн профилей и это только по одной игре.
Вместо этого делаем таблицу ProfileProducts с указанием профиля в одном поле, и в другом поле строку, в которую сохраняем хеш содержащий идентификаторы всех купленных игр профиля. на application layer делаем процессор для этой модели который пишет в таблицу валидный хеш и парсит его при чтении. все. теперь количество записей ProfileProducts будет равно количеству профилей
и то, здесь тоже стоит подумать.
таблица dlc вообще не нужна. почему не сделать dlc = продукт?таким образом облегчая работа процессинга игр везде.
таблица Languages вообще не нужна. список языков всегда статичный. предположим что в мире 300 языков. зачем в базе хранить 300 статичных записей?
вместо этого берет Bitmap и через него укладываем в поле Languages интовое значение которое при чтении будет процессится на уровне application layer и через Bitmap получается комбинация языков. все.
на питоне это джелается так
https://docs.python.org/3/library/enum.html#enum.IntFlag
что касается дисконтов - делаем таблицу Discoun, которая имеет поле promocode, процент скидки, дату начала и конца и список продуктов. таким образом мы покрываем скидки по промокодам при создании ордера, и благодаря списку игр под этот дисконд, на уровне application layer в отдельном потоке процессим каждые N часов (24) и проверяем совпадение текущей даты и времени на все дисконды и обновляем цены на соответстующие игры. так как в моменте все цены на игры будут статичны, и они могут изменяться только при времени экспирации дисконда или при ручном изменении цены на игру, - нам не нужно каждый запрос в бек считать цены на игры. мы это делаем в отдельном потоке раз в N часов и показываем клиенту уже посчитанные (закешированные) данные
кстати, почему в таблице libraries есть указание order_id? у вас разве не раздвелены этии сервирсы? библиотека это games сервис а order_id это про пейменты. какаво функциональное назначение этой связи?
sales groups вообще не нужна.
- orders/ crates убираем
- sales экранирует покупку
- discount хранит данные по скикдкам и акцияим, дисконд процессор процессит их
- libraries переделываем в ProfileProducts, уберает order_id, products делаем хешем, на апликейшене делаем хеш процессор
- таблицы group_* тоже не понял зачем вообще нужны, ввсе категории игр статичны. это опять таки вопрос bitmap. строим битмап плоским списком и имеем любую возхможную комбинацию с уникальным интовым значением и так укладываем в базе. всё. никакой возни с категориями.
куплена игра или опубликована девелопером, она так или иначе попадает в таблицу ProfileProducts. будто то девелопер имеет доступ к своей игре или клиент купил игру роли не играет.
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1