допустим есть таблица объекта, в ней нужно хранить некоторые настройки типа bit(есть, нету, другого не существует), причём настроек этих ограниченное количество.
Идеи:
Допустим их 6.
1) хранить их в varchar(6), строка получится вида "000110"
на мой взгляд достоинства :
- легко парсить поле[1]- первый параметр, и всё
недостатки:
- кто-то поставит иной символ, хотя можно проверять на не ноль и.
- кто-то недопишет символ, или сделает строку больше
2) создать справочник
1-я таблица
id, имя параметра(варчяр)
2-я таблица (связывающая)
id, id параметров
3-я таблица - сам объект. и айдишник связной таблицы
из плюсов вижу целостность, также, число параметров - это константа, их могут не дописать, но будит видно, какие параметры есть.

3)
собственно хранить в самой таблице обьекта bit'ами, но она и так уже на вид как многоэтажка.
---------------------------------------------------------
SET @@verSION = 'Microsoft SQL Server 2005 - 9.00.3042.00 (Intel X86) Feb 9 2007 22:47:07 Copyright (c) 1988-2005 Microsoft Corporation Standard Edition on Windows NT 6.0 (Build 6002: Service Pack 2) '

также присутствует мысля, что если число параметров константа, и они хранятся в виде есть - нет , то можно хранить те, что есть
---------------------------------------------------------
SET @@verSION = 'Microsoft SQL Server 2005 - 9.00.3042.00 (Intel X86) Feb 9 2007 22:47:07 Copyright (c) 1988-2005 Microsoft Corporation Standard Edition on Windows NT 6.0 (Build 6002: Service Pack 2) '[/quot]

а можете аргументировать?
допустим есть большая куча данных в формате есть-нет, где всё - нет, но то, что их нет это нужно хранить. В итоге по второму варианту мы их просто хранить не будим.
---------------------------------------------------------
SET @@verSION = 'Microsoft SQL Server 2005 - 9.00.3042.00 (Intel X86) Feb 9 2007 22:47:07 Copyright (c) 1988-2005 Microsoft Corporation Standard Edition on Windows NT 6.0 (Build 6002: Service Pack 2) '

к тому же есть 2-3% вариант, что когда-нибудь добавят к объекту ещё одну опцию.
То есть объект что-то вроде пола. Есть м и есть ж, но никто никогда не подумает, что он окажется и п. Вероятность низкая, но вдруг.
---------------------------------------------------------
SET @@verSION = 'Microsoft SQL Server 2005 - 9.00.3042.00 (Intel X86) Feb 9 2007 22:47:07 Copyright (c) 1988-2005 Microsoft Corporation Standard Edition on Windows NT 6.0 (Build 6002: Service Pack 2) '

в дополнение ко всему роль параметров у объекта если один из параметров всегда 0 (то есть свойство всегда отсутствует - это тоже нужно отображать) третий вариант для этого больше подходит, но беспокоит многоэтажность структуры. в одной таблице у нас используется вариант 2. Там varchar(60), и в 90 % это всё 0. если это сделать всё полями - будит

поля объекта
авторпараметр_ 1
параметр_ 2
параметр_ 3
параметр_ 4
параметр_ 5
параметр_ 6
параметр_ 7
параметр_ 8
параметр_ 9
параметр_ 10
параметр_ 11
параметр_ 12
параметр_ 13
параметр_ 14
параметр_ 15
параметр_ 16
параметр_ 17
параметр_ 18
параметр_ 19
параметр_ 20
параметр_ 21
параметр_ 22
параметр_ 23
параметр_ 24
параметр_ 25
параметр_ 26
параметр_ 27
параметр_ 28
параметр_ 29
параметр_ 30
параметр_ 31
параметр_ 32
параметр_ 33
параметр_ 34
параметр_ 35
параметр_ 36
параметр_ 37
параметр_ 38
параметр_ 39
параметр_ 40
параметр_ 41
параметр_ 42
параметр_ 43
параметр_ 44
параметр_ 45
параметр_ 46
параметр_ 47
параметр_ 48
параметр_ 49
параметр_ 50
параметр_ 51
параметр_ 52
параметр_ 53
параметр_ 54
параметр_ 55
параметр_ 56
параметр_ 57
параметр_ 58
параметр_ 59
параметр_ 60

вопрос в том, что для такого небоскрёба лучше 2 или 3 ?
---------------------------------------------------------
SET @@verSION = 'Microsoft SQL Server 2005 - 9.00.3042.00 (Intel X86) Feb 9 2007 22:47:07 Copyright (c) 1988-2005 Microsoft Corporation Standard Edition on Windows NT 6.0 (Build 6002: Service Pack 2) '

NafТогда надо углубиться в предметную область, абстрактно это конечно хорошо, но в отрыве от реалий
С уважением, Naf
собственно углубляться не надо. Я как-бы описал объект вкратце.
6 полей, малая вероятность, что новый параметр добавится, к тому же ещё один плюс у варианта 2. если я использую третий вариант - то при добавлении поля придётся делать правку клиента.

NafErik_KartmannNafТогда надо углубиться в предметную область, абстрактно это конечно хорошо, но в отрыве от реалий
С уважением, Naf
собственно углубляться не надо. Я как-бы описал объект вкратце.
6 полей, малая вероятность, что новый параметр добавится, к тому же ещё один плюс у варианта 2. если я использую третий вариант - то при добавлении поля придётся делать правку клиента.
ты же сказал, что число фиксированно, надо будет новые добавите, если сразу рассчитываете на возможность динамич. добавления, то и оговаривайте сразу
потом сказали 6, привели аж 60
в динамическом наверное лучше иметь таблицу категорий (это названия ваших битов)
и таблицу "принадлежит категории" - ассоциативная связь сущность принадлежит категории - ссылка на сущность и на категорию, уникальный индекс по паре этих полей
Извините покорно, но я из-за суматохи не дописал, что це другая таблица. Я её для примера привёл.
у сабжевого обьекта возможность добавления есть, но мизерная.

авторв динамическом наверное лучше иметь таблицу категорий (это названия ваших битов)
и таблицу "принадлежит категории" - ассоциативная связь сущность принадлежит категории - ссылка на сущность и на категорию, уникальный индекс по паре этих полей
так это и есть вариант 2?
А в случае, если мы так постановим, что хрен с ним, и число параметров - это константа, то лучше использовать способ 3 ?
А чем он лучше 2) ?
есть какойнибудь вариант 4)
---------------------------------------------------------
SET @@verSION = 'Microsoft SQL Server 2005 - 9.00.3042.00 (Intel X86) Feb 9 2007 22:47:07 Copyright (c) 1988-2005 Microsoft Corporation Standard Edition on Windows NT 6.0 (Build 6002: Service Pack 2) '

Как крайний вариант, разве что ;)
---------------------------------------------------------
SET @@verSION = 'Microsoft SQL Server 2005 - 9.00.3042.00 (Intel X86) Feb 9 2007 22:47:07 Copyright (c) 1988-2005 Microsoft Corporation Standard Edition on Windows NT 6.0 (Build 6002: Service Pack 2) '