В этой задаче всё нормально и никаких видимых проблем нету. Обычно индекс работает синхронно с обновлением основной таблицы (кроме редких типов индексов основанных на текстовом поиске).
Единственное что здесь избыточно так это сам ключ. '328382164-audi-a4-2012-blue-WВA2UAF48H38K007347'
его копия будет лежать и в таблице и в индексе. Я-бы поискал какие-то закономерности.
Если вся таблица созавалась под audi - то стоит-ли держать еще признак рядом?
Если бы база была класса Oracle и ключ - композитный то я-бы разбил его на два-три подключа
и использовал-бы compressed index. Тогда марки машин можно было сжать и уменьшить объем индекса.
Практически эта задача звучит так. Создать копию файла с изменённой строкой. Такой подход к изменению текстовых файлов во всех языках и системах программирования.
Топик тегирован "Базами Данных". Какими - чорт его знает.
Поэтому есть следующие коробочные решения. Cassandra, Redis, Amazon DynamoDb. Все они поддерживают дополнительное поле TTL и удаляют записи автоматически без участия разработчика.
По поводу подводных камней о которых пишет автор. Это всё очень плохо и почти не работает в боевых условиях. Пока бэкап данных делается в обычном плановом режиме - никто не знает о существовании всяких там левых файлов на сервере приложений. Грубо говоря все думают что состояние системы (state) лежит в базе и только в базе. Поэтому попытка размазать состояние системы по нескольким нодам вычислительной сети приводит к сложным и трудноуловимым последствиям.
Какой бизнес-смысл этих ограничений? Если поле массива должно хранить возраст человека (условно от 0 до 120 лет) то тогда надо создать свой тип (класс) и создавать типизированный массив.
А я вообще не понял почему автор "ударил лицом" в грязь. Разве речь шла о хакатонах или олимпиадах.
Вообще в ентерпрайзе например нет таких оценок времени. Задача которая делается за 10 минут - скорее всего никому не нужна. Задача должна быть обдумана. Покрыта тестами. Покрыта code-review.
Мой шеф говорил - "задача должна настояться". Я-бы голосовал 1 StoryPoint. Или один день разработки. А то что "подруга" решала за 5 минут - было похоже на троллинг молодого кавалера или развод на слабо. Зачем вообще вестись на такое?
Непонятно какого рода acceptance criteria здесь можно применить. Если ИИ нашел что картинка состоит из синего фона то является ли это решением? Хотя по факту вы фоткали морской горизонт. И если в море был виден парусник - то как ИИ должен был его описать?
ИИ с синим фоном и я могу сделать. Нехитрое дело... Усредненный цвет.
Если у вас d не равно 1 тогда возникает flow который приводит к matrix которая не аллоцирована.
Кстати вы используете не матрицу а так называемый Jagged Array (зубастый массив). В этом нет смысла т.к. у вас матрица всегда прямоугольная и рациональнее выделить один большой массив и распределять его ячейки как элементы прямоугольной матрицы (i,j) формула смещения - очень простая. Ширину умножить на один индекс плюс второй.
Я-бы делал так
float* matrix = new float[n * m]
ну и формулы доступа дальше подправить надо соотвественоо.
Я думаю что скорость современных адаптеров Wifi (5G/900Mb) будет лучше чем 10 мегабит по коаксиалу.
По поводу дома. Вы говорите что внутри - видимость плохая. Попробуйте повесить пару адаптеров снаружи дома так чтобы из них можно было собрать схему "bridge". Или один адаптер в доме а другой снаружи. Вобщем разные варианты. При этом к интернету будет подключен только один а другой в роли репитера.
Да. Корректно. Но если вы не пользуетесь билдером то вам придется вручную отслеживать открывающие и закрывающие скобки в тек местах где есть приоритет и вручную форматировать отступы и переносы если есть такое требование. Тоесть в какой-то момент времени сложность кодогенерации перейдет с билдера в ваш рукотворный код и вам эту сложность также придется поддерживать и объяснять ее происхождение коллегам.
Кстати на каком языке вы разрабатываете? Для Java есть готовые билдеры в QueryDSL, JooQ.
Понимать сложность алгоритмов - сложно. В общем случае глядя на исходних достаточно трудно сказать какое там o(n). Особенно если есть рекурсии и предикаты которые срабатывают с вероятностью которую мы не знаем.
Вообще, нарабатывая опыт. Например обход элементов квадратной матрицы имеет квадратичную стоимость а обход куба - кубическую. Это из простого. Шаблоны дихотомического поиска почти всегда содержат в основе своей формулы логарифм по основанию 2. И комбинаторные алгоритмы (сочетания и перестановки) - практически всегда содержат в своей основе n под факториалом.
Кстати если формула содержит суперпозицию факториала и полинома - то полином можно выкинуть. Т.к. в сравнении пределов факториал улетает в бесконечность быстрее и соотв. решение зависит только от факториала.
Я не очень понимаю зачем для собеседования знать оценку неизвестных алгоримов. Я прошел не один десяток интервью и меня никогда никто не просил оценить сложность неизвестного алгоритма.
По поводу Дональда Кнута. Ничего он не поймет. Кнут писал 40 лет назад. Писал про железо которого уже не существует (ленточные накопители) и продавливал свои идеи алгоритмизации на ограниченном числе ресурсов. Кнут просто издевается над современным читателем имеющим ноутбук и смартфон тем фактом что заставляет изучать несуществующий компьютер MMIX (это такая себе машинка-калькулятор вроде Феликса или Энигмы, такие вот у меня ассоциации) и под него-же писать и читать код. Ну кому это надо!
Сегодня я снимаю шляпу перед тем трудом который он сотворил. Но если студент хочет ПРОСТО освоить тему оценок сложностей алгоритмов то можно взять что-то более быстрое и эффективное. Вирт. Седжвик. Даже Кормен.
Для жлобских ноутбуков можно попробовать поставить Linux с десктопом XFCE (Xubuntu). Там 8 для ОС надо.
По поводу чистки - полностью согласен. Часто бывает что лежит хлам который годами не нужен. Апдейты. Софт который не был корректно удалён. Я сам этим грешил. Вобщем надо просто критически посмотреть что вообще за файлы там лежат. Может рука дрогнула и телесериал был залит случайно в \windows.
Скорее всего прямой формулы не существует. Есть сравниительные подходы. Тоесть к примеру вы знаете уже такую конфигурацию которая "держит" 10 млн запросов. Вот смотрите как она реализована. Скорее всего это не один сервис а целый грид сервисов которые географически разбалансированы так чтобы каждая нода брала на себя часть нагрузки.
Почему в подобного рода задачах нельзя создать формулу? Ну формула - это скорее всего иммитационное моделирование всех уровней вашей системы в том числе сетевого стека и пользователей. По сложности эта модель близка к разработке самой системы. Поэтому я думаю что такой подход вам не нужен. Да и мало кому вообще нужен. Разве что атомный взрыв так моделируют.
Для оптимизации загрузки landing page, можно хранить копии этой картинки в уменьшенном виде. 2000х1000 => 1000x500 => 500x250 e.t.c. Так игроделы делают для быстрого рендеринга текстур. Mip-уровни кажется называется.
Обновлять эти mip уровни можно не спеша. Через минутку.
База mysql вам вобщем-то не нужна. Картинку можно в реальном времени править atomic операциями и хранить в raw формате. Не знаю делают ли такое на PHP. Возможно вам нужен рукастый програмист на C++ или еще на каком-то языке чтобы подружить PHP с С++ и сделать сервис для этой картинки.
Можно попробовать сделать 2 фото. Одну во время дождя. А другую в ясную погоду. Со штатива и не двигая между снимками. Потом попробовать сравнить 2 фотки и посмотреть какие артефакты дает дождь.
Да и в данном вопросе есть два "хитрых" смысла. Есть художественный смысл. Типа улучшить фото. Этим занимаются художники. И есть смысл информационный. Например понять какой номер машины был замечен в плохую погоду и попытаться его распознать. Вот этот второй смысл - он про другое и к убиранию дождя не имеет отношения. Я-бы сказал что для систем машинного зрения лучше вообще дождь не фильтовать а сразу давать сырое на вход. Это более честно.
Я-бы предложил нарисовать граф зависимостей. Картинку со стрелками кто от чего зависит.
И дальше раскидать софт по железкам так чтобы при выходе из строя железки упало по минимуму
зависимых сервисов.
Вот нарисовать такой граф я не могу. Это наверное автор может.
try-catch - это эволюционно развитый if-else. Вот те кто кодили на "C" знают как тяжело работать с файловыми операциями. Любой fopen,fread e.t.c. надо проверять на код возврата и обеспечивать аварийный выход с очисткой (!) всех ресурсов. И вот отслеживание всех ресурсов и их состояний это нетривиальная задача. Для этого создали try-with-resources. И вообще возврат в это тяжелое мракобесное время проверок errorcode - никому не советую.
В случае с делением на 0 (ArithmeticException). Если вы рисуете на экране график функции - то возможна ситуация
где будет много делений на нуль. Тогда обработка исключений может стать performance issue. Это правда.
Может помочь декомпозиция формулы с делением на результат с Option[Int] (в Scala и Java это уже рабоатет) и возвращать неопределенное значение None в случае когда в знаменателе стоит ноль. Вообще в языках ФП данный подход очень рекомендуется т.к. в этих языках есть синтаксический сахар для быстрого сворачивания (flatMap) списков таких опциональных значений.
Тоесть если вы из функции хотите вернуть пустоту - то возвращаете None вместо бросания прикладных исключений.