Кой начин е по-ефективен

Въпросът не е свързан с конкретна база, но сценарият е следния:
Има някакво поле в базата, което трябва (редовно) да се обновява.
Кое ще е по-добре:

1) На всяка стъпка DELETE/INSERT
2) На всяка стъпка INSERT OR REPLACE
3) На всяка стъпка INSERT, INSERT, INSERT после SELECT LAST.

Полето има значение на ON/OFF затова имам вариант 1) - ако записът съществува значи е ON, ако не, значи е OFF.
Всъщност на мен най-читав ми изглежда вариант 3) ама не знам до колко е бърз.

Ако ти трябват history данните ползваш само insert-и. Ако данните станат много можеш да ползваш партишъни (в зависимост от конкретната база данни). В противен случай insert or update (тука има проблем, трябва ти уникален ключ за да работи схемата а не винаги такъв има наличен от входящите данни). Освен това, при много данни може да се забави заради индексите (ако имаш индекс по полета което ще ъпдейтваш, в тоя случай триеш и добавяше на ново).

Ако имаш индекс по полето, SELECT на последния запис е много бърз, дори при милиони записи можеш да очакваш двуцифрен брой милисекунди. Но ако често променяш, бих заложил на INSERT OR REPLACE, така че да не се трупа излишна информация с времето. Там проблемите са по-скоро с конкуретния достъп, ако е възможно от две места едновременно да се прави заявка и има значение кой от двата записа ще остане последен.

Това мнение е било редактирано от DarkOne на 25-08-2021, 20:58

Зависи от базата

PostgreSQL  ползва MVCC store, така че всеки UPDATE реално прави нов запис. Също е по-ефективно колоните, които често се променят да са в отделна таблица, защото всяко писане инвалидира visibility map-a на страницата, което силно преебва използването на индексите

Кой би избрал подобен physical implementation за RDBMS ако при нормално ползване всичко се изпочупва и почва да работи субоптимално. Makes no sense.

Според мен Postgres си работи нормално при INSERT OR REPLACE

На sqlite съм забелязал че трябва да се внимава при таблица с колони (ID, Col1, Col2, Col3) като се прави REPLACE SET Col1 = 42 WHERE ID = 100 без да се указват Col2 и Col3 че дори записът да съществува набива default-и на Col2 и Col3 (примерно NULL) а не запазва старите стойности, но това може да не е релевантно за Postgres.

cheers,
</wqw>

Това за индексите е така. И аз съм го срещал на много места като препоръка - при големи индекси (респективно данни) е по-удачно да се изтрие и да се добави записът на ново отколкото да се редактира вече съществуващ такъв и да се ребилднат индексите след това.

А що се отнася до upsert-а в postgres, не затрива колоните които не се ъпдейтват. Ползвам го често за добавяне на данни с on conflict do update key = excluded.key returning id щото при on conflict do nothing returning id не връща нищо.
В mysql има същия "проблем", но там са го решили с last_insert_id(value) където value е стойността която ще получ за генериран ключ.

Индексите сработват само при голяма уникалност. Едва ли индекса ще е по полето със стойност 1/0. Да отговорим може би трябва да знаем колко ще са записите(мин, макс) в таблицата, какви други полета, дали ще има конкурентни заявки и т.н.