smilingcheater

У команды init достаточно большой перечень опций, так что можно в саму команду прописать все дефолтные значения, и каждый последующий проект инициализировать ею:

composer init --name='gordinskiy/new_package' \
    --description='Project description' \
    --type='library' \
    --author='Dmitriy Gordinskiy' \
    --license='MIT' \
    --require='php:>=8.2' \
    --require='webmozart/assert:^1.11' \
    --require-dev='phpunit/phpunit:^10.3' \
    --require-dev='vimeo/psalm:^5.11' \
    --require-dev='phpstan/phpstan:^1.10'

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

Какую конкретно? Ту, которую лучше знаешь, если не можешь назвать конкретную причину, почему лучше изучить другую и взять другую. Например вот я беру postgres по-умолчанию, но вот у меня проект, который требует минимального жора ресурсов и наиболее простой инфраструктуры - тогда беру sqlite.
Или наоборот - я понимаю, что у меня какие-то специфичные требования по консистентности и доступности, система у меня будет распределённая, а запросы у меня будут исключительно key-value, да и желательно ещё иметь возможность подписки на изменения каких-то ключей - тогда беру etcd.

Не спрашивайте у чатжпт ничего, в чем не являетесь полным экспертом. Он почти в половине случаев выдает очень правдоподобный бред.

У этого алгоритма действительно пространственная сложность O(N) (если N - размер входного массива). Однако, можно натянуть сову на глобус, если отдельно считать входные и выходные данные (которых O(N)). Тогда можно сказать, что алгоритм использует O(1) дополнительно пространства. Входные и выходные данные все равно понадобятся, поэтому иногда их не считают.

У меня нет доступа к этому видео. Если они там говорят "additional space is O(1)", то это именно так, как я описал выше.

Любой самый дешевый vds с каким нибудь линуксом, на который ставится .Net (ubuntu, debian и т.д.). И бота собираете под Linux.

Подскажите пожалуйста как сохранить модель Doctors как авторизованного пользователя?

1) Модели не называются во множественном числе. Модель Doctor привязывается к таблице doctors. И "я получаю модель Users," - то же самое, модель User.
2) Доктор или пациент это не пользователь, это либо роль, и тогда надо делать RBAC, либо авторизированная сущность, и тогда нужно связывать юзера и сущность через один-к-одному, в случае если доктор и пациент кардинально различаются по свойствам, а не просто имеют разные права. А пользователь просто способ авторизации/идентификации.

Приоритета нет, поскольку это не оператор, а языковая конструкция key => value.
Каждый из элементов конструкции вычисляется отдельно.

В стародавние времена это действительно было проблемой.

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

Эта ситуация послужила одной из причин появления хранилищ для неструктурированных данных, таких как Монго, которые входят в очень широкую категорию NoSQL.
Но сами по себе "документо-ориентированные базы данных" в качестве основного хранилища - это ад и проклятие, хуже EAV. Если EAV делает адом только работу с атрибутами товаров, то Монга делает проклятием работу со всей БД целиком. Забудьте об этой идее.

Тем более что в последние годы появилось вполне достойное решение: во всех классических СУБД появилась поддержка JSON полей.
То есть таблица товаров будет самая обычная, в которой есть общие поля типа цены, названия и прочее. А свойства хранятся в JSON поле. Беря, таким образом, лучшее из двух миров.

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

Главное при этом хранить (либо в коде, либо в таблице категорий) эталонные структуры таких json полей, которые, во-первых, использовать как справочники для заполнения товаров (тупо чтобы помнить, что частота процессора называется freq, а не frequency), и чтобы собственно делать фасетные фильтры.

remote amvera already exists

Вы пытаетесь добавить remote с именем amvera,

git remote add amvera https://git.amvera.ru/<имя-пользователя>/<транслитерированное-имя-проекта>

Если вам пишет, что такой remote уже существует, значит вы ранее уже это сделали.
Зачем вы пытаетесь добавить адрес повторно?

Подскажите, что с этим можно сделать?

Если вы хотите заменить ранее добавленный адрес, то либо предварительно удалите предыдущий remote
git remote remove amvera
либо используйте команду замены
git remote set-url amvera ...

Потому что стучаться надо не на локалхост, а по имени контейнера.