Да. Корректно. Но если вы не пользуетесь билдером то вам придется вручную отслеживать открывающие и закрывающие скобки в тек местах где есть приоритет и вручную форматировать отступы и переносы если есть такое требование. Тоесть в какой-то момент времени сложность кодогенерации перейдет с билдера в ваш рукотворный код и вам эту сложность также придется поддерживать и объяснять ее происхождение коллегам.
Кстати на каком языке вы разрабатываете? Для Java есть готовые билдеры в QueryDSL, JooQ.
Скорее всего нет т.к identifiers всегда начинаются не с цифр. Это старое правило. Ему уже пол-века и оно действует не только в pg но и Oracle и во многих языках трансляторах.
Реляционная алгебра практически не умеет оперировать горизонтальными коллекциями. Такова она есть. И SQL создавался для других дел.
Самое правильное что можно сделать - создать временную табличку. Слить туда твои массивы с разворотом в 90 градусов и выполнить простейший (! реально простейший!) запрос с группировкой.
Это решение будет идеологически правильней, чем нагружать SQL не-свойственными ему задачами.
Зависит от ценности этой информации. Если эту схему рассматривать как историю - то ничего удалять не надо. Просто перепишите ваши отчоты чтоб они делали GROUP BY и DISTINCT и просто игнорировали дубли.
Если вы - владелец этой системы и данных - то вы вправе поставить любой констрейнт уникальности так чтобы дубль в принципе невозможно было всунуть. Но это вопрос не технический а организационный.
Удалять - советчиков много. Но все они - безотвественные и если вам не стоит слушать советов по чистке данных именно здесь в тостере то вы рискуете какраз потерять нужные данные.
Такая конфигурация не имеет право называться базой данных. Присоединяюсь ко всем ораторам. Просто добавлю что портативное устройство должно писать логи операций. Чтобы выполнять разбор полетов и фиксировать что делалось. Можно с ротацией. А база данных должна лежать отдельно. На надежных удаленных серверах.
MySQL - это не совсем DBMS. Это сборный лего-конструктор в котором каждая таблица в отдельности сама определяет свой уровень отказоустойчивости (т.н. engine). Поэтому обсуждать надёжность MySQL нет смысла без обсуждения того как была создана каждая таблица. In general - про надёжность сказать ничего невозможно.
Данная задача не решается в рамках CrudRepository.
Архитектурно. Для крупных систем если кто-то хочет искать произвольный текст (fuzzy text search) по вводимому выражению наподобие гугло-поиска специально подключается Apache Lucene или ELK stack. В него реплицируется искомая табличка и далее уже по этой реплике выполняются все текстовые сёрчи.
Все что вы сейчас наделаете в рамках классической реляционной алгебры будет работать медленно и плохо ибо реляционная алгебра не создавалась вообще для подобных нечетких поисков.
