lavrenov,
Тут проектировщик стоит перед выбором в плане оптимальности.
Например, Решение 2 выглядит более адекватно в логическом плане, поскольку если свойство отсутсвует, то луче чтобы его структурно не было возможности внести в принципе. Это своего рода ограничение целостности. Но таблиц больше.
Кроме того, из соображений упрощения поддержки ограничений целостности, возможно, наоборот, в таблице Люди сделать внешние на женщин и мужчин, поскольку в этом случае легче организовать ограничение на то, чтобы чел не оказался и мужчиной и женщиной( правда тада появится Нуллы, в этих колонках). Но, например, ограничением на значение можно добиться, чтобы не был не Нулл на обоих: т.е. человек типа и мужчина и женщина . А если сделать как Вы решили, то, скорее всего, контролировть это будет более сложно, поскольку нужно просматривать таблицы мужчины и женщины. Но в Вашем варианте зато не будет Нулл и вообще проще структура.

Паганельvadiminfoчтобы чел не оказался и мужчиной и женщиноймужчинам только четные ID генерировать, а женщинам - только нечетные
всё
Этот подход тоже имеет издержки типа:

Это не ограничение целостности, а ограничения на ввод определенной программой суррогатного ключа. Т.е. в общем случае теперь надо проверять, что у мужчин не оказались нечетные, у женщин четные какой бы прогой данные не вводились, и той, что не знает ничего о правиле генерации. Тем более что суррогатный ключ изначально не предполагает каких-то правил связанных с предметной областью (мужчина четнное значение, женщина - нечетное ). Главное чтобы он был уникальным. В общем как бы ОЦ все равно желательна.

Это не достаточно "семантично", поскольку не декларативно: если декларативеное ОЦ в МД видно, то про четеность и не четность нужно приложить больше усилий чтобы догадаться, тому кто ниче не знает об этом.

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

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

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

А мы же не можем быть уверены на начальном этапе в том, что этого потом не произойдет?


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


Т.е. проектировщик, скорей всего, все равно остается перед выбором.

Паганель,

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