kuza2000, я не против SQLite. Мне просто надо вникнуть в суть вашей задачи и понять какой класс запросов там бегает. И только после этого я смогу что-то точнее сказать. А пока... берите SQLite.
kuza2000, в твоей активности в топике нету никакого Acceptance Criteria. Тоесть ты не задаешся конкретной целью а просто играешся. В этом случае мы цели никогда не достигаем а просто проводим время в беседе.
Я не специалист именно по SQlite но я тебе хочу сказать что не стоит завязываться на какую-то стандартную библиотеку питона. И то что ты написал по стилю разработки (jupiter/pandas) это не мобильное и не встраиваемое приложение а вполне себе серверное. Значит нечего там экономить на спичках. А SQLite он потому и лайт потому-что изначально делался для in-memory и мобил. А сегодня по нелепой случайности в него грузят терабайты. И всем пофиг. Один я удивляюсь.
ТЗ я себе написал, как мог, а дальше? Планирование архитектуры приложения, базы данных, фронт или бэк?
Чтоб никто здесь не фантазировал. И я не фантазировал. Архитектура разрабатывается только исходя из требований.
Тоесть мы должны прочитать твои требования. Например - в каком виде нужно показать статистику. Эту задачу можно сделать как в 1 таблицу а можно и в 10 таблиц. Все зависит от того что требуется. Нормализация там. Нужно ли хранить историю переходов игроков из команды в команду. Требование? Я считаю да. Что делать если команда сменила название? Заводить новую запись или просто переименовывать? Это - все вопросы архитектуры.
kuza2000, вы занялись очень плохим и неподходящим для баз данных делом. А именно - экономией места. Т.к. вы неоднократно упоминаете "компактность" и "максимально плотное заполнение". Обычно базы данных - не про это. Если у вас - особый кейс - то возможно вам не нужен SQLite а стоит программировать свою собственную (key-value или document-oriented) систему где вы сможете хоть сжимать gzip-пом поля хоть делать column-oriented структуры. Короче я хочу сказать что база данных будет сопротивлятся вашему стремлению ее ужать. Такова ее природа. И многие механики баз данных очень не любят всякие "ужатия".
Но если вы хотите сильно - то попробуйте разбить таблицу на серии. Поскольку у вас загрузка идет сериями - то пускай каждая серия создает табличку. Вы ее уплотняете. И переводите как-бы в Read/Only. В этом случае результат вашего уплотнения хотя-бы сохряняется. В остальных случаях он будет потерян для индексов точно.
DollyPapper, смотрите. Поскольку вы не автор топика - то будет неприлично здесь разводить долгий спор. На тему ООП в Python - вы лучше создайте отдельный вопрос в хабр. Я думаю это будет правильнее.
DollyPapper, Python не способствует дисциплине кода.
Когда ты будешь изучать ООП, которое за собой тащит SOLID, Design Patterns и тому подобное ты просто увидешь что некоторые языки сознательно вводят много ограничений (в т.ч и типизация) и это в будущем помогает читать код когда он разраставется до сотен модулей и десятков тысяч классов.
Читать Python код сложнее т.к. в нем нет ПРАКТИКИ применения типов. Это часто ставит разработчика-читающего в затруднительное положение. Получается что ему недостаточно видеть сигнатуру метода а ему надо вычитать все uses и returns чтобы понять контракт.
И хотя начиная с некоторого релиза аннотации типов введены, сообщество пока не приняло эту практику и можно сказать что % использования практически равен нулю.
Я пересекаюсь с Python мало. Лишь в части Spark/PySpark. И в тех случаях когда надо по "быстрячку наговнячить" запросов к датафреймам. Но самые вкусные фичи (например DataSet) и строгий контроль типов по прежнему PySpark недоступны. И чтобы их потрогать - нужно брать Scala.
В остальном Python - хороший язык и вы можете его смело брать для украшения резюме. Но если вы хотите знать тонкости ООП то вам будет НЕДОСТАТОЧНО использовать Python. Берите специальные языки C++/C#/Java вот шаблоны проектирования как раз писались про них и тестовые примеры как раз тоже с этими языками.
Dmitry Roo, я у себя подозреваю камни в почке и думаю что автору все равно нужен фикс для его исходника. Господин Баелдунг прав в своих примерах - но нужен какой-то специфичный кейс где это применимо и не принесет вреда кроме пользы.
Dmitry Roo, вот вы ему щас дадите совет. А он за чистую монету возьмет и будет всегда все текстовые файлы загружать скопом в массивы байт. Так себе шаблончик.
Drno, если ты решил переключится с работы на игру - то это так себе переключение. Всяко лучше на улицу сходить чем жечь глаза еще больше. Я тоже немало поиграл в своё время. И щас уже вообще не тянет ни разу.
gena_vit, не я пас. Я с Виндовс графикой лет 15 назад последний раз что-то делал.
Да и тяжело там все. Неудобно. Какие-то простые вещи надо так нудно кодить.
Щас вот Python + mathplot мне рисует любые графики. Или еще в Java JChart я что-то делал.
Вот. А вся Rich-графика делается в браузерах в основном. Браузер - как view для твоего
приложения.
У тебя есть текстовые месседжи для календаря. Их можно разбирать классической логикой парсеров и извлекать дату и время. А остальное - камменты. И это решение будет детерминированным и покроет 99% кейсов что ты сможешь придумать.
Постановка... какая-то расплывчатая. Попробуй в виде кейсов описать. Вот модель твоя уже обучена и на вход пришел текст: Input "сходить до врача в следующую субботу"
Можно скачать книжку в pdf, и попробовать почитать ее на хорошем EBook. Если будет достаточно - то ОК.
Если нет - то заказать Hard Cover.
Я как старый библиофил и читака - очень люблю бумажные книги. И подарочные варианты этих книг. Но я признаю что мы живем в такое бурное время что тех-литература очень быстро стареет. Например фреймворки - живут 1.5-2 года и после этого их описание в книгах становится просто неактуальным.
20+ часов??? Дружище. Да ты просто катастрофический нарушитель охраны труда.
Рабочий день - 8 часов. Овертаймы - отдельно идут с накоплением отгулов.
Вообще есть такое правило. Действовало еще когда я на гос-предприятии работал.
45 минут работаем с моником. Далее 15 минут - другая работа где можно зрение переключить
на что-то другое. Бумаги. Книги.
Упражнения для хрусталика глаза с переводом зрения на окно - это да. Это работает.
Еще хорошо работает игра в настольный теннис. Позволяет как-раз тренировать фокус зрения.
И еще раз - иди к врачу.
Да кто-ж вам запретит-то хоссподи...