Пол типа Boolean

[CD_Eater]

Допустим, вам заказали разработать некую систему, хранящую личные данные клиентов, и в ТЗ написано, что пол клиента (взятый из паспорта, так что возможны только два варианта) должен кодироваться значением типа Boolean.

Вопрос: Как вы закодируете пол человека значениями True/False?

1. True - это мужской пол		36	(64.29%)
2. True - это женский пол		20	(35.71%)
Всего:		56

@темы: Вопрос

Comments

[Скептичный циник]

ТЗ на помойку.
А как же "неизвестно"?
Да и boolean не подходит для хранения пола ибо кто-нибудь сделает проверку типа

if (!user.gender) { ... exception ... }

и тушите свет.

[Aista]

Если представить это не как True и False, а как 0 и 1, то ответ напрашивается сам собой

[CD_Eater]

Скептичный циник,

ТЗ на помойку.

а по-моему, вполне логичное требование: пол должен быть всегда известен
когда клиент предъявляет паспорт и оператор вводит его анкетные данные, пол ОБЯЗАН быть введён
если анкета успешно введена в базу - это значит, что пол клиента гарантированно заполнен, никаких проверок "известен ли пол" при дальнейшей работе не требуется

[Aguinore]

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

[Скептичный циник]

> вполне логичное требование: пол должен быть всегда известен
Требование – логичное, но метод его решения выбран опасный.
Валидация в ORM или в domain logic при сохранении/обновлении модели справится с этим лучше.
Или хоть в реляционной базе NOT NULL/ENUM.
Но никак не nullable-значением. А строкой/числом/usw уже не так важно.

[Aista]

существуют гермафродиты и прочие разные трансгендеры

И часто вы видите такие паспорта? оО

[Скептичный циник]

Aista, в Германии такие паспорта есть – у них не обязательно указывать пол ребёнка, например, если он родился интерсексуалом. А раз такой прецедент есть, то любой (по крайней мере, для системы учёта), кто меняет паспорт, имеет право эту графу оставить пустой.
Слышал, что в других странах тоже что-то подобное есть (например, Пакистан), но лично не встречал.

[Kakou ECTb]

мужик тру, не мужик - фолс. о чём тут думать

если вдруг понадобится добавить третий пол, то поле легко переименовывается в sexType, где 0 и 1 уже известны. а н астороне бизнесс логики всё это конвертится в enum с мапингом.

[pferdchen ist tot]

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

Я хз, нас за такое препод по сям бил канделябром по ебалу

[Aguinore]

*yoru*, поработав с кровавым ынтерпрайзом, могу сказать, что тут чуть ли не на каждом уровне есть перепроверки на известность номера договора или чего угодно еще. Из-за этого код становится трудно читаемым, но зато защищенным от сбоев.

[CD_Eater]

Скептичный циник,

Или хоть в реляционной базе NOT NULL/ENUM.

Разумеется, один из самых естественных вариантов хранения значения пола в БД - это в столбце с констрейнтом not null.
А разве это как-то противоречит требованиям ТЗ?
Если вы не знали, типа Boolean нет в классическом SQL (в MySQL, MS SQL, Oracle нельзя сделать столбец типа Boolean в таблице).
Так что речь идёт о внутреннем представлении данных в программе, а не о способе его хранения в БД.

данные, загруженные из БД, гарантированно валидны (за валидность отвечают констрейнты и процедуры проверки, обычно сидящие в триггерах БД)
откуда же у вас навязчивая идея всё ещё раз перепроверять, разбавляя код вставками типа
if (!user.gender) { ... exception ... }

Но никак не nullable-значением.

Шо, простите?
у вас фобия - боязнь хранить нули в целочисленных типах? )))

[CD_Eater]

*yoru*,

А защита от дурака, сбоя, фазы луны, чего угодно?

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

[Скептичный циник]

CD_Eater, РСУБД привёл просто в качестве одного из многих примеров, для любого другого случая есть свои методы. Да и использовать определение "классический" и наименования серверов вместо наименования стандартов – некорректно. Особенно mysql, застрявший в 93 году, но допиливающий в свой стандарт что попало.

> откуда же у вас навязчивая идея
Контракты и модульная/библиотечная структура. Я, как разработчик модуля, понятия не имею что взбредёт вызывающему коду передать в мою функцию, в каком контексте он будет использован и будет ли там вообще использована РСУБД с триггерами. Соответственно, гарантий корректности значений – нет.

> у вас фобия - боязнь хранить нули в целочисленных типах?
Я про ситуации, когда в enum'ах любого вида используют nullable-значения для данных, когда там возможна ситуация "отсутствие значения". Особенно, когда это происходит в языках с динамической/утиной типизацией.

Например, при добавлении возможности пустого/третьего значения рефакторинг мест типа

// М
if (user.gender) ...
// Ж
else ...

превращается в боль, а передача туда "неизвестно" вместо "Ж" плодит сложноуловимые баги. Такой код обязательно кто-нибудь напишет, если изначально подразумевается bool и "поле легко переименовывается в sexType, где 0 и 1 уже известны" не спасёт.

Конечно, делать switch..case для пола это перебор, когда у вас лендинг для россиян, а не махровый немецкий энтерпрайз. Но в посте ничего не сказано о контексте.

> Дураки, сбои, фазы луны не могут обмануть валидацию данных в БД, проводимую хранимыми процедурами.
На клиенте проверки нужны от очепяток. На сервере/базе – для целостности данных. А теперь представьте, что с одной базой работают разные приложения или одно, но разных версий. Внутри триггера будете хардкодить приложения и их версии/фичи и делать громоздкие if..else/switch..case? А если я данные в redis храню?

[CD_Eater]

Скептичный циник,

Я, как разработчик модуля, понятия не имею что взбредёт вызывающему коду передать в мою функцию

а как же презумпция невиновности?
в доках смело пишете "функция работает правильно на любых корректных входных параметрах" и вешаете ответственность на того, кто ваш модуль использует
иначе утонете в ваших if-ах )))

А теперь представьте, что с одной базой работают разные приложения или одно, но разных версий. Внутри триггера будете хардкодить приложения и их версии/фичи и делать громоздкие if..else/switch..case?

как вы себе это представляете?
на БД одна бизнес-логика, а каждое клиентское приложение имеет какую-то свою? )))
отсутствие такого разброда и шатания гарантируется архитектором проекта (а вы думаете, откуда к вам ТЗ свалилось?)
изменения бизнес-логики, когда они появляются, обязательно вносятся в первую очередь в БД, что гарантирует совместимость клиентов обеих версий с базой
или вы живёте по-старинке: у каждого клиента есть право на insert/update в любую таблицу, а по вопросам корректности данных база верит на слово клиентским приложениям?
такие динозавры архитектуры уже давно все вымерли ))))

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

передача туда "неизвестно" вместо "Ж" плодит сложноуловимые баги

очевидно, что для переменных, которые по смыслу должны быть всегда определены (как пол), не следует использовать типы данных, которые могут хранить значение "неопределено", нужно использовать более подходящие типы данных
если ваш язык - без контроля типов (с динамической типизацией), то эта проверка ложится на совесть программиста, но она не должна выражаться в виде вставки if-ов при каждом удобном случае! ))))
похоже, вы используете динамический ЯП, но образ мышления у вас остался старый, от статической типизации, поэтому страх "а вдруг там null" заставляет вас каждый раз отложить ещё один кирпич написать ещё один if, когда вам страшно
правильный выход - грамотная документация и делегирование ответственности
иначе вы так никогда и не познаете прелести языков с динамической типизацией, будете воспринимать их как неудобные языки, требующие писать больше кода, хотя на самом деле программы на динамических ЯП короче, и писать их удобнее
в динамических ЯП вам просто дали больше свободы и выразительной силы (мощности языка), при этом и чуть больше ответственности

А если я данные в redis храню?

А когда это redis стал считаться полноценной БД? )))
Вы с таким же успехом можете хранить ваши данные в обычном массиве.

[Скептичный циник]

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

> у каждого клиента есть право на insert/update в любую таблицу
Такие динозавры, конечно, вымерли, но их код ещё работает и с ним, особенно в госструктурах, приходится работать.

> очевидно, что для переменных, которые по смыслу должны быть всегда определены (как пол)
Всем ведь, конечно же очевидно, что пол человека всегда определён, что у пола всего два значения, что более одного официального имени быть не может, что имена не содержат цифр, что не существует людей без имён вообще, что в месяце 30-31 день, что в сутках всегда 24 часа, что ... а потом _внезапно_ оказывается, что нифига подобного. Такие мелочи потом дороже выходят.

> "а вдруг там null" заставляет вас каждый раз написать ещё один if
Динамическая типизация, как вам известно, не видит разницы в if между 0 и null. Значит, нужно либо делать типозависимые сравнения (и научить всю команду так делать только для одного поля), либо просто использовать инкремент enum не с 0, а с 1 и далее. Выбирая первое, "не познаете прелести языков с динамической типизацией" (: Второе проще и меньше багов.

> А когда это redis стал считаться полноценной БД?
Неужто есть стандарт, описывающий критерии "полноценности" и ведущий постоянно обновляемый список таких продуктов? (: Необоснованно вангую, что это вы про реляционность. Тогда это уже холивар – куда пихать доменную логику. Я предпочитаю в сервисы работы с репозиторием, которые использует модель.

> Вы с таким же успехом можете хранить ваши данные в обычном массиве.
Слишком много геморроя чтобы сделать shared memory персистентной (: Всё это уже изобретено до нас в виде той же redis/mongo/couch/.... И в некоторых случаях документоориентированность – плюс.

[CD_Eater]

Выброшенное исключение в коде заметнее строчки в доках

предлагаете засирать код каждой функции if-ами вместо одной внятной строки в доках?
ну-ну...

Всем ведь, конечно же очевидно, что пол человека всегда определён, что у пола всего два значения

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

Динамическая типизация, как вам известно, не видит разницы в if между 0 и null

вы неправильными языками пользуетесь
В Lua, например, if видит эту разницу
только при правильном подходе вам не придётся сравнивать 0 и null

Неужто есть стандарт, описывающий критерии "полноценности" и ведущий постоянно обновляемый список таких продуктов?

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

[SpiritOK]

Помнится, на ithappens предлагали для случая boolean вместо поля sex использовать поле HasPenis. If (client.HasPenis) даже звучит естественнее, и частично решает проблемы гермафродитов, кстати

[CD_Eater]

If (client.HasPenis) даже звучит естественнее, и частично решает проблемы гермафродитов

бывают случаи ампутации полового члена из-за опухолей или травм, при этом пол человека не меняется

[SpiritOK]

Не надо придираться к биологии, там и так не всё логично.

Причина всех плясок вокруг паспортного пола, имхо - в необходимости хорошего экспертного признака на допуск к каким-то активностям и/или льготам, в идеале максимально дискретного, для определения которого не нужно проходить психологический опросник на соотношение всех возможных полов. Обычно этим признаком является именно содержимое штанов. Есть член - отлично, к нему обычно идут определённые морфологические особенности, которые способствуют службе в армии, например. Нет члена - отлично, предполагаем другие особенности, с которыми в армии делать нечего.
Кстати, одной из официальных статей негодности для армейской службы идёт именно отсутствие члена, даже при букве М в паспорте. Такие дела.

Странно, что ещё не набежали феминистки с воплями о том, что графу "пол" вообще нужно отменить, потому что все могут всё, и разграничивать людей на Эм и Жо это сексизм. Сорри, наболело

[CD_Eater]

Причина всех плясок вокруг паспортного пола, имхо - в необходимости хорошего экспертного признака на допуск к каким-то активностям и/или льготам

всё проще: закон (и общественная мораль) различает людей по признаку биологической способности к деторождению (вследствие значимости таких людей для общества), именно для этого и нужен признак "пол".

правда, сейчас, в эпоху феминизма, графа "пол" в паспорте вообще ничего не гарантирует насчёт этой значимости
это частный случай очень распространённой ситуации: человек действует прежде всего в интересах собственного профита, а не ради выполнения возлагаемых на него общественно-полезных функций
очевидный пример: всевозможные коррумпированные чиновники, судьи, менты
менее очевидный пример: женщины, которым дали право "быть хозяйкой своей пизды" и избавили от давления общественной морали, не утруждающие себя деторождением

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