Структуры базы данных с большим количеством битовых полей

Question

У меня есть класс данных с очень большим количеством двоичных свойств - 151 (!), Если быть точным, - и меня интересует, как структурно моделировать эти данные. Несмотря на внутреннюю эффективность хранения битовых полей в виде байтов, мои чувства пауков в программировании покалывают при создании таблицы с 151 битовыми полями (в дополнение к другим свойствам).

Там не будет большого количества строк - возможно, 1000 и однажды отправленные в производство не будут меняться очень часто.

Я думал о том, чтобы разделить мои данные на непересекающиеся подклассы и создать отдельные таблицы, но разделение свойств таким образом неосуществимо и даже если возможно, конечно, не будет эффективно отображаться с подклассами данных. Другая проблема заключается в том, что я хотел бы сохранить все данные вместе и избежать дублирования полей и / или строк. Я также рассмотрел использование некоторого пользовательского двоичного формата, но это не работает, так как поле ключа в моих данных используется в качестве внешних ключей в других таблицах.

Запросы будут интенсивно использовать предложения WHERE для извлечения соответствующих данных. Я рассмотрел использование нескольких полей long или int, но я отклонил это как неработоспособное, поскольку я не знаю побитовых операторов и функций или функций в SQL, и, как отмечалось выше, классификация свойств проблематична, не говоря уже о других основных вопросы разработки программного обеспечения (с этим методом).

Я буду использовать PostgreSQL.

Итак, мой вопрос здесь заключается в том, чтобы сделать таблицу с огромным количеством полей или есть другие методы, совместимые с реляционной моделью?

Answer 1

Самая большая проблема, которую я вижу, - это очевидный факт, что мощность однополевых индексов, по меньшей мере, низкая. Может быть, вы можете описать данные немного больше, и мы можем обсудить другие проекты? Например, все ли они независимы друг от друга?

Имея только 1000 строк, может быть проще хранить это в другом месте, чем в базе данных (хотя я полагаю, что есть много возможностей объединения?) Не по причинам эффективности запросов, но на самом деле это не похоже на данные базы данных.

Answer 2

Смоделируйте ваши данные наиболее подходящие для вашей проблемной области. Здесь у вас не так много данных, в худшем случае, если каждая строка занимает 200 байтов, вы просматриваете менее 200 КБ данных. Это тривиальная сумма, даже если ваша конкретная база данных не реализует логические свойства эффективным способом.

С другой стороны, наличие 150 логических свойств звучит несколько подозрительно, возможно, ваша модель данных может быть дополнительно нормализована?

Answer 3

PostgreSQL изначально поддерживает биты и битовые строки.

Answer 4

Почему вы не можете использовать побитовые операторы?

&   bitwise AND 91 & 15 11
|   bitwise OR  32 | 3  35
#   bitwise XOR 17 # 5  20
~   bitwise NOT ~1  -2

от: http://www.postgresql.org/docs/7.4/static/functions-math.html

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