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

Question

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

& 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

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

Answer 3

PostgreSQL supports bits and bit strings natively.

Answer 4

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

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