Тут приложение борет проблему которая высосана из пальца. Само по себе сложение - длинных целых - это
очень простой алгоритм.
А вот эта форма хранения чисел - это какая-то чепуха и несуразца.
Вот твой пример.
Например: число 111 - это 1 3 1, а число 21 это 2 1 2 1 1.
Заметно что число в котором цифры различаются (а таковых чисел - подавляющее большинство)
занимает более чем в 2 раза больше места чем оригинальное число.
Представь сколько символов будет занимать следующее.
1234567890
10 цепочек. По одному символу в цепочке.
Я здесь не вижу никакой оптимизации кроме как игнорировать этот архиватор Бабушкина и
просто вычислять в длинной арифметике как и задумано. Если есть предположение
что оптимизация даст полезный эффект - то хочу узнать на чем основано это предположение?
Может быть на том что бы будем складывать цепочки цифр типа
111111111111111111111111 или 2222222222222 ? Но это никак не акцентировано
в задании.
Вообще какая цель этой лабораторной? Какая тема? Что изучаете?
Можно сделать с UNION ALL где мы добавляем ранг ответа и в первом ранге ставим фактический результат
а во втором ранге - дефолтный. Но это усложняет билдер запроса и вобщем-то господин потомок
древних династий говорит верно. Решайте это на стороне приложения а не БД.
Обычно идут от запроса. Какие виды запросов вы хотите делать к гос-услугам? Это важно. Это самый важный вопрос который стоит при проектировании. В NoSQL системах этот вопрос определяет сет ключевых полей.
А распухнет база или засохнет - вообще сейчас не имеет значения.
Анонимос дело говорит. Дружище автор а что это у тебя слеши смотрят не в ту сторону. Поверни их как
положено. И покажи определение этого загадочного "list".
И мой вопрос про текст ошибки - по прежнему актуален.
neil_arms, быстрый ответ - почисти таблицу и обнули sequence объект.
Более длинный ответ заставит меня разбирать какой ORM ты используешь. Как была создана таблица на самом деле (мне нужен оригинальный SQL) и как работает Postgres с автоинкрементными полями. В оракле например были варианты использовать отдельно sequence объекты.
В аттачменте приведено 95 координат. Нужно построить матрицу расстояний. Тоесть будет квадрат 95 на 95 ячеек. В каждой ячейке - расстояние.
Расстояние посчитаем сначала в градусах. По теореме Пифагора. Вот это расстояние будет метрикой
стоимости пути в алгоритме Дейкстры или в любом другом алгоритме.
Потом градусы можно перевести в километры. Для экваториальных измерений там обычно
1 градус был равен 111 километров. Для измерений ближе к полюсам там соотв надо делать поправку.
Впрочем для автора такое искривление возможно безразлично.
Я по натуре не согласен с такой постановкой. Мы не учитываем длину по дорогам. Эта длина
слабо коррелирует с координатами. Все знают что такое пробки, окружные трассы, плохие
грунтовые дороги и погодные условия.
Ну да ладно. Автор. Дай нам пример тестовых данных (хотя-бы штук 100 координат).
Есть наверное несколько путей как это сделать.
Один путь
SELECT f1,f2 ...
UNION
SELECT f1,f2 ...
присоединить сбоку значение из первой и второй
Еще вариант сделать JOIN по ключам f1,f2 (при условии что у нас есть точное совпадение комбинаций ключей). SELECT .... JOIN ... ON ...
Все остальное - детализация
Сомнительно что кто-то подарит тебе хостинг и канал бесплатно. Амазон и Microsoft дарили
студентам облачные демо-версии аккаунта на 30 или на 60 дней. После которого можно было
либо отказаться от использования либо начать платить. Да и студенты использовали такое
очень слабо. В основном для своих курсовых работ или каких-то пет-проектов. Но там точно
не было продуктовой нагрузки. Кроме того у AWS была просто нулевая поддержка для такого
аккаунта. Грубо говоря если у тебя что-то не работает с EC2 то писать в саппорт бесполезно
пока ты не покажешь доказательство своей оплаты.
Бесплатным услугам от cloudflare я-бы тоже не доверял. Ты думаешь что его используешь а он
на самом деле твои файлы будет коллектить использовать твои данные в биг-дате как хочет.
Не удивляйся если твои фото где-то всплывут. Читай мелким шрифтом короче все агрименты.
dmshar, ну про счетчики по модулю 2 это я точно не про Python писал. Это скорее про С++, Rust.
Python - конечно интересный но зело нетипизированный и жадный до мемори.
