Михаил Р.

Вы выделили в системе два класса сущностей. Одна - Пользователь, вторая - Роль.
Под каждый класс нужна отдельная таблица.
Как определить какие взаимоотношения между этими классами?
Нужно примерить следующие коммутативные гипотезы:
Первая пара гипотез:
"Один пользователь должен (может) иметь только одну роль."
"Одна роль должна (может) быть назначена многим пользователям."
Вторая пара гипотез:
"Один пользователь должен (может) иметь несколько ролей."
"Одна роль должна (может) быть назначена многим пользователям."
Если в вашей архитектуре системы справедлива первая пара гипотез, то вы строите взаимоотношение между классами Роль и Пользователь как "один ко многим". Это значит, что у таблицы Пользователь будет внешний ключ в виде идентификатора роли, тем самым вы каждому пользователю сможете назначить только одну роль. Но сами роли могут повторятся у разных пользователей.
Если в вашей архитектуре системы справедлива вторая пара гипотез, то вы строите взаимоотношение между классами Роль и Пользователь как "многим ко многим". Для этого нужно создать промежуточную таблицу, например Пользователь_и_роль, в которой будут два внешних ключа - идентификатор пользователя и идентификатор роли пользователя (можно, но технически нужно еще создать еще идентификатор первичного ключа, чтобы можно было корректно обращаться к записям этой таблицы, не путая их). В этом случае каждому пользователю можно выделить целый набор ролей, не ограничиваясь одной ролью.

Как вообще задавать фикс значения используя бутстрап?

Никак, он не для этого.

Создавать свой класс? Нормально ли вообще создавать свой класс и юзать его в перемешку с версткой на bootstrap?

Да, создавать, да, нормально.

Если да, то как организовывать такие классы в файловой структуре, ведь они будут созданы только в том случае, если возможностей бустрапа не хватит.

Добавляете файл /assets/css/style.css, подключаете после бутстрап.

Так ведь есть-же опция изменения заголовка --header, воспользуйтесь.
То бишь

curl --header "Host: sample-host-name.org" "http://1.2.3.4/index.html"

Посмотрите на highscalability.com/blog/category/example - там есть разбор реальных архитектур. Tilda там нет, но есть например Wix - правда в эпоху до Docker. Но принципы те же.

1. Из коробки компилируется в единственный, сравнительно компактный, бинарь без зависимостей от рантайма и окружения.
(и без подводных, в отличие от full aot и assembly trimming)

2. Сможешь рассматривать вакансии, где требуется Golang, если собираешься искать работу.
3. Сможешь нанимать go-шников со всеми вытекающими, если будешь искать разрабов в свой проект.
4. Если твой проект должен будет активно взаимодействовать, например, с kubernetes и прочими devops-штуками, то Go может быть чуть удобнее, тк практически все эти инструменты написаны на Go и для работы с ними имеются готовые библиотеки, которые, вероятно, будут лучше, чем их альтернативы для .NET.

1. На десктопе рулят события мыши: mousedown - эквивалент touchstart, mousemove - эквивалент touchmove, mouseup - эквивалент touchend.
2. Вместо множества точек касаний (пальцы) у вас одна точка - курсор мыши, поэтому свойства changedTouches в объекте события не будет.
3. Тестировать, что окружение браузера имеет сенсорный экран, можно проверкой наличием доступного свойства любого события touch в window:

if("touchstart" in window)
{
  // работаем с сенсорными обработчиками
}
else
{
  // работаем с мышиными обработчиками
}

4. Событие завершения управления элементом (touchend, mouseup) лучше вешать не на сам элемент item, а на его контейнер, который будет занимать всю ширину экрана (идеально, если это будет body). Логика обработки может застрять на обработчике move, если во время движения точка воздействия на объект убежит за пределы объекта.
В определенных случаях могут выручить события mouseover/mouseout.

aiogram - это маленький и примитивный фреймворк сам по себе. Для его изучения достаточно прочесть документацию. Но до этого надо изучить Python, asyncio, принципы работы сетей в целом и протокола http в частности, желательно базы данных, чтобы хранить состояние, алгоритмы, вроде конечного автомата, чтобы управлять состоянием, совсем хорошо ещë и понимать Linux, ведь на каком-то сервере вашему ПО надо будет работать.

Зачем продают OEM-процессоры и рискованно ли покупать их?

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

Например DNS может себе купить оптом много этих процессоров для собственных сборок, а излишек продать в розницу с небольшим дисконтом, по сравнению с BOX. При этом гарантия продавца будет по сути такая же.

И нет, риски крайне малы (не больше, чем при покупке боксовых), если покупать у нормального продавца.

Боксовый кулер мне не нужен

А его сейчас в BOX и не кладут практически :)

родная гарантия тоже особо не нужна

У OEM процессоров гарантия ровно такая же, как и у BOX.

Из-за чего они появляются и могут ли они быть хуже, чем боксовые?

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

На фото лотки от райзена, но для интела примерно что-то похожее.