Давай свой код который написал. Может не я а кто - другой
поможет. Хадуп это вообще метафора. И информации нам с
этого в топике никакой нету. Все равно что сказаь что нюанас -
это Java.
maksam07, выж дотнетчики умеете CLR код смотреть? Вот посмотрите что там внутри.
Многие компилляторы в режиме релиза убирают все промежуточные переменные.
Проверте. А то до конца жизни будете ходить в заблуждениях.
Тут приложение борет проблему которая высосана из пальца. Само по себе сложение - длинных целых - это
очень простой алгоритм.
А вот эта форма хранения чисел - это какая-то чепуха и несуразца.
Вот твой пример.
Например: число 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 координат).
Давай свой код который написал. Может не я а кто - другой
поможет. Хадуп это вообще метафора. И информации нам с
этого в топике никакой нету. Все равно что сказаь что нюанас -
это Java.