Таблица AREA имеет десяток полей (Ключ, ДатаВремя, Место, Цель, Координаты, Имя,,, Синалы)
Сигналов 25 штук и каждый может как присутствовать, так и отсутствовать.
Для этого нужно добавить в таблицу эти самые 25полей типа Boolean.
Но почему-то это показалось расточительным. В итоге было взято только одно поле типа DWORD, где каждому биту соответствует свой номер сигнала.
И программа с этой базой данных успешно начала свою работу.
Вскоре мне потребовалось сделать некоторую статистику, а следовательно выполнить SQL-запросы.
Выбрать все записи на такую-то дату или в таком-то месте проходят на ура.
Но вот как выбрать записи в которых участвовал только какой-то любой один сигнал не ясно.
Конструкция SELECT * FROM AREA WHERE ((ASygnals AND ANumberBit) > 0) не работает так как AND воспринимается как логический, а не математический оператор.
Неужели всё-таки нужно было создавать эти 25 полей изначально?
Уважаемые авторы вопросов! Большая просьба сообщить о результатах решения проблемы на этой странице. Иначе, следящие за обсуждением, возможно имеющие аналогичные проблемы, не получают ясного представления об их решении. А авторы ответов не получают обратной связи. Что можно расценивать, как проявление неуважения к отвечающим от автора вопроса.
23-03-2019 04:02 | Комментарий к предыдущим ответам
>>>Неужели всё-таки нужно было создавать эти 25 полей изначально?
>>>вот и позволил себе некоторые фантазии и оффтоп. А вообще-то я часто проверяю комбинацию установленных битов сравнением с константой
Вопрос по теме:
Допустим, есть три варианта реализации таблицы, как у автора вопроса (id, Name, DateWork, Parametrs; id-pk, DateWork-index), в которой:
1. Parametrs - 25 отдельных столбцов, без индекса;
2. Parametrs - 25 отдельных столбцов, с общим индексом;
3. Parametrs - один столбец (integer или desimal, с битовой упаковкой, как у автора) без индекса.
По этим таблицам можно построить 4 вида запросов:
1. По таблице 1 с условием отбора: = для каждого параметра и объединить их and;
2. По таблице 2 с условием отбора: = для каждого параметра и and;
3. По таблице 3 с условием отбора: = для единственного параметра;
4. По таблице 3 с условием отбора: "бинарный and" от параметра и маски.
Как вы считаете, какие из этих запросов выполнятся быстрее?
23-03-2019 03:48 | Комментарий к предыдущим ответам
>>>SELECT * FROM AREA WHERE ASygnals bAND ANumberBit
Уточню:
1. bAND в access'е из коробки работать не будет. Для его работы необходимо включить режим "Синтаксис для SQL Server (Ansi SQL)".
2. В выражениях sql, access позволяет вставлять любую функцию написанную на vba. Поэтому на vba можно написать любой фильтр, в том числе и аналог bAND.
3. Соответствие флага(-ов) проверяется так:
select * from AREA
where (ASygnals bAND ANumberBit) = ANumberBit
14-03-2019 22:49 | Комментарий к предыдущим ответам
:))) Нет активности на Королевстве, вот и позволил себе некоторые фантазии и оффтоп.
А вообще-то я часто проверяю комбинацию установленных битов сравнением с константой, поэтому и подумал: может подойдёт автору вопроса.
Я предполагал, что существуют некоторое возможное количество комбинаций. - Сигналов 25 штук и каждый может как присутствовать, так и отсутствовать. Что-то это мне напоминает. :-)
13-03-2019 23:44 | Комментарий к предыдущим ответам
Я предполагал, что существуют некоторое возможное количество комбинаций. Извиняюсь, что не уточнил. К тому же можно проверять с помощью сравнения. Например, если в байте 1 бит установлен, то значение >= 128. Но всё это теоретические размышления. К таким фантазиям на тему можно отнести использование хранимки, которая будет проверять биты на сервере. При каких-то условиях может быть приемлемым получение всех данных и фильтрация на клиенте.
А вообще, это задача для объектной базы, у полей которой переменное количество свойств. Тут ещё просто, потому что они одного типа.
Может подойдёт такое решение: заранее вычислить значения для различных установленных битов в поле Сигналы. Например, мы знаем все значения, для которых установлен 5 бит. Вот эти значения и выбирать. Один раз потрудиться для вычислений, а потом сервер будет отдыхать.
Второй вариант: поля нет вообще, но есть таблица связей, где для ID записи перечислены все установленные значения. Если таких значений не установлено, то и записей нет.
Но тут серверу нужно выбирать данные. Мне кажется, что 25 полей более простое во всех отношениях решение.
Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter. Функция может не работать в некоторых версиях броузеров.
