Василий Банников

SELECT number FROM login_id WHERE id = ?
Вместо знака вопроса подставляй значение переменной user_id так, как это рекомендует та библиотека, которой ты пользуешься

Запрос должен вернуть 0 строк, если записей с таким id нет.
Если такая запись есть, то вернёт одну строку с единственным столбцом - значением колонки number в этой строке.
Проверить значение уже можешь на питоне.

Маркер чтобы туда тип записать

Редирект нужен только для того, чтобы ты мог в своём магазине показать весёлую картинку, что всё пришло успешно.

Редирект кто угодно может подделать.

1. Нельзя опираться только лишь редирект. Запрещаю.
2. Банк также отдельно может дёргать какой-нибудь вебхук на твоей стороне.
3. Ты сам можешь периодически проверять статус платежа через API банка.

За подробностями обращайся к документации твоего банка.

Сейчас даже открыл документацию юкассы и там перед показом весёлой картинки идёт шаг:

Шаг 4. Дождитесь успешного завершения платежа: подождите, когда придет уведомление от ЮKassa, или периодически отправляйте запросы, чтобы получить информацию о платеже

Потому что label должен стоять около какого-нибудь выражения.
Если выражения нет - это на самом деле return, а не goto

(я не только корректность схемы тут рассматриваю)
Вроде всё ок, только видно некоторое дублирование данных в пациенте и сотруднике.

Можно (не обязательно) попробовать ввести сущность "человек" (название черновое), у которого будет информация о паспорте, имени, и прочем.
И пусть пациент/сотрудник ссылается на него.

Можно так достаточно интересную связь сделать, когда один и тот же человек является одновременно и сотрудником и пациентом. (И например ввести запрет на выписывание лекарств самому себе)

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

Таблица с лекартсвами выглядит как справочник, тк никаких связей с другими таблицами не имеет.

Возможно, есть смысл ввести ещё справочник действующих веществ, чтобы можно было быстрее искать конкретные лекарства по этому действующему веществу.

Можно попытаться формализовать планы лечения - но это отдельная очень большая задача.

К таблице с адресами ещё есть смысл добавить номер ФИАС/КЛАДР/ГАР (уже запутался в этих системах) - это распространённая практика в России.

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

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

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

Также не понятно, почему позиция жёстко привязана к отделу.
Кажется, есть смысл ввести отдельно таблицу для позиций (в оргструктуре) и должностей (специализации и грейды врачей)
+ Часто оргструктуры имеют древовидную форму с отделами/подотделами/филиалами
+ Часто есть деление на юридическую структуру (которая записывается во всяких юридически значимых документах) и ресурсную оргструктуры, которая описывает реальный бизнес-процесс.

Вместо флага is_doctor в позиции следует всётаки какой-нибудь enum сделать, ибо потом захочется делить сотрудников на более чем две категории.

Лучше сделай резервные копии важных файлов и установи начисто.

Какой тип у ProductId? Если это Guid, то смотри какие у него конструкторы есть.
Проще всего через Guid.Parse.

PS:
А DbContext мокать не нужно. Используй вместо этого EF Core inmemory, либо Sqlite с размещением в оперативной памяти.

Будет что-то типа:

var conn = new SqliteConnection("DataSource=:memory:");
var options = new DbContextOptionsBuilder<ApplicationContext>()
   .UseSqlite(conn)
   .Options;

using var dbContext = new ApplicationContext(options);
dbContext.Products.Add(new Product { /*...*/});
dbContext.SaveChanges();

var controller = new CartController(dbContext);
// ...

PPS:
Если ты хочешь тестировать контроллеры - значит ты что-то делаешь не так. Возможны два варианта:

1. Ты наговнокодил и затолкал бизнес-логику в контроллеры.
Если так, то выноси логику в сервисы и делай так, чтобы контроллер зависел от сервисов.

2. Тебе на самом деле нужны интеграционные / api-тесты / e2e-тесты. В таком случае тебе нужно не контроллер конструировать, а поднимать сервер и тестировать при помощи http-запросов. В таком случае следует ещё и по пути полноценную СУБД поднимать, а не мок.

Попробуй установить отдельно через android studio