Всем доброго дня.

Есть табличка в базе, в ней есть три поля, путь будут INDEX, VALUE: Integer; MASK: SmallInt.
Теперь надо сделать проверку на уникальность, по условию:


Т.е. либо разные Index и/или Value, либо одинаковые, но тогда нет общих битов в маске.

Вопрос: можно ли и стоит ли это делать средствами Firebird (и если да, то как?) или забить и реализовать проверку в приложении?

Filippov Dmitryalekcvp,
можно сделать.
Несколько вариантов (не все возможные) на выбор.
1) в процедуре добавления, обновления данных.
2) в триггерах на INSERT, UPDATE
1. добавляться будет сразу из приложения, без ХП.
2. А как грамотно проверить? Что-то типа:

И стоит ли тогда сделать какой-нибудь индекс, чтобы проверка быстрее проходила?

Filippov Dmitryalekcvp,
если это не курсовик и т. п. все таки рекомендую работу делать через хранимые процедуры.

Чтобы вести предметный разговор про индексы требуется немного больше информации:
структура таблицы, какие данные, их состав / объем, режим работы (как обновляется, пополняется).. да и еще много чего.
Это простейшая программа, на три таблички, для резервирования объектов. Справочник объектов, справочник пользователей и табличка, собственно, с резервированием.
Index - это ID объекта, Value - дата (без времени), Mask - рабочие часы (интервал резервирования кратен часу).
Не курсовой, но чисто для облегчения жизни внутри отдела.

KreatorXXIalekcvp,
А что, нужно не позволять делать update или Insert? ИМХО, на клиенте удобнее это делать.
Нужно сказать "упс, занято", если пересекается по времени. Просто мне казалось что правильнее будет это контролировать на сервере, чтобы корректность данных проверялась в одном месте, а не то там, то там.

hvladСоздай доп таблицу (ID, Value) с уникальностью на оба поля.
Перед вставкой в основную таблицу (например в триггере before insert\update) вставь ID, Value в доп таблицу.
Если удалось - можно обычным селектом проверить наличие конфликтующей маски в основной таблице.
Если не удалось - откат и повтор (или отказ от операции).Дык, в том и дело, что ID и Value могут быть не уникальными.
hvladНу, или откажись от масок и вставляй несколько (ID, Value, Hour) в основную таблицу с обычным контролем уникальности по 3-м полямПри типовом сценарии - количество записей в таблице вырастет в 8 раз...

Интересно, а если 8 индексов по 3 полям сделать - это совсем маразм будет? :)

Гаджимурадов Рустамalekcvp>Например, что вообще оозначает несовпадение битов - что
человек не работал в 1 час на нескольких объектах или что?

8 рабочих часов - 8 бит. Бит установлен -> в этот час объект занят. Биты совпадают - конфликт, один объект не может использоваться двумя пользователями одновременно.

Например, имеется запись A:

кто-то зарезервировал объект с ID = 1 на 10е июля с 10 до 13 часов.

Пытаемся добавить запись B:

кому-то объект с ID = 1 тоже нужен 10го июля с 12 до 14 часов, но тут должен быть облом, т.к. с 12 до 13 объект уже занят.

Filippov DmitryПотому как "полбита" не посчитать, а человек (или объект) занят полчаса, а потом полчаса не занят - это вполне жизненно.В моём случае это исключено. Либо занято весь час, либо свободно.

IBExpertНафиг такие извращения? Разбить MASK на два поля - начало и конец интервала в часах.
Или стоит задача 8 байт на каждой записи сэкономить?
А как тогда искать пересечения? В случае с масками будет A and B = 0 (чисто) <> 0 (пересекаются), а если интервалы хранить, то надо 4 сравнения делать.

И как это поможет с уникальным индексом? А в триггере - без разницы, маски или интервалы.

К тому же, если интервал, например, с 10 до 12 и с 13 до 15 в один день, то с маской это одна запись, а с интервалами - две.
Filippov DmitryID объекта,
час
уникальный индекс по этим двум полям.
Дата ещё, и получится, как выше советовали, просто в основной таблице по записи на каждый час резервирования. Т.е. размер x8 и в приложении сложнее обрабатывать, т.к. потом из набора всё равно маску собирать придётся для отображения/редактирования.

Гаджимурадов РустамВернее, не снимется - пересечение интервалов придётся
проверять вручную, без всяких индексов.

Ну так если пересечение всё равно придётся вручную проверять, то с масками и проверка проще: bin_and(a, b) = 0 и всё.
Т.е. я так понимаю - в любом случае проверку придётся делать триггером?

Гаджимурадов Рустамкогда/если появится необходимость
бронировать более 8 часов или график будет неодинаковый
у разных объектов/дней
Больше 24 часов в день всё равно не забронировать, а Integer - 32х-битный.
А для разных дней и так разные записи.

WildSeryГаджимурадов Рустам,
Диапазон может вставляться не "нормальным" диапазоном, а перечислением всех часов.
Тогда уникальность сработает.

Так, прикинуть: 365 дней в году, по 8 записей на день, 10-15 объектов ~ 30-45к записей в год. В принципе не много, я так понимаю?
Правда я ещё для повторяющихся событий хотел сделать ссылку на ID первой записи, чтобы можно было редактировать всю группу, придётся ещё одно поле добавлять...

kdvТак что вот этот "масочный" контроль устроить можно было бы только вычисляемым индексом (скорее, индексом по вычисляемому столбцу).
Ну вот я и спрашивал про 8 индексов (каждый имеет вычисляемый столбец со значением NULL или 1 для соответствующего бита)

WildSeryalekcvp,
50К записей в год, в таблице из 3-4 полей простого типа - это вообще ни о чём.
Там около 10 полей, в т.ч. 1 varchar(256), я привёл только значимые.

В общем я подумал и решил немного модифицировать идеи выше:

Таблицу с резервированием я разобью на две: в первой будет - id, кто, что, описание и т.п., а во второй только: res_id (= id из первой), объект, дата, номер часа. И, соответственно, во второй сделаю уникальный индекс по всем полям, кроме res_id.

Какие-нибудь замечания или дополнения можете сделать?

Гаджимурадов РустамЛишь повторюсь - в погоне за простотой уникальности
ты значительно усложняешь реализацию и сопровождение.
А как иначе избежать этого 21482445 ?

Гаджимурадов Рустам,

Ну ещё есть вариант делать с маской, проверку через триггер, а для избегания сценария от kdv - делать очень короткую пишущую транзакцию (wait) и первым делом в ней блокировать строку с объектом в справочнике объекта. Тогда не будет синхронных резервирований одного объекта и, соответственно, описанной ситуации.

Гаджимурадов РустамНу это та же пессим.блокировка, только не дат, а объекта.
А даты в такой модели не заблокировать никак...

Гаджимурадов Рустам,

Приложение напрямую к серверу БД коннектится, не вижу смысла заморачиваться с 3хзвенкой.

Дегтярев Евгенийalekcvp,
а если экземпляр один то и с блокировкой можно не заморачиваться )

Пишущих экземпляров где-то 2-5 планируется.