rPman

На каждую таблицу будет заводиться индекс PK, если количество записей будет одинаковое (в смысле на каждое значение PK будет по одной записи в каждой таблице) - будет хуже, так как размер индекса у каждой таблице растет с ростом количества записей в ней, и много таблиц - много по факту отдинаковых индексов (но для разных таблиц он хранится), поэтому разделять по мелким узким таблицам имеет смысл только для разряженных данных, когда записи появляются только при наличии данных, причем чем больше таких отдельных таблиц тем больше должна быть 'разряженность' данных, чтобы это имело смысл.

Так как объем ПЗУ значительно выше (при той же стоимости) чем ОЗУ (а требования к ней таковы что индексы желательны влезать в нее, хотя бы для оперативных запросов) то лучше забить на оптимизацию по занимаемому месту данными, чем увеличить кратно требования для оперативного хранения индексов.

Поэтому - не дроби на большое количество таблиц, пусть будет меньше таблиц с большим количеством полей, но без фанатизма, если видишь что появляется куча условий not null когда как для нескольких таблиц это отрабатывается inner join, то тогда да (not exists лучше чем is null).

p.s. в догонку про сериализацию данных в одно поле, когда одно поле БД хранит сразу несколько значений - это оправдано и даже рекомендуется, если эти данные не имеют смысл по отдельности, красивый пример ip-адрес и порт как настройки подключения - суть одни данные, и нет никакого смысла разделять их на разные поля базы, за исключением случаев когда возможно потребуется активная аналитика по отдельному полю (например по ip адресу) - 'активная' тут это значит нужно строить индексы и делать частые запросы а не разовый full scan бакэндом.

Дробление данных на большое количество полей - повышает нагрузку на бакэнд (спорное утверждение, бывает наоборот, но зачастую да), правда для тех разработчиков, где такая оптимизация имеет смысл, такими вопросами не задаются, нужны действительно большие нагрузки.

Администратор БД это тот кто следит за работой базы, раздает и управляет правами доступа пользователей, настраивает размещение tablespace, настройка репликации и резеврной копии и т.п.

Если администратор БД часть команды разработчика приложения (это важное дополнение) то на него обычно ложится все что касается оптимизации скорости (проектирование индексов и вообще участие в проектировании базы данных). Абсолютно бессмысленно просить словами администратора создать/удалить таблицу, но прежде чем что либо в базе делать, лучше обсудить, особенно если это все на продакшн базе будет происходить, так как когда размер базы большой, простейшее добавление или удаление колонки (например если там есть default value) может занимать сутки-недели.

Написание триггеров, хранимых процедур и представлений - это не дело администратора БД но очень часто он совмещает функцию разработчика БД (само собой об этом нужно заранее договариваться) и это становится само собой разумеющимся.

везде одинаково:

return - выход из функции/метода
break - выход из switch для выбранных секций case
goto - выход на метку (только в пределах метода), можно использовать как выход из многоуровневого цикла без определения переменных состояний, но вообще плохой тон

Хранение блобов в файле программы (оно будет мапиться на адресное пространство и читаться эффективнее fread) в .data секции, создать объектные файлы с помощью objcopy или генерировать константы массивов с 0xXX с помощью xdd

https://caiorss.github.io/C-Cpp-Notes/resources-ex...

Почти все нормальные криптовалюты имеют кошелек с api (часто rpc) по работе с ним.
Так же для облегчения веса в мегабайтах результата, пользуются (часто неофициальными) библиотеками.
Для криптовалют с поддержкой контрактов бывают особенности реализации, так же надстройки меняют картину, например lightning network требует отдельный кошелек/демон lnd когда как обычные переводы bitcoin можно делать только офф кошельком.

гуглить: имя твоей криптовалюты + имя языка программирования + library + опционально название/версия контракта