Вопрос в самом деле очень путано выглядит. Может автор хочет рисовать в окне приложения пикселами?
Или на декстопе? Честно такие вопросы во времена DOS решались проще. И даже объяснить что просиходит
было проще. Включил там какой-нибудь VGA mode. Записал в видеопамять парочку пикселов. Вот оно. Видно.
А щас действительно поди поясни. Абстракции абстракциями погоняют.
Assylkhan777, спасибо я поберегу своё зрение. Кроме того кто-то вам уже выдал очередное unsupportable решение. Пишите на него модульные тесты. Проверяйте.
Assylkhan777, обращайтесь к вашим тех-лидам и архитекторам. То что вы делаете - это безсмысленное переусложнение простых вещей. Не нужно переусложнять простое. Это плохо для поддержки кода.
Автор ты хочешь всю таблицу вернуть через return? Обычно так не делается. Я не помню технических ограничений на длину строки в Python. Может это нечно вроде 2 млрд символов. Но когда работают с базами данных (по настоящиему) то предполагается что размер БД и таблиц во много раз превышает размер доступной памяти. В этом и есть специфика баз. На то они и базы. И возможно твоя табличка sqlitedb_developers - игрушечная и тебе это не грозит но просто помни о моей рекомендации.
Любая попытка протолкнуть содержание целой таблицы через python dictionary или через JSON/CSV строку - должна рассматриваться пристально. С претензией на memory overhead.
Я добавлю что самые дорогие в мире ошибки - это ошибки разработки. Никакое железо не гарантирует отсутсвия лагов. Природа лагов вообще настолько сложна что по каждому из них нужно делать целое техническое расследование. И я например как разработчик могу написать такой код, который положит в состояние "полочки" все ваши процессорные ядра. И я буду прав. И никакой тестировщик не докажет мне что я где-то напортачил. Код работает - as designed.
Вопросы дальнейшего улучшения - за отдельные деньги.
Сомнительно, что в этой задаче имеет смысл использовать файлы.
С точки зрения современных WebAPI, файловая система давно уже стала метафорой. Мы не знаем
что стоит по ту сторону от веб-интерфеса. Файловая система? Или иерархическая таблица? У нас даже нет возможности проверить если мы не знаем архитектуры. И я в своём месседже выше говорю только о структурности хранения. Тоесть о сущностях таких как фолдеры и файлы. Но я ничего не говорю о физической реализации.
Román Mirilaczvili, time-to-live - это интересная опция но она совершенно бесполезна в данной задаче. Ведь никто на уровне тех-задания не говорит о каких-то временнЫх параметрах. Речь идет только о порядке доступа.
Наверное на такой вопрос не будет ответа. Потому что активность в браузере может быть любая. Например простое использование JavaScript в части window.localStorage подгрузит оперативную память хранением key-value базы. Будут лаги связанные со свапом ило доступом к странчной памяти а ты будешь списывать эти лаги на процессор.
Или Unity игра, которая по сути будет использовать графические части системы которые будет задыхаться от нагрузки в то время когда основной процессор будет гулять.
Тоесть твой вопрос - это матрица стратегий. На чем будешь делать бенчмарк - то и улучшай. А получить как "с куста" перформанс да и еще и "задёшево" - это не сработает.
В подобного рода базах обычно пишут темпоральную информацию. Например Беляева была заумжем за всеми мужчинами в этой таблице просто в разное время. Тоесть информация обладает началом действия и длительностью.
Кроме того люди могут менять фамилии. Значит для одного человека может быть несколько записей.
Справочник SPR_ROLE явно неполный. Этих статусов может быть много крат больше. Приёмный сын. Биологический сын. Отчим. Мачеха. В базах соц-сетей могут быть прочие забавные статусы типа там "любовник", "в отношениях". И эти статусы тоже могут быть темпоральны.
