Информация, которая должна храниться в БД:
ID (Integer), Name (String), Check (Boolean)
Выглядеть это могло так:
ID Name Check
1 test1 True
2 test2 False
3 test3 False
4 test4 True
Однако, в таком случае слишком часто будут повторяться значения полей столбца “Check”. В целях экономии, думаю, будет более эффективно разбить эту таблицу на 2 других и исключить столбец “Check” вовсе. Получится одна таблица для записей где Check = True, другая – для записей, где Check = False. Т. е. вот так:
Таблица №1 (Check = True)
ID Name
1 test1
4 test4
и
Таблица №2 (Check = False)
ID Name
2 test2
3 test3
Вроде бы логично. Но тогда у меня, у ламера, :) появляется 2 вопроса:
1. Неужели, каждый раз, когда пользователь будет щёлкать на соответствующий CheckBox придётся перемещать запись из одной таблицы в другую?
2. Как «привязать» для отображения значение столбца “Check” к CheckBox’у?..

Спасибо за уделённое время и за помощь!

tpgТогда по событию изменения чека придется просто либо удалять строку из второй таблицы, либо добавлять.[quot]
Так это же практически тоже самое что и перемещать записи из одной таблицы в другую. :)
А "напрямую" привязать к CheckBox'у не получится?
...А может есть в SQL какая-нибудь штука, позволяющая при сведении таблиц "виртуально" добавлять столбец и "заполнять" его данными, на основе чего-то?.. Было бы просто фантастиш, если бы при сведении таблиц 1 и 2, можно было бы добавить столбец Check и заполнить его значения на основе таблиц 1 и 2: строки из первой - Check = True, строки из второй - Check = False. При добавлении запись помещается в соответствующую таблицу, а при изменении CheckBox'а, при обновлении или завершении работы с таблицей запись бы перемещалась (или оставалась на месте, если значение в конце концов небыло измененно).
Есть в SQL что-нибудь подобное?.. Или есть, но это будет менее эффективно?..
[quot]Я бы, все-таки, обошелся бы в этом случае только одной таблицей с чековой колонкой.
Т. е. вот так... ?
Таблица №1
ID Name Check
1 test1 True
2 test2 False
3 test3 False
4 test4 True
Заманчиво, конечно... :) А если нужно будет ещё ввести Check2, Check3 и т. д.?

Это вообще нормально, не экономить на столбцах с Boolean-значениями? А то я новенький, может велосипед изобретаю?.. :)

Прошу прощения, напортачил с цитированием... :)

2 tpg,
Спасибо за отзыв! :)

Alexey Kudinov
1 будут храниться только True/False или еще и значение "не определено" (NULL) ?
Только True или False во всех колонках boolean-значений базы данных.

2 %-ные соотношения True/False соизмеримы ? Т.е. какое соотношение True к False ? 60 к 40 или 98 к 2 ? Если ответ на п.1 утвердительный, то сколько значений "не определено" ожидается по колонке ?
Точно процентное соотношение не извесно. "На глазок" параметров True будет не более чем 1 True к 3 False.

3 насколько вероятно появление других колонок (этих самых Check2, Check3...) и сколько их может быть ? Для каждой из этих колонок ответить на первые 2 пункта.
Будет как минимум 2 "Check"а. Появление "Check3" очень маловероятно. %-ное соотношение True-False в Check2 будет (примерно) ещё меньше чем в "Check1".

Как видите, я предложил Вам задуматься (для начала :) ) над 3 пунктами и не дал ни одного совета. Все дело в том, что ответы на эти вопросы сильно влияют на результат.
Да, я понимаю. Информацию, которая должна хранится в БД я уже обдумал. Просто не стал перегружать лишними (как мне показалось) сведениями учасников форума... Но, если хотите, могу описать более подробно... Даже буду рад поделиться мыслями. :)

Alexey Kudinov,
Спасибо!
А по этому вопросу что-нибудь можете подсказать?..
...А может есть в SQL какая-нибудь штука, позволяющая при сведении таблиц "виртуально" добавлять столбец и "заполнять" его данными, на основе чего-то?.. Было бы просто фантастиш, если бы при сведении таблиц 1 и 2, можно было бы добавить столбец Check и заполнить его значения на основе таблиц 1 и 2: строки из первой - Check = True, строки из второй - Check = False. При добавлении запись помещается в соответствующую таблицу, а при изменении CheckBox'а, при обновлении или завершении работы с таблицей запись бы перемещалась (или оставалась на месте, если значение в конце концов небыло измененно).
Есть в SQL что-нибудь подобное?.. Или есть, но это будет менее эффективно?..