Вопрос - почему в первом варианте база с таблицей получилась 692 КБ, а во втором - 2347 КБ, более чем в 3 раза больше!
Чтоб задать вопрос - нужно иметь какое-то предположение или гипотезу относительно результата. Ты-же не ребенок который спрашивает "почему море - соленое?".
Вот у тебя очевидно были в голове какие-то расчеты относительно размера индекса. Какие? Как ты прикидывал на глазок? Или коэффициент накидывал?
Дмитрий, scrum backlog grooming - это процесс ухода за твоими user stories. По сути обсуждение как лучше реализовать. Вот ты избегаешь обсуждения деталей. Что-то брякнул и ушел. И как ты думаешь - по твоему ТЗ тебе хорошо сделают? Тебе насоветовали и ftp, и webdav и черт знает что. И никто не обсуждает их сравнение свойств. Что обсуждает что ftp не версионируется? Кто обсуждает что web-дав это никому не нужный протокол лишь для веба а не для локалки. Кто обсуждает что графические UI приблуды для бэкапа никак не скриптуются и не управляются автоматизировано.
Тут толи тегов не хватает. Толи исходников. Вроде как майнкрафи на Java написан. Значит и плагины под него тоже должны быть в сорцах. Короче как говорил один финский кодер - taks is cheap. Show me the code.
Дмитрий, экий ты злой. Git имеет сильные преимущества для текстово-ориентированных документов. Потому что позволяет с точностью до символа определить что где менялось. А эксцельки будут расматриваться как бинарники. Впрочем тебе при такой глубине груминга должно быть все равно что Git, что SVN.
OGSegu, ну смотри. Я вижу 2 решения. Их оба надо попробовать от простого к сложному.
1) Допустим ты копируешь с MicrosoftBlob storage на AWS/S3. Идешь в гугол и ищешь fuse-драйвер для обоих. Ставишь и монтируешь. Появляются два фолдера. И дальше дело техники. Через линуксовую утилиту rsync или через cp копируешь с одного на другое.
2) Разработка. Предположительно тебе понадобятся два клиента. Вот этот для МС https://mvnrepository.com/artifact/com.azure/azure... и вот этот для Амазончика https://mvnrepository.com/artifact/com.amazonaws/a...
Далее ты ищешь разработчика который напишет некий Abstraction Layer над бакетами и фолдерами и файлами и простой функцией скопирует все оттуда сюда. Или отсюда туда. Здесь даже больше возможностей чем в rsync. Можно много проверок сделать. Например фиксировать Etag/SHA1/MD5.
Я написал пример для Java, но можно найти весь стек и под Python.
И то что ты написал про Rest API - это не нужно. Нет смысла ломать головой все двери. Если есть клиент - то используй его. И кстати да. Внутри он написан на RestAPI это правда. Только формат хидеров и ключей там достаточно хитер и нет смысла его в очередной раз реализовывать.
DemPi, ты не поверишь но кодировки - это 80% ошибок всех новичков. Я-бы в ВУЗ-ах ввел отдельный предмет. Под названием работа с символами и байтами в инфо-технологиях.
Реально! Преподаватели и магистры! К вам обращаюсь! Почему из ВУЗов выходят люди которые систематически палятся на кодировках?
На ниве Windows-разработки есть свои графические технологии (WPF, WinForms, Xamarin).
Они прочно занимают место и очень хорошо интегрированы с ядром Windows/.Net. Поэтому
если кто-то захотел делать графику под Windows - то его сначала спросят хорошо-ли он подумал
и почему он вдруг взял Java а не DotNet. Все таки вендор имеет свои преимущества.
В области Linux - царит хаос графических сред. Там даже несколько типов декстопов (Gnome/KDE) которые
друг с другом не совместимы. И там частично это решается за счет Qt либо других С++ фреймворков.
Для MacOS я не вкурсе. Но там наверное что-то своё есть проприетарное и продаваемое за деньги.
Пускай знающие дополнят.
Что осталось для Java? Графические фреймворки AWT/Swing которые пока еще живы но выглядят по разному
на разных ОС. Кто их щас использует - я ХЗ. Но это сегодня явно легаси. SWT - хорошо выглядит и на нем
написаны некоторые приложения типа торрент качалок - но это не чистая Java а следовательно принцип
совместимости может не работать.
JavaFX остался никому не нужной сироткой. Я честно говоря не знаю известных продуктов которые-бы были
написаны и успешно проданы. Если знаете - то скажите.
kuza2000, я не против SQLite. Мне просто надо вникнуть в суть вашей задачи и понять какой класс запросов там бегает. И только после этого я смогу что-то точнее сказать. А пока... берите SQLite.
kuza2000, в твоей активности в топике нету никакого Acceptance Criteria. Тоесть ты не задаешся конкретной целью а просто играешся. В этом случае мы цели никогда не достигаем а просто проводим время в беседе.
Я не специалист именно по SQlite но я тебе хочу сказать что не стоит завязываться на какую-то стандартную библиотеку питона. И то что ты написал по стилю разработки (jupiter/pandas) это не мобильное и не встраиваемое приложение а вполне себе серверное. Значит нечего там экономить на спичках. А SQLite он потому и лайт потому-что изначально делался для in-memory и мобил. А сегодня по нелепой случайности в него грузят терабайты. И всем пофиг. Один я удивляюсь.
ТЗ я себе написал, как мог, а дальше? Планирование архитектуры приложения, базы данных, фронт или бэк?
Чтоб никто здесь не фантазировал. И я не фантазировал. Архитектура разрабатывается только исходя из требований.
Тоесть мы должны прочитать твои требования. Например - в каком виде нужно показать статистику. Эту задачу можно сделать как в 1 таблицу а можно и в 10 таблиц. Все зависит от того что требуется. Нормализация там. Нужно ли хранить историю переходов игроков из команды в команду. Требование? Я считаю да. Что делать если команда сменила название? Заводить новую запись или просто переименовывать? Это - все вопросы архитектуры.