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

Есть табличка в базе, в ней есть три поля, путь будут 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 первой записи, чтобы можно было редактировать всю группу, придётся ещё одно поле добавлять...