1) где ты делаешь commit? Или где у тебя включен auto-commit?
2) команда update обычно возвращает количество строк которые были обновлены. Проверь сколько обновилось.
А язык программирования ты - принципиально не указал. Типо язык ООП? Нет такого. Все разные. И игры с конструкторами и super ссылками по разному реализованы.
Алина это все ужасно. Из поста можно сделать следующие выводы.
Фриланс биржа вас не любит и не ценит. И даже наработанный опыт не дает вам гарантий что вас не кикнут из за какого-то пустяка. Вобщем трудовое законодательство идет по пи... короче игнорируется. И правильно выше пишет
один чел что вам и новая регистрация ничего принципиально не меняет.
Вобщем заваязывайте с фрилансом. В наше время корпорации уже дают удаленку. А корпорации
это гарантии того что вы можете как нормальный белый человек работать по 8 часов в день.
Нормально ходить в декрет и в больничный. И иметь отпуск. И главное - видение своей карьеры.
Можно требовать для европейских государств ссылаясь на всякие GDPR и прочее что там есть личная информация. Для РФ - скорее всего безразличны эти требования поэтому можно забить. Хранят как хотят. И ваши объявления скоро появятся в руках у мальчиков в маске Гая Фокса за очень небольшие деньги.
Боюсь что факт удаления мы никак не сможем проверить. Если сайт по поиску не находит
объявление то это не означает что в базе его физически нет. Просто у него флажок стоит
например "archived" и все. И движок текстового поиска его просто не видит.
Спасибо за совет, сегодня провели анализ нагрузки и пришли к выводу, что из за роста объема данных некоторые тяжеловесные запросы стали нагружать sql.
Еще одно наблюдение. Может будет полезно. Услово БД делятся на OLTP и DWH.
В первой работают короткие транзакции типа key-value во второй - всякие sum/avg/count
и прочая аналитика. В реальности БД создают условия когда нет различия для выборки 1
строки по поисковым ключам или множества строк. Благо... реляционная алгебра позволяет.
И как следствие большая часть БД никак не бъется на такую классификацию а просто
по сути являет собой гибридные БД где есть и те и другие виды запросов. И ничего
с этим сделать нельзя. Просто человеческая лень и бизнес-прагматизм решает задачи
здесь и сейчас и не думает ни о каких классификациях и уж тем более на разделениях систем
на первые и вторые. Мне такие БД чаще всего попадались в очень плачевном и загнаноом
состоянии. Вот. И я думаю что формальное разделение систем на NoSQL/key-value и Analytics
было тем самым "ответом" на такое плачевное положение реляционной архитектуры.
Разделение позволяло по крайней мере выделить главную цель - дать быстрый TTFB для
пользователя веб-сессии и сделать это время независимым ни от каких фоновых джобов
или отчетов. Ну а аналитические БД - обычно цеплялись репликой или slave или логическим
стенда-бай (смотря в какой БД) к базе онлайн транзакций.
Вот все кто изначально такую архитектуру сделали - живут припеваючи и ни о каких загонах
и не думают. Благо в наше время, в эпоху докеров и кубернетисов задача поднятия инстанса
стала во много раз дешевле чем 10-15 лет назад когда покупалась железка под задачу.
Сегодня железки нет в изначальных условиях и значит вы - свободны в выборе архитектур.
Услужливость ChatGPT такова что он практически всегда выдает хоть какой-то ответ. За исключением тех случаев когда вы нарушаете agreement об использовании.
RimMirK, смотри. Начни с простого и самого прямого способа. Заведи 2 таблицы. Публикации и пользователи. И еще одну таблицу связь многие-ко многим. Если связь есть то значит пользователь уже смотрел.
Эта схема для малых размеров БД успешно работает. Она может быть не производительной для больших данных но тебе это пока не грозит. Начни с малого. Когда будут performance issues - тогда можно обсуждать как улучшать.
Преждевременно улучшать нет смысла т.к. нет информации что улучшать.
Добавлю что ElasticSearch и Lucene стоят в одном и том-же стеке. Одно из них по уровню ниже другого.
Solr тоже можно считать развитием этого стека но я давно не слышал об его использовании.