Владимир Коротенко, проблема - как всегда в людях. Люди - дорого стоят. Найти хорошего девопса чтоб знал Постгре и умел написать баш-скрипты - проблема. Еще проблема - доказать что придуманная только что на коленке технология бэкапа вообще позволит восстановиться. Или восстановиться по состоянию на какую-то точку.
А мы живем в эпоху облаков. Одним мышко-кликом можно поднять хоть оракл хоть mysql. Проблемы ограничений софта уже давно нет. А ограничения людей остались.
На самом деле я - не против хранения музыки на диске. Пускай автор хранит.
Владимир Коротенко, можно по разному на это смотреть. Я-бы смотрел сквозь ценность информации для backup. Вам нужно точно-точно сохранить все? На военном уровне надежности? Или потеря парочки файлов - это нормас. В разных dbms это борют по разному. В Oracle прошла целая эпоха эволюций от raw до специальных опций типа Oracle Securefile которые удешевляют доступ и снимают нагрузку с тела таблиц.
Станислав, это не то что я хотел. Я хотел взять курсор из БД и на уровне SQL решить 50% проблемы. И потом на уровне GoLang + JSON/Serializer/Marshaller решить вторые 50%.
Ты опубликовал то что мне никак не помогает. Я - не специалист в Go. Прошу извинить. Но я собаку съел на базах данных и на экспорте в бигдату и JSON-конверсиях.
Предположительно зависит от качества эфира во время связи по Wifi. У одного из компов - антена или адаптер слабее - и он фиксирует больше ошибок и повторов. Тоесть если ты соединился на скорости 150/300/900Mbit это еще не факт что будешь фактически получать данные так-же.
Вообще, если надо читать то нет никакой разницы по использованию памяти какого размера файл нам нужно открыть, если нет необходимости его весь держать в памяти.
Это из личного опыта. Пользователи и админы любят открывать логи не грепом а текстовым редактором.
Кроме того гранулярность по времени даст вам возможность более точно сужать область поиска.
Ну... можно создать таблицу с авто-инкрементным полем id.
Потом вставить в нее 1 строку.
Потом скопировать таблицу саму в себя.
Тут будет еще двоичный логарим копирований от 100500 ... эээ это где-то ... чуть меньше чем 128Кил... короче 17 раз надо копировать.
Вот. А потом в конце одним update-ом обновить поле hash как хеш-функция от id.
Как хеши делать в MySQL я не помню. Но это справочная инфа.
Со второй таблицей наверное также. Теже самые действия.
Непонятно почему в 21 веке нужно писать кастомные парсеры для CSV.
Это тыщу раз решенная задача. Имеется текстовый файл с разделителями. В данном случае - с пробелами.
Ну а вещественное число с запятой рассматривать уже отдельно как региональные преференции.
#define если if
#define длявсех for
#define аиначе else
#define ДЫРКА NULL
UPD. В этой инициативе нет ничего нового. Копмилляторы с одного на другое назывались кажется
толи кросс-компилляторы толи транс-пилляторы неважно. У тебя по сути задача решается
реплейсментом исходного кода. Только надо делать не тупой реплейсмент а хотя-бы не трогать
строковые литералы.
Я думаю что мы окажем медвежью услугу если дадим линки на GCC, clang. Это реализации компилляторов. И они сложны как вселенная. Но было-бы невежливо ничего не дать.
Тут пишем Spring а подразумеваем Hibernate. Я думаю что для Java - безразлично. Можно ссылку ставить куда угодно. Но для ORM движка и для механики Serializable - я-бы проверил не приводит ли это к зацикленности и ошибкам при работе persist/save. И я-бы попробовал null вместо ссылки на самого себя.
(Очень плохо конечно что ты ради секретности придумал имя Test. Это сильно сбивает с толку.)
pinkhead_psd, не думайте сейчас о накладных расходах. Просто попробуйте написать рекурсивный обход Б-дерева. И если он будет успешным (без ошибок) и без stack overflow - то тогда попробуйте декомпозировать в решение на базе цикла.
Но мой опыт подказывает что 80% разработки на этом завершаются. Всегда технически проще подрегулировать размер стека (для Java там есть отдельный параметр) чем платить программисту сотни и тысячи зелени за размотку рекурсии в цикл со структурой типа Deque.
В наше время - самый дорогой ресурс - это вовлеченность специалиста в задачу. Вот честно. Все стало дешево. Диски. Память. Вычислительные ноды. Как грязи всего много. А людей не хватает. И денег на оплату синьоров не хватает.
pinkhead_psd, еще рекурсия очень важна при описании различного рода грамматик. Такие технологии как BNF/EBNF, yacc, bizon, antlr e.t.c. - это все описательные языки которые объявляют какой-то синтаксис. Например синтаксис S-expressions или JSON может быть описан десятком строк описания грамматики на EBNF.
Есть описательные рекурсивные техники для рекурсивных структур данных. Например узел бинарного дерева описывается как Нода у которой есть две ссылки на такие-же Ноды. Это поддерживается даже в языке С.
pinkhead_psd, стек не обязательно должен быть использован в рекурсивной функции. Существуют технологии т.н. хвостовой рекурсии где ты описываешь функцию рекурсивно а компиллятор ее разворачивает в цикл. Но это не все компилляторы поддерживают. И сама функция должна подойти под критерии.
Есть техники описания т.н. генераторов последовательностей. Например список чисел Фибоначчи. Эти генераторы тоже имеют вид рекурсивных функций. Но при этом стек им не нужен. Они - ближе к итераторам по своей природе.
А мы живем в эпоху облаков. Одним мышко-кликом можно поднять хоть оракл хоть mysql. Проблемы ограничений софта уже давно нет. А ограничения людей остались.
На самом деле я - не против хранения музыки на диске. Пускай автор хранит.