2) Есть видеопоток, на котором, например, обнаруживаются автомобильные номерные знаки и отправляется запрос в базу данных для проверки его наличия. В результате возвращается какой-то результат.Обычно делается полная обработка видео до конца, после чего все найденные номера пишутся в базу с метками времени, по необходимости делаются снэпшоты конкретного фрейма и сохраняются отдельно, ссылка на место хранения картинки так же пишется в бд. Далее уже можно делать запросы в бд на сопоставление двух таблиц - имеющегося списка владельцев и распознанных номеров. По необходимости заводится табличка связей, типа найдено юзер.айди / парсед_нумбер.айди для того чтобы не бегать с выборочными запросами по пользователю и т.п...
3) Для этой базы данных я хочу создать WEB с личной учетной записью и реализацией в виде пользователя - администратора...Это базовый функционал любого современного фреймворка, авторизация и роли. Здесь вы никакого функционала по идее не пишете вообще. Только создаете и настраиваете соответствующие роли и права. "создать WEB" в вашем случае логично просто написав АПИ с десятком рутов, далее будет не особо важно будет ли у вас веб страничка или приложение.
1) PostgreSQLЛюбая рбд. Специфичных задач я тут не вижу, подойдет все что можно установить и с чем вы знакомы лучше.
2) Python + Tenserflow и/или что-то в этом роде + psycopg2Опять же, задача чисто прикладная, любые инструменты выполняющие поставленную задачу подойдут. Производительность и качество можно проверить только тестами на конкретных данных.
По п.2, ожидается, что не будет необходимости отслеживать сразу несколько объектов и отправлять несколько параллельных запросов. Однако это не исключено.Это в любом случае будет работа с командной строкой, любой процесс из которой можно запустить отдельным потоком.
3) Python + Flask и связанное с этим, например, Bootstrap и тому подобноеСкорее всего апи на любом фреймворке + какой-нибудь реакт/вью.
4) Android Studio, Kotlin + что-то для работы с БДПо описанию скорее какой-нибудь PWA хватит с головой. Вся работа с бд идет через апи, ничего дополнительного особо придумывать не надо.
Я напоминаю вам, что у меня нет опыта работы с чем-то настолько большим. Спасибо.Слона едят по кускам. Разбейте задачи на понятные подзадачи и решайте все в порядке реализации. Каких-то инновационных фичей я тут не вижу, все строится либо на готовых модулях/приложениях, либо на достаточно примитивной логике, так что задача вполне по силам новичку, хоть и придется поработать.
preg_replace('~⚡~ui', 'X', $str);preg_replace('~[\x{26A1}]~ui', 'X', $str);
var_dump($_POST);$password = md5('kakdj834'); хэшировать черте-что после добавления в бд пароля в открытом виде - особый вид искусства...mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);ini_set('error_reporting',E_ALL);
ini_set('display_errors', 1);header("Cache-Control: public");
header("Content-Description: File Transfer");
header("Content-Disposition: attachment; filename=somefile.ext");
header("Content-Transfer-Encoding: binary");
header("Content-Type: binary/octet-stream");
readfile($filePath);operation_type это тип операции. Списание или же начисление. От этого на фронте будет вырисовываться определённый текст. PLUS - начисление, SUB, списание, но как я уже и сказал это у меня вызывает вопросы. Ведь даже при списании будет начисление.Смысл? Правильнее добавлять минус при списании к стоимости покупки, тогда это поле вообще не понадобится, а сумма по транзакциям будет правильной. Ну и на фронте исходя из знака отображать что там нужно...
list_purchase, конечно можно вынести в отдельную таблицу и я понимаю даже почему, но данное поле даже необязательное, оно как примечание. Стоит ли для неважный вещей создавать таблицу?Вообще странно, что у вас покупка состоит вроде бы из набора итемов, но они нигде не перечислены, кроме как в необязательном поле...
Не будет ли нарушаться принцип KISS?KISS это не принцип построения структур, это принцип построения кода, понятного для чтения и интерпретации. А изначально вообще принцип построения визуальных интерфейсов. В построении структуры реляционных баз основной принцип - соблюдение нормальных форм (см. ниже).
И как бы Вы реализовали систему списания и начисления баллов? Наверное это самый главный вопросТак а какая логика начислений? Надо добавить - делаем апдейт на нужную сумму, нужно списание - делаем апдейт на нужную разницу, в чем вопрос?
Стоит ли делать зависимости? Чтобы сумма бонусов клиента зависела от таблицы покупокЭто называется "нормальные формы". На практике вам будут нужны первая, вторая и третья нормальная форма (например хранение total_purchase нарушает 3 НФ, так как может быть вычислена из объединения с таблицей покупок).
Может где то, в определённом источнике имеется свод информации, касаемо таких решений? Может где то, в определённом источнике имеется свод информации, касаемо таких решений?
Мол, даем злоумышленнику понять, что почта верная и достаточно ему просто подобрать пароль.Это неправильные разработчики, и они делают неправильный