Бредятинаsergei64_89И все же остается вопрос как вставлять данные в эти таблицы по второму варианту.люди связаны с таблицами мужчины и женщины связью один к одному,но один человек не может быть одновременно и тем и другим,соответственно связь один к нулю или к одному.здесь получается что каждый человек и мужчина и женщина.
Хороший вопрос. Но он относится и к первому варианту тоже: как вводить значения "правильных" характеристик для конкретного человека? К сожалению, на уровне СУБД решения нет, только на уровне приложения.Я вот не понял вопроса sergei64_89...

Конечно, для вставки данных нужно сделать INSERT, поэтому правильный ответ - "вставка данных возможна только на уровне приложения".

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

Бредятинаalexeyvg
Я вот не понял вопроса sergei64_89...
Конечно, для вставки данных нужно сделать INSERT, поэтому правильный ответ - "вставка данных возможна только на уровне приложения".
Но, конечно, чтобы не получались ситуации "человек одновременно и мужчина и женщина", нужно сделать соответствующий констрейн.
Какой констрейн? Проблема в слове "одновременно". Мы сейчас далеко зайдем. Так как очевидно, что "не одновременно" человек может быть мужчиной и женщиной. Впрочем, одновременно тоже может:) На первый взгляд необходима какая-то специфическая характеристика в "головной" таблице, значение которой будет "направлять" нас правильным образом. Но ведь значение этой характеристики тоже меняется.Обычный констрейн, не позволяющий создать для записи в головной таблице записи сразу в двух таблицах "ЭМ" и "ЖО" :-)

sergei64_89Это ситуация описывает супертип подтип.но вот как реализовать при связи один к нулю или к одному я так и не понял.если кто знает,то поделитесь

3 таблицы:
люди(ид, тип, фио)
студенты(ид, тип, номер зачетки)
преподаватели(ид, тип, должность)

В каждой таблице 2 ключа:
ид (ПК)
ид, тип (АК)

Таблицы студенты, преподаватели ссылаются (ФК) на люди
В таблицах студенты, преподаватели делается дополнительно чек-констрейн на поле тип

Бредятинаalexeyvg
3 таблицы:
люди(ид, тип, фио)
студенты(ид, тип, номер зачетки)
преподаватели(ид, тип, должность)

Не красиво ид, тип (АК) в первой таблице. Станет студент преподавателем:)... А тип в двух других таблицах, наверное, одинаковый для всех записей?Этот способ позволяет надёжно, встроенными средствами любой СУБД решить поставленную задачу. Станет студент преподавателем, будет учить, как правильно строить модели данных :-)

Поле тип не выходит за рамки этих двух таблиц (разве что фильтр сделать), все ссылки будут только на поле "ид".

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

По моему, типовая схема, я её лет 10-15 использую - с помощью всего-лишь АК и ФК обеспечить целостность данных для .
Решение "К сожалению, на уровне СУБД решения нет, только на уровне приложения." считаю неправильным - если есть возможность простыми встроенными средствами СУБД обнспечить целостность, её нужно использовать. Знаем мы это "на уровне приложения" :-)

БредятинаНе годится. Что же Вы игнорируете объяснения?:)Игнорирую, потому что вы не объясняете, а только говорите, что заете, как в таких случаях надо делать :-)

Буду благодарен за альтернативные варианты.

sergei64_89подскажите что есть АКАК - это альтернативный ключ.

В конкретных реализациях СУБД это может быть уникальный констрейн или уникальный индекс.

Бредятинаalexeyvg
Этот способ позволяет надежно, встроенными средствами любой СУБД решить поставленную задачу. Станет студент преподавателем, будет учить, как правильно строить модели данных :-)
Поле тип не выходит за рамки этих двух таблиц (разве что фильтр сделать), все ссылки будут только на поле "ид".

Не позволяет. Вообще не позволяет. Но Вы продолжаете игнорировать замечания, или отделываетесь шутками:) Тоже вариант, конечно, Жаль, если единственный:)"Не позволяет." и даже "Вообще не позволяет." - это не аргумент.

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

Это нонсенс. Даже ради "встроенных средств". Поддерживать одно значение атрибута для всех записей."Нонсенс" - тоже не аргумент.

Ради поддержки целостности наиболее экономичным, простым и надёжным способом я пойду даже на это :-)

Ваше альтернативное решение, как я понял, это забить на целостность ради отсутствия неких абстрактных "нонсенсов"?

Бредятинаalexeyvg
По моему, типовая схема, я её лет 10-15 использую - с помощью всего-лишь АК и ФК обеспечить целостность данных для .

А здесь не проходит. Человек может быть и студентом, и преподавателем.1. Если исходить из постановки задачи ТС, то человек не может быть и студентом, и преподавателем.

2. Если расширить постановку задачи, и человек может быть и студентом, и преподавателем, то это значит (расшифровываю), что человек может иметь объединённый набор атрибутов студента и преподавателя.
В этом случае нужно добавить значение типа "студент_преподаватель" и разрешить добавлять такие записи в обе дочерние таблицы.
И заодно завести тип "никто", каковым отмечать людей, не являющихся ни студентом, не преподавателем.

Бредятинаalexeyvg
Буду благодарен за альтернативные варианты.
Я бы почти наверняка хранил бы все в одном объекте. Ограничений на количество характеристик объекта ("колонок" в "таблице") никаких нет в нормальной СУБД. Сгруппировать характеристики просто (это даже сам пользователь может сделать). Нет проблем для той ограниченной постановки, которая прозвучала.Я бы тоже почти наверняка так сделал для данной задачи (хотя нужны детали постановки).

Но часто делал и так, как описывал.

Если у студентов и преподавателей 3 общих атрибута и по 50 непересекающихся, то 100 полей стиля "здесь читаем а здесь рыбу заворачивали" не пойдёт на пользу системе.

Тимичный пример применения - всякие документо-ориентированные системы.

Бредятинаalexeyvg
2. Если расширить постановку задачи, и человек может быть и студентом, и преподавателем, то это значит (расшифровываю), что человек может иметь объединённый набор атрибутов студента и преподавателя.
В этом случае нужно добавить значение типа "студент_преподаватель" и разрешить добавлять такие записи в обе дочерние таблицы.
И заодно завести тип "никто", каковым отмечать людей, не являющихся ни студентом, не преподавателем.

Ага. Когда я Вам это сообщил, Вы проигнорировали. И что же, Вы серьезно считаете эту логику, о которой написали, не элементом приложения?Приложение - это код на клиенте (в т.ч. на сервере приложения).

А я говорю про необходимость по возможности реализовать целостность на уровне ограничений модели данных. Вот в данном случае эта возможность есть, я её описал.

"разрешить добавлять такие записи " - это я же говорил не про код в приложении.

Бредятинаalexeyvg
Если у студентов и преподавателей 3 общих атрибута и по 50 непересекающихся, то 100 полей стиля "здесь читаем а здесь рыбу заворачивали" не пойдёт на пользу системе.

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

На вопрос ТС, как лучьше реализовать указанное им решение №2, я привёл вышеописанный вариант. По поводу сравнения вариантов №1 и №2 я вообще не высказывался - не имею достаточно данных.

А как я сделал-бы сам - это конечно зависит от условий задачи - я делал по разному...

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

Констрейны это всё будут хоть немного сдерживать.