По какой-то причине я не думал о NULL :) Это будет работать для нас очень хорошо, по крайней мере, как краткосрочное решение ... В долгосрочной перспективе мы собираемся разделить эту таблицу на две: покрытия и покрытие_истории. Большое спасибо, сэр!

ей БД есть специальный вид таблицы, в которой хранится история ее изменений. Так называемая «самоархивированная» таблица:

CREAT TABLE coverages (
   id INT, # primary key, auto-increment
   subscriber_id INT,
   current CHAR,  # - could be "C" or "H".
   record_version INT,
   # etc.
);

Здесь хранятся «покрытия» наших подписчиков. Поле «текущий» указывает, является ли это текущей / исходной записью («С») или исторической записью («Н»).

У нас может быть только одно текущее покрытие "C" для данного подписчика, но мы не можем создать уникальный индекс с 2 полями (* subscriber_id и current *), потому что для любой данной записи "C" может быть любое число "H" «Записи - история изменений.

Таким образом, индекс должен быть уникальным только длятекущий == 'C' и любой subscriber_id.

Это можно сделать в Oracle DB, используя нечто вроде «материализованных представлений»: где мы можем создать материализованное представление, которое будет включать только записи стекущий = 'C' и создайте уникальный индекс с этими 2 полями: * subscriber_id, current *.

Вопрос в том:Как это можно сделать в MySQL?

 Alex Kovshovik17 янв. 2011 г., 23:54
У нас есть несколько серверов приложений (веб), которые могут попытаться вставить одну и ту же запись одновременно (и это действительно происходит). Нам нужно предотвратить дублирование в таблице покрытий.
 dkretz17 янв. 2011 г., 23:39
Какова цель уникального индекса? Что вы не можете сделать с неуникальным индексом? Это звучит как преждевременная оптимизация ...

Ответы на вопрос(1)

Решение Вопроса

Вы можете сделать это используяNULL ценности. Если вы используетеNULL вместо "H»,MySQL будет игнорировать строку при оценкеUNIQUE ограничение:

A UNIQUE index creates a constraint such that all values in the index must be
distinct. An error occurs if you try to add a new row with a key value that
matches an existing row. This constraint does not apply to NULL values except
for the BDB storage engine. For other engines, a UNIQUE index permits multiple
NULL values for columns that can contain NULL.

Теперь это немного обманывает, и это означает, что вы не можете иметь свои данные в точности так, как вы хотите. Так что это решение может не соответствовать вашим потребностям. Но если тыМожно переработать ваши данные таким образом, это должно работать.

 Alex Kovshovik17 янв. 2011 г., 23:52
По какой-то причине я не думал о NULL :) Это будет работать для нас очень хорошо, по крайней мере, как краткосрочное решение ... В долгосрочной перспективе мы собираемся разделить эту таблицу на две: покрытия и покрытие_истории. Большое спасибо, сэр!

Ваш ответ на вопрос