mayton2019

Я думаю что главное отличие - это способность осуществлять соединения (JOINS) по любому полю.

Попробуйте сджойнить две таблицы Cassandra по любому полю. Хрен вам. Это считается неверным дизайном. С точки зрения идеологии Cassandra вы должны были дизайнить модель так чтобы таких джойнов (или таких мыслей) у вас никогда не возникало. Грубо говоря - хотите какую-то выборку - подготовьте ее заранее на уровне архитектуры. Типа мат-вью.

Да что там джойн. Там даже выбрать по предложению WHERE не всегда можно. Тоже считается антипаттерн. В базовом SQL синтаксисе это не сработает. Надо добавлять опцию allow filtering что как-бы говорит нам - что мы вышли за рамки обычного запроса. Захотели птичьего молока...

А вот для Oracle/PG/Mysql/MSSQL - получить джойн по любому полю с любым - сущий пустяк. Хотя дать смысл этому джойну будет сложнее. Джойнить величины с величинами.

Хотя в последнее время различия между реляционными и прочими - стираются. Это как парадигмы в ЯП. Лет 20 назад все говорили о парадигмах. Сейчас - многие языки считаются мультипарадигменными. Тоесть спор сам по себе закрыт на уровне определения.

Стоит ли отслеживать такой флуд? Разработчик за 1 рабочий день 100 тысяч раз создаст MyFavoriteProgram.exe и столько-же раз его удалит. Так работают сборщики и IDE, а тебе будет на почту прилетать.

println("Какой у тебя вес ?")
        val weight : Double = readln().toDouble()
        println("Какой у тебя рост ?")
        val height : Double = readln().toDouble()
        println("Какой у вас пол ? муж -1 , жен - 2")
        val year : Double = readln().toDouble()
        val w: Double = 10.0
        val h: Double = 6.25
        val h2: Double = 5.0
        val calc = w * weight + h * height - h2 * year + h2

Это точно не Golang. Поскольку цели и задачи которые ставились перед Golang - сильно отличаются от встраивания в бытовую технику. Это скорее всего C или С++ но вы должны это уточнять.

Вообще с таким сырым ТЗ ничего начинать нельзя. Узнайте хотя-бы модели и названия железок на которых это должно работать.

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

Насколько я понимаю системотехнику, в телефоне (Xiaomi Redmi 9) есть только одно устройство типа 4G приемник. Поэтому и 4G трафик один. И - взаимоисключающий. Тоесть или работаем с одним оператором интернета или с другим.

Хотя входящие звонки я могу принимать с двух операторов.

Симка... хм. Ну это что-то вроде аппаратного хранилища ключей.

Оставь только почтовый индекс обязательным. Всё остальное - пускай текстом запишет как есть.

Дело в том что не все символы из таблицы ASCII можно использовать. Первые 30 штук - управляющие. Если их печатать в консоли - то терминал будет фиксировать странные эффекты. Звук. Скролл экрана. И движение курсора в разных направлениях. Эти-же символы либо не имеют визуального отображения либо отображаются по разному. Их лучше не брать вобщем-то. И в исходниках их эскейпить надо.

Ты лучше скажи что на самом деле надо? Если тебе нужна генерилка паролей - то бери цифры - 10 штук + латиница большая и малая 26 * 2 итого 62. Для генерации 1 млн комбинаций нужно примерно 3.5 раза умножить 62. Логарифм миллиона по основанию 62.

Тоесть 4 символа латиницы и цифр перекрывают твою задачу.

Не знаю как устроен Renpy но доменная модель совершенно не продуманная. Можно создать базовый тип для "персонажа". Имя там... возраст. И производные от него указать.

Мы-же в парадигме ООП работаем, верно?

react, JQuery - это известные фреймворки. Их код разбирать не надо. Надо просто знать как они работают.
Они документированы и очень хорошо описаны в литературе. И очень сомнительно что вы, глядя в код фреймворка поймете как он работает. Такого уровня обратный инжинеринг вам совсем не нужен. И не продуктивен. Просидите долгие годы.

А вот изучать надо бизнес-код самого сайта. Изучать можно по разному. Верно говорят в топике выше - надо ставить брейкпоинты и смотреть как чего работает. А еще лучше - понять как фронт взаимодействует с бэком. Хороший вариант - нарисовать для себя модель наподобие Swagger/GraphQL где описать все методы и примеры аргументов.

А как вы измеряли? Методика бенчмарков в Java - нетривиальна. Тут надо попасть в прогретый код и в промежутки между паузами GC. Иначе ваш эскперимент будет выдавать вовсе не то время что вы хотите мерять.

Всё это кушает очень много ОЗУ и ресурсов диска (SSD), что на рабочем ПК довольно проблемно (32 ГБ, постоянно занята на 100% и образуется огромный файл подкачки), процессор обычно сильно не нагружен (i9-10900 нагружается максимум на 15%).

С большой вероятностью новый сервер который стоит миллион денег также скушает все ваше ОЗУ.
Потому что нет оснований не скушать. Лимиты на использование в ОЗУ зашиваются в программное обеспечение.
Следовательно даже на 32 и на 16 Г вашу задачу можно решать.

Если она нерешаема - то интересно почему. Что за алгоритм? Может язык и виртуальная машина неоптимальны? Python например. Тот никогда не хвастался экономией памяти.

Отправлять HTTP 200 или 404 - это исключительно фича HTTP протокола и к базам данных она не
имеет никакого отношения.

Ты можешь использовать коды HTTP состояний для поддержки статусов ошибок. Это идеология REST но она носит рекомендательный характер. Никто не сможет тебя осуждать за то что ты ее не применяешь или как-то по другому применяешь.

Кстати непонятно как ты раньше слал NULL. Ответ должен быть типизированный. Если это User - то нужно форматировать Json/Xml представление. И где там можно впихнуть null - непонятно.

Если хочешь абсолютной строгости - то бери SOAP или gRPC. Это протоколы удалённого вызова методов и в них на уровне исходного кода не так просто что-то игнорировать или забивать болт на ошибки и исключения. Ну по крайней мере с точки зрения code-review будет очевидно что ты - халтурил.

Эта формула - недостаточная для других конверсий.
input * (value-2 / value-1)
Например Цельсии и Фаренгейты - это умножение и сложение. Вобщем недостаточно одного value.

Я собираюсь в будущем создавать проекты на андроид, в которых все пользователи будут в реальном времени получать информацию с сервера или БД.

Я попробовал это перевести на язык кулинарии и вот что получилось:

- Я в будущем решил стать поваром и готовить людям еду. Люди будут есть эту еду.

В этом утверждении нет никакой конкретики и под нее можно подогнать любую теорию.

По поводу языков и книжек. Их написано очень много. Все они - субъективны. И очень редко
мысль автора книги попадает под те задачи которые тебе надо будет решать.

Тебе надо взять паузу в самообучении. И войти в любой проект где есть похожи стек (стек игровых технологий) и хотя-бы год поработать и понаблюдать как и чего. Пускай даже на низкой оплате. После этого большая часть вопросов у тебя отпадет. И вот тогда у тебя появятся правильные вопросы. И правильное пояснение своих идей про 10 тысяч пользователей и базы данных.

Все. Успехов.

Есть мысль что ты сам себя заблокировал. Работаешь в UI ?

Есть еще мысль что надо посчитать count сколько ты собираешся обновить. Может там - вся таблица обновляется.

Мобильный телефон как веб-сервер? В этом нет смысла по следующим причинам.
Ненадёжна связь. Телефон часто попадает в зоны недоступности. Кому нужен сервер который периодически отваливается? Или какую логику должно иметь то приложение которое делает GET и получает SocketTimeout.

Сложности с получением IP. Куда подключаться? Какой алгоритм обновления?

Если нужно взаимодействие в обратную сторону от нормального сервера к телефону то уже много лет как создана технология веб-сокетов и всех устраивает. Сервер уведомляет телефон. Вот соцсети так работают.

Реляционная алгебра - это не Excel. Она не оперирует понятием порядка строк в таблице. Порядок достигается за счет сортировки по определённым полям. Если у тебя изначально таких полей не существовало - то самое время их создать например на основе sequence. Потом при выводе можно задать ROW_NUMBER()

То что ты сейчас захотел - это фигня полная и она будет сломана сразу-же после например удаления одной строки. Вобщем по вопросу тебе всё равно помогут - но обрати внимание на пробелы в знаниях.