Собствнно вот и у меня херня с тем, что я выбрать не могу, а вариантов мало

встречаю иногда мысль что пока дб на том же сервере можно забить и юзать синхронно

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

И вообще как там все можно будет связать в единый механизм

Есть бд(sqlite3) на 15к уникальных пользователей. Допустим, мне нужно добавить нового пользователя в бд, но мне нужно удостовериться, что его нет в этой бд перед добавлением. На данный момент алгоритм работает следующим образом: берутся все уникальные id каждого пользователя в бд, засовываются в один массив, а далее:

if new_user not in user_list:
    add_user()

Гениально и просто, но данный алгоритм, описанный выше хорошо работает с бд из 10 пользователей, 100, мб даже 1000. А что делать с 15к? Нормально ли сравнивать один новый элемент с массивом, в котором 15к других элементов? Если это ненормально, то как такой объем данных обработать корректно?

if new_user not in user_list:
    add_user()

ЕбАнУтЬсЯ

if new_user not in user_list:
    add_user()

Я бы не брал все значения из бд, а делал бы SELECT WHERE

Хуйня такая, что я маму рот её ебал

У тебя будет 50к пользователей и у тебя вылетит в трубу вся оперативка, дак еще и всю бд ебать ради этого одного

К тому же: сделать поле unique, не?

Я так и делаю. Беру все значения одного столбца id (уникальный идентификатор)

Но их ведь все равно будет 15к

Ты не понял его идею

Выбирать конкретно этот айди

Вернулось тип что-то - значит есть

Но все еще хуйня

Зачем делать два запроса, когда можно сделать один?

А шо делать то тогда?

Я тебе сказал: сделать поле unique, а если уж это айди, то оно должно быть primary key и автоматом unique

Иначе это нихуя не primary key