В каком типе переменной хранить (м\ж) пол?

Question

[Andrey Plax]

В каком типе переменной хранить пол, bool, enum (перечисление), другие варианты? И почему?
Пишу на C# и вроде бы запросто можно изпользовать булево :) Но посоветовался с опытным 1С-ником, а он говорит, что ни в коем случае!!! Что в 1С и пол и Юр.Лицо\Физ.Лицо и прочие подобные параметры - это перечисления из 2 значений. Но разве не проще:
bool isWoman = true (or false) ;
???
Заранее, спасибо всем, кто адекватно ответит!

Comments

[Алексей Немиро]

Я обычно делаю так :-)

bool - однозначно нет.

На уровне БД можно хранить маленькие числа, типа byte, smallint или еще что-то типа этого.

[abcd0x00]

bool не пойдёт, так как нужно иметь три состояния - мужской, женский и неизвестный.

[Алексей Немиро]

abcd0x00: true, false, null - но гибкости не будет. Зачастую, помимо М и Ж, могут возникнуть дети, младенцы, и как было сказано, разделение на юридических, физических лиц и т.п. Так что проще сразу использовать перечисления, чтобы потом не пришлось переделывать :-)

[abcd0x00]

Алексей Немиро: нехорошо, хранить людей с нелюдьми. Лучше распределить всё по разным таблицам. Таблица людей, таблица предприятий.

[Алексей Немиро]

abcd0x00: дети вроде как люди, на них bool не хватит :-) Можно городить множество полей и хранить все отдельно, но для этого придется делать большую работу. Если заранее учитывать, то тратить время в пустую. Практика показывает, что М и Ж бизнесу мало, и заранее неизвестно, что понадобится. В молодости гендерные bool приходилось меять. Разделением тоже как-то занимался - идиотизм полный, ибо делить можно бесконечно. Вот так бывало нужно отправить в API пол человека, у тебя для этого десять полей: пол, возраст, обращение и т.п. с портянкой условий, а в API всего одно числовое или строковое значение.

Лучше перечислений для подобной задачи еще ничего не придумали :-) Хранение бесполезных точных данных, типа возраста, не имеет смысла, если эти эти данные понадобятся только для одноразового определения является человек ребенком и в какую возрастную группу он попадает (портянка условий) и для прочих разделений.

[abcd0x00]

Алексей Немиро: ты пытаешься в колонке пола хранить тип человека (мужчина, женщина, ребёнок, бабушка), а нужно две колонки иметь - пол человека и возрастной тип. Если нужно будет у ребёнка сохранить пол, ты что будешь делать? Ты будешь достраивать что-то там, и в конце получится какая-то индусская картина, потому что поменять ты не сможешь ничего, из-за того что много кода будет полагаться на изначальную архитектуру базы данных. Ещё хреновее - хранить пол у организации, у которой вообще пола нет. В таких случаях у тебя будет типа заполнитель несуществующей колонки, что является затычкой, которые потом накапливаются и вообще всё тормозят.

[Алексей Немиро]

abcd0x00: В больших базах каждый байт на счету, нужно взвешенно подходить к проектированию. Один байт (true | false) против одного байта (0-255), ну или двух, если значений будет не хватать. Последний явно дает больше возможностей для развития. Если все станет плохо, то конечно, придется делать существенные доработки или даже новую базу. Но такого по идее быть не должно, поскольку хоть какая-то информация о проекте перед началом разработки должна быть и можно учесть многое. Мне еще ни разу не приходилось переделывать перечисления, а вот bool - да. Единственное, с масками нужно осторожней быть, не увлекаться сильно, а лучше не использоваться совсем (с большими значениями и вычислениями в больших базах можно существенно потерять в производительности).

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

Из практического примера - системы бронирования авиабилетов. На поверхности у них четыре типа пассажиров: младенец, ребенок, взрослый мужик и не менее взрослая баба. И далее могут быть разные вариации типов пассажиров. Все в одном перечислении. Хотя конечно, это не пол как таковой, но используется для идентификации пола. Мне попадались различные ужасные вариации реализации этого, а в крупных проектах приходилось тотально все переделывать. Всего-то можно было изначально сделать одно простое перечисление :-)

Если границ развития проекта никаких нет, то да, будет лучше все разделить, точнее скорее строить вертикально. Но количество подобных проектов-монстров в меньшинстве и это другой уровень, другие ресурсы. Обычно все просто. Десяток вариаций «полов» и никаких bool :-) Если СУБД позволяет, можно автоматизировать распределение хранения данных по разным признакам. Все должно быть просто и быстро.

Строки тоже иногда используются. Это в принципе неплохо, если база небольшая и работать приходится с сырыми данными. Для небольших проектов в целом без разницы как хранить данные, переделать будет проще.

[abcd0x00]

Алексей Немиро:

Из практического примера - системы бронирования авиабилетов. На поверхности у них четыре типа пассажиров: младенец, ребенок, взрослый мужик и не менее взрослая баба. И далее могут быть разные вариации типов пассажиров. Все в одном перечислении. Хотя конечно, это не пол как таковой

Да, это не пол, это тип или класс пассажира. Просто тебе пол не нужен и как бы ты его узнаёшь иногда только.

А вот теперь представь, что через 10 лет использования такой базы у тебя появляется новый самолёт, где два туалета - мужской и женский. И тебе нужно составить запрос, сколько человек посетило женский туалет за год. И ты что будешь писать? Правильно, ты будешь сидеть и набирать эти поля вручную, выбирая из них, кто женщина, кто не женщина, а кто вообще - стиральная машина. А все потому, что тебе нужно было сделать таблицу людей и таблицу билетов, и просто соединить эти две таблицы изначально, а ты решил сэкономить типа "а что будет".

[Алексей Немиро]

abcd0x00: почему же, будет обычное условие :-) ...WHERE pass_type = FEMALE С детьми возникнут проблемы, если изначально их не разделять по гендерному признаку.

Люди и билеты, как правило, в разных таблицах. Смешивать их нет смысла, это совсем разные структуры.

Но даже если каким-то образом все это окажется в одной таблице, выборка будет аналогичной.

Если типов людей немного и использовать маски, то все совсем просто:

-- слова вместо чисел, просто для примера
WHERE (pass_type & 'FEMALE') = 'FEMALE' -- только женщины
WHERE (pass_type & 'FEMALE') = 'FEMALE' AND (pass_type & 'CHILD') = 'CHILD' -- дети женского пола
WHERE (pass_type & 'FEMALE') = 'FEMALE' AND (pass_type & 'INFANT') = 'INFANT'

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

Для небольших баз такой вариант может быть удобным, если типов людей будет не больше 10-15 (2¹⁰) и данных немного (с несколькими гигабайтам проблем точно не должно возникнуть, даже на слабом железе).

Возможные ситуации с полами. Например, если изначально были М, Ж и пол не указан. Может потребоваться расширить этот список, сделать несколько вариантов "пол не указан". Если использовать bool, то придется добавлять дополнительное поле, которое будет содержать информацию, почему пол не указан, или переделывать в int. А в перечисления достаточно добавить нужные элементы в список и все: пол не указан, потому что гладиолус; луна находилось в неправильном месте; пользователь пьян; пользователь не дошел до выбора пола; facebook не вернул информацию о поле пользователя; пользователь отказался отвечать на вопрос и т.п. Бредовый список, но как минимум два варианта "пол не указан" в реальных условиях может быть: не выбран и null.

[abcd0x00]

Алексей Немиро: я где-то выше писал, что должно быть как минимум три возможных значения для пола - мужской, женский и неопределён. Поправлю себя же: должно быть четыре варианта - мужской, женский, неясный и значение не задано. Так что bool тут точно не подходит. Но вот хранить в поле пола, что у него пол - ребёнок, это как раз не даёт у детей задавать пол. И это вылезет, когда потом потребуется выборка именно по полу.

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

Answer 1

[Толстый Лорри]

ИМХО, расточительно делать отдельную таблицу под пол. Отлично подойдет (если не уходить в дебри человеческих отклонений):

enum Sex { 
    Male,
    Female,
    Undefined
}

bool? - тоже вариант, но читается хуже.

Answer 2

[Петр]

По причине сумасшествия в современном обществе, "пол" лучше хранить в int и для значений использовать отдельную таблицу.

Comments

[Andrey Plax]

Ну, не могу не согласится. Аргумент весомый! :)

[lxfr]

Andrey Plax: INT 11 :)

Answer 3

[Александр Владимирович]

Международный стандарт ISO 5218 описывает представление человеческих полов. Он может быть использован в информационных системах и базах данных.

4 кода, определённых в спецификации стандарта, выглядят, как:

0 — неизвестно
1 — мужчина
2 — женщина
9 — неприменимо

https://ru.wikipedia.org/wiki/ISO_5218

Answer 4

[Константин Нагибович]

1C-ник правильно вам сказал - для таких случаев в 1С используются перечисления. Так проще сопровождать. Не придется разбираться кто есть кто - мужчина или женщина.

Comments

[Lander]

Всё просто 0 - женщина, 1 - мужчина! Логично же! Или вы разъёмы "мама" и "папа" тоже по справочнику смотрите?

[Константин Нагибович]

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

[Lander]

Константин Нагибович: Ну если опасаться феминисток, когда однозначно enum('WOMAN', 'men'). :)))

[Константин Нагибович]

Lander: ну вот вы и попали в категорию "подкаблучников" )))

[D']

Константин Нагибович: а если так: enum('wo', 'man') ?

[Lander]

Константин Нагибович: Какая тонкая грань между женоненавистником и подкаблучником :)))

[h8nor]

D' Normalization: вполне логично. У высших приматов самец и самка.
Lander, Константин Нагибович Вообще касательно граней есть картинка :3

Answer 5

[iv_k]

как это делает фейсбук

www.independent.ie/business/technology/facebook-ad...

скоро и инта может стать мало =)

Comments

[h8nor]

Не понятно, как субкультура попала в раздел биологического пола. Кто-то наигравшись в варик может считать себя эльфом или орком :3

Answer 6

[ArXen42]

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