Михаил Р.

select 
  people.* 
from people 
join people as parent on people.parent_id = parent.id 
where people.size > parent.size;

Откуда у вас миф о "50 человек на место, если убрать новичков"?

Для уверенности буду говорить о бэкенде, но тимлид фронтов моей команды говорит, что и у фронта ситуация похожая. На одну нашу вакансию прилетает 50-200 резюме в неделю, в зависимости от активности рекрутёров, и все они от джунов, за исключением одного-двух слабых мидлов с опытом не больше трёх лет. Причём эти мидлы брезгливо морщатся на зарплаты меньше 300. Зачастую даже они получают оффер от другой компании быстрее, чем мы заканчиваем их собеседовать. Сильный мидл попадается раз в два-три месяца. Сеньоры не попадаются вообще. В некоторых банках уже несколько лет почти тысяча незакрытых вакансий.

NULL и 0 будут давать разный результат при подчете агрегации. Sum, Avg и прочие стат- функкии будут учитывать 0 и игнорировать NULL.

Вообще в реляционной алгебре правильно использовать NULL когда данных нету.

Еще для некоторых dbms (Oracle) Null не индексируется. Это экономит место в сегменте индекса и делает поиск более быстрым дла nullable колонок.

NULL — это отсутствие значения. Если не "устанавливать" значение, то это и будет по-умолчанию. Если поле участвует в вычислениях, то лучше поставить 0. Если отсутствие значения используется в логике, то оставляйте NULL. Например количество товара: 0, код (если допускается неопределённость) —NULL.

Если это не курсовая, то сыро.
Цены - в отдельную таблицу, добавлять период действия. Если цена меняется с завтрашнего дня, вы когда их менять будете?
Закупочные цены - тоже имеют свойство меняться. Партии товаров на складе могут иметь разную цену поступления. Не увидел, что будет двигать остатки товара на складе (на вход).
Оплаты фиксировать в отдельной таблице, там будут конкретные транзакции, типы оплаты, не стоит это все пихать в заказ.
Скидки - так же в отдельную таблицу, период действия, типы скидок, etc
Это очень кратко.

1. Хранение адреса в виде записей в базе.
Думаю, вполне можно было бы обойтись текстовым полем и id по кладр/фиас/гар (если россия).
Всё равно все возможные форматы адресов ты нормально не покроешь (а если покроешь - это будет свой фиас)
2. Использование float для хранение цены товара
3. Скидка чисто в виде числа в заказе - вполне возможно, что ты захочешь ввести какую-нибудь более гибкую систему скидок.
В текущей ситуации такое невозможно.
Например скидку в виде абсолютного количества денег, полностью бесплатный/подарочный товар.
Скидку только на отдельную категорию товара, или систему баллов.
Так что я бы сделал бы отдельную таблицу со скидкой на заказ, которую бы мог потом расширять.
(в принципе, можно оставить пока так, а потом миграцией всё исправить)
4. (комментарий про хранение цены убран, тк я изначально не заметил поле store_price)
5. Хотелось бы, чтобы была функция оформления заказа без регистрации.
6. А, ну и да. В заказе должен быть указан адрес. У пользователя их может быть несколько, и должен быть способ определить, на какой именно доставлять. (а с учётом п5 - адрес должен быть самостоятельной вещью)
+ Должна быть система как и с ценой - адрес у уже завершённого заказа не должен меняться.
7. А где статусы заказа? Типа новый/оплачен/доставка/доставлен/завершён?

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

PPS: Применять такую схему я бы осмелился только в рамках курсовой работы в колледже. Даже на диплом это врядли тянет, не говоря о реальном мире.

В целом правильно, но если уж затеваться с хранением адресов, то тогда в заказе должна быть ссылка на id адреса. иначе просто нет смысла. В целом для такой примитивной схемы отдельное хранение адресов выглядит неадекватным, я бы просто писал адрес в заказ.
То же самое про телефоны. Просто писать в таблицу юзеров.
Не хватает емейла. Смс на каждый чих рассылать дорого.

В таблице заказов очень сильно не хватает поля status. Ну и связанной таблицы с историей статусов.
Отдельно хранить дату и время - это глупость. Есть тип datetime
discount - это ОЧЕНЬ отдельная тема. Но по крайней мере скидка должна размазываться по товарам. Если клиент при выкупе откажется от одного, то как пересчитывать цену?
В целом стоит в заказе дублировать основную инфу по товарам. Потому что её надо показывать в истории заказов, а товара может уже не быть в базе. В том числе цену до скидки и со скидкой.

Непонятно, что за таблица store.

Для ООООЧЕНЬ простого букинга с большой натяжкой.

Не вижу собсно отелей (или он будет один? Тогда это не букинг, а бронирование в отеле)

Не вижу типов комнат (возможно это сайт бронирования конкретной квартиры покомнатно?)

Эмоунт - это деньги? Тогда тип флоат не подходит.

Что за фючеред_имэйдж? еще и интежер...

Где опции в номере? Или в комнатах квартиры все удобства на улице и это где то отдельно текстом прописано?

Короче пока на 2 с плюсом...

Если вы не понимаете преимущества и недостатки этих языков именно в задачах ML, а кроме того, вы в одну кучу намешали "ML-движок" и "ML-модель" , то это просто означает что у вас (и вашей команды) знания в области ML реально нулевые. В таком случае писать самостоятельно "ML-движок" я бы вообще поостергся. Как вам уже посоветовали - нанимайте людей, которые имеют соответствующую экспертизу, они и на ваши вопросы вам ответят. Опыт в программировании и опыт в ML - это близкие, но совершенно различные скилзы.
P.S. Про вопрос - а ЗАЧЕМ самостоятельно писать "ML-движок" - я вообще умолчу.

Web - на два порядка проще (читай дешевле) для разработки за счет повышенного требования ресурсов на клиентской стороне.

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

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

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

Кстати, один момент, тормозные веб приложения это не потому что веб такой плохой, это потому что разработчики ленятся делать все как следует. Рынок заполонили низкокачественные разработчики на основе веб. Помни об этом!

Это самому написать легко

Поднимаешь в РФ VPN (или арендуешь VPS в РФ) и подключаешься к нему на роутере. Заворачиваешь только необходимый трафик на роутере/пк в этот VPN.

Те, тебе в любом случае нужен мост к серверу в РФ, чтобы ходить через него на необходимые сервисы.