Създаване на Ограничение за уникален Активен запис

В таблица искам да имам много записи, които да се държат за историческа достоверност, но само един от тях да е текущо „активен“.
Примерно ако искам да държа информация за срещите ми по канадска борба. Искам в таблицата да са всички мачове, но само един от тях да е активен в момента.
Обновяването на таблицата може да става в силно агресивно-конкурентна среда, и е възможно множество клиенти да се опитат да въведат текущия мач едновременно, което искам да избегна.
Възможно е в таблицата да има много активни записи, но за различни ситуации, примерно за мен един активен мач, за друг състезател друг активен мач и т.н.

Не искам да разделям отделна таблица за историческите данни.

Не мога да синхронизирам външните клиенти.

Предложения?

Това, което на мен ми хрумва е да имам колона "active", в която да има стойност TRUE ако записа е активен, и NULL ако записа не е активен. Като се включи тази колона в UNIQUE CONSTRAINT, ще може да има много записи с NULL, но само един с TRUE. Негатива е, че ще може да има и един запис с FALSE в колоната, което не ме радва.

За актуален резултат:
GROUP BY(Match), MAX(Date)

За многократни вмъквания на едно и също:
INSERT OR IGNORE

Подходът ми се струва, че е грешен. Хистори данните не бива да се редактират (бизнес правило, все пак това са ти логовете).

За реализация на подобна схема ползвам таблица с активните записи. Когато запис стане неактивен се трие и с териер се записва в таблицата с историята. Самата таблица с историята е хубаво да е с партишън за да не се получават проблем с производителността след време.

Защо искаш да избегнеш тоя вариант?

Това мнение е било редактирано от thrawn на 05-02-2021, 18:38

Ти пък един проблем си намерил.

Много по-големи ядове от този ще береш с тази структура.

Това мнение е било редактирано от DarkOne на 05-02-2021, 20:53

Я дай едни примерни данни, че така само гадаем какво точно искаш.

Бе то май гледам само защо го иска баш така.

Между другото, като казах, че е ясно, се сетих, че не ми стана ясно каква е тая идея с булевата стойност (която се иска) и изкуствено добавената стойност null.
Струва ми се, че в таблицата няма да има само един активен запис (среща по канадска борба) а ще има много (среща по джудо, икебана , канадска борба) което значи, че ключът задължително трябва да е съставен за да може да се ползва unique за активните записи. А това значи, че няма да има проблем и със стойността false при неактивните, което прави null излишна.

Това мнение е било редактирано от thrawn на 06-02-2021, 08:29

Какви биха били плюсовете и минусите на следното:

-Добавяш колоната status, слагаш default value false и not null
-Правиш UNIQUE Cosntraints на база няколко колони (+статуса) , които да ти определеят уникалността на двубоя

Направи тогава отделна таблица за *активните* данни :-)) Таблицата с history данни ще се има достатъчно неприятности с конкурентните клиенти, които ръгат един и същ event.

Принципно ако искаш да имаш active колона и да uniqify-неш примерно редовете по user_id, sport_id не я правиш nullable, а добавяш *филтриран* UNIQUE индекс така някак

. . . колкото и да е dubious този дизайн. Още нещо, примерно в MSSQL ако имаш UNIQUE индекс по него можеш да имаш *само* един ред с NULL -- go figure!

А може и едно view да пробваш със SELECT * FROM MyTable WHERE active = 1 и после ако ти харесва как се получава да го материализираш за performance.

cheers,
</wqw>

Разделянето усложнява. „Ни щъ.“

Това свърши работа в Postgres! И е точно това, за което питам.
Стандартен SQL ли е това, или е някакво разширение, за което трябва да се оглеждам?

Да, наистина странно. Работя с Azure MSSQL, но до сега не ми се е случвало да попадна в такава дупка.
Решението с CREATE UNIQUE INDEX ... WHERE ... изглежда ще работи и с MSSQL.

@wqw: мерси.