d'Ivan

Github использует ключи ровно для того же, для чего их использует ssh - они заменяют доступ по логину/паролю.

Больше никакой разницы нет.

https://stackoverflow.com/a/31175038
sqlite3.exe test.db "select * from abc;" ".exit"

UPDATE `product1` AS `p1`
  JOIN `product2` AS `p2` ON `p2`.`product_id` = `p1`.`product_id`
  SET `p1`.`Status` = `p2`.`Status`

Еще например вот так можно

type FReader struct {
	reader io.Reader
	filter func([]byte) (int, error)
}
func NewFReader(r io.Reader) *FReader {
	return &FReader{r, func(p []byte) (int, error) { return len(p), nil }}
}
func (fr *FReader) Filter(filter func([]byte) (int, error)) *FReader {
	return &FReader{fr, filter}
}
func (fr *FReader) Read(p []byte) (n int, err error) {
	n, err = fr.reader.Read(p)
	if err == nil && fr.filter != nil {
		n, err = fr.filter(p)
	}
	return
}

тогда можно написать

chainreader := NewFReader(myreader).Filter(myfilter1).Filter(myfilter2).Filter(myfilter3)

https://play.golang.org/p/rakSV5kgqR9

https://m.habr.com/ru/company/microsoft/blog/416449/

Есть паттерн Worker Pool, пример можете посмотреть здесь: https://gobyexample.com/worker-pools

Вообще, нужно взять бумажку и задать на высшем уровне абстракции все возможные в текущем представлении сущности. Если разговор о "змейке" - задаете вопрос, что у вас в игре есть как сущности. Скажем, есть змея, есть стены, есть жрачка, их пишете как сущности. Затеяли добавить "муху" - пишете тоже. Затем пишете, кто что умеет делать: змея умеет ползать, стукаться в стены или жрачку, расти и возможно что-нибудь ещё, стены просто стоят, жрачка умеет появляться, съедаться. И так далее, пока всю игру в примитивах не опишете. Дальше - каждая сущность это класс, каждое отношение это метод, каждый параметр, выясненный в процессе, это свойство класса. Но чем дальше в лес, тем больше грабли. На уровнях выше начинаются модули со своей инкапсуляцией, события, гонки всякие, а-ля "кто съел яблоко, вы или противник", асинхронное взаимодействие, подписки на что-либо, и так далее, интерфейсы становятся сложнее, какие-то объекты передаются как параметры и всё такое, но общий принцип остается - сначала большими кусками всё делится на куски поменьше, определяются интерфейсы (кто что может спросить или повлиять на кого), пытается реализовываться, потом, вполне возможно, находятся противоречия, которые приходится устранять рефакторингом, и по спирали.

Что поизучать - сначала просто базовое ООП, чтобы понять, из чего вообще строить программу, что такое объект, класс, интерфейс, наследование, полиморфизм (та же жрачка может быть нескольких видов, например, но "съедается" она одинаковым образом), инкапсуляция (а-ля "не лезь в мои свойства своими лапами"). Все эти SOLID и прочие аббревиатуры, а также паттерны и антипаттерны, появятся в процессе, когда от архитектуры перейдете к дизайну самих сущностей и написанию кода методов. По-моему так.

Все дело в том что utf8mb4_unicode_ci использует 4 байта для кодирования одного символа, плюс 1 байт хранит длину строки. Соответственно (255+1)*4 = 1024.
Уменьшит размер данных можно, и даже нужно, с учетом что текущие данные не будут повреждены. Проверить максимальную длину строки:
SELECT MAX(fieldname) FROM table;

Выбор размера данных зависит от их возможных значений. Например если поле может быть только "да", "нет" , "иногда" то достаточно varchar(6)

Кроме того если строковое поле имеет ограниченный набор значений имеет смысл использовать enum или отдельную таблицу со словарем

Вам нужен std::map или std::unordered_map. Самому писать структуру данных не надо.

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

В качестве ключа используйте пару {Тип транспорта, номер маршрута}. В качестве значения - счетчик остановок.

Еще вам нужен еще один map из тип транспорта-> std::set или std::unordered_set номеров маршрутов.

Для построения структур один раз приходитесь по всем остановкам и увеличивайте счетчик в первой структуре. Добавляйте маршрут к транспорту во второй структуре.

Для поиска ответа пройдитесь циклом по всем элементам set из второго map - это все маршруты. Смотрите в первом map'е сколько остановок у этого маршрута и выбирайте максимум.