Стою перед выбором способа реализации наследования


1й вариант - имеем поля каждое ссылающееся на потомка
2й вариант - имеем одно поле ссылающееся на всех потомков и поле описывающее тип связи


Непойму какой вариант лучше и чем.
Помогите пожалуста советом и опытом

Спасибо

MasterZiv
sp wrote:
> 1й вариант - имеем поля каждое ссылающееся на потомка
> 2й вариант - имеем одно поле ссылающееся на всех потомков и поле
> описывающее тип связи

Поясните детальнее. Что-то бред какой-то у вас тут написан.
Posted via ActualForum NNTP Server 1.4

Имеем к примеру сущности

MasterZiv
sp wrote:

> Имеем к примеру сущности
Оба неправильные. поищите по форуму, обсуждалось много раз.
Posted via ActualForum NNTP Server 1.4

а как хоть темы сформулированы были? как искать?

MasterZiv
sp wrote:

> Имеем к примеру сущности
Оба неправильные. поищите по форуму, обсуждалось много раз.
Posted via ActualForum NNTP Server 1.4

если Вы знаете как правильно - наверное лучше было бы мысль свою тут изложить а не отсылать ко всему интернету в сибири весь снег убирать! :)

там столько бредятины - я уже 2й час всякую чушь читаю а зерна так и не нашел

ткине где можно об этом почитать плз

Спасибо за то что поделились опытом!

думаю остановлюсь на 1м варианте, потому как других типов телефонных номеров не планируется в ближайшее десятилетие:)

474 BelyА почему вы вобще разделяете мобильные и стационарные телефоны?
Я думаю, что это просто неудачный пример .
spИмеем к примеру сущности
Наследования у телефонов я вообще не представляю...

Если у человека в руке молоток - все что он видит вокруг ему кажется гвоздями :)
так это Вам видится неудачным примером - Вы не с той стороны на телефоны смотрите - нам такое разделение необходимо для рассылки оперативных SMS - и скажите теперь что это неудачный пример!!!!

NafЯ все же за второй вариант. Причем первичный ключ дочерней таблицы является внешним ключом ко второй таблице (к его первичному ключу). Таким образом их первичные (суррогатные, конечно) ключи совпадают.
С уважением, Naf

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

474 spЕсли у человека в руке молоток - все что он видит вокруг ему кажется гвоздями :)
так это Вам видится неудачным примером - Вы не с той стороны на телефоны смотрите - нам такое разделение необходимо для рассылки оперативных SMS - и скажите теперь что это неудачный пример!!!!
Я вообще-то имел в виду не разделение, делите ради бога, а то, что для иллюстрации наследования вы выбрали именно телефоны. Ну, какой-то сложный пример. Трудно понять, что значит наследование для телефонов.

возможно Вы и правы

Bely spЕсли у человека в руке молоток - все что он видит вокруг ему кажется гвоздями :)
так это Вам видится неудачным примером - Вы не с той стороны на телефоны смотрите - нам такое разделение необходимо для рассылки оперативных SMS - и скажите теперь что это неудачный пример!!!!А накой вам вобще наследование в БД?

Дабы унифицировать ввод - для всех объектов не описывать в тысячный раз телефоны и в UI однажды создав класс Телефон не мучаться с копированием интерфейса и дублированием функционала.
А еще как вы в одной таблице совместите противоречивые данные
А таблица Телефоны может содержать их и для ссылки на телефон нужен всего один ID

Bely spкакто сложно Вы выразились - не понятно кто первый кто второй и какие ключи
мне кажется что со вторым вариантом хуже - потому как поменяй нескоко раз поле "тип телефона" и уже не вспомиш из какой таблицы ключ, а так все четко и понятно и никогда не потеряешся :)А вы для всех объектов всех типов введите сквозную нумерацию.
Даже если 10 раз поменяете тип - в других таблицах не окажется записей с таким ID.

Это несколько усложнит обработку данных

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


Однакоже странный подход к проектирования - сделаем структуру данных абыкак а в интерфейсной части все выправим!!??


Если это ДОПОЛНИТЕЛЬНЫЕ ДАННЫЕ, то они могут храниться вообще в отдельной таблице.

Так и есть - сущность телефон выделяется в эти 3 таблицы и может являться дополнительным аттрибутом любого объекта


Сейчас вы говорите так, как будто телефонный номер - это свойство какого-то третьего объекта.
Но к наследованию - это вобще никак не относится.
Этож как же ??? разве структура Телефон -> {Телефон стац. | Телефон мобю.} не является наследованием????


И еще. Реализуя в БД наследуемость так же как в C++/C# и прочих языках - вы роете себе яму.
Когда вопрос встанет, чтобы было не просто "красиво", а еще и "быстро" - переделывать красоту будет поздно.
впервые слышу о том что правильно спроектированная система будет не быстрой

Bely sp И причем здесь структура таблицы?
Интерфейс, классы и все прочее - может быть какими угодно.
При этом структура таблицы для всех телефонов может быть одна.
Есть слой хранения данных.
Есть слой отображения данных.
Однакоже странный подход к проектирования - сделаем структуру данных абыкак а в интерфейсной части все выправим!!??Перевираете мои слова.
Надо сделать структуру данных ПРАВИЛЬНО с точки зрения ХРАНЕНИЯ и ОБРАБОТКИ ДАННЫХ.
При проектировании - не надо оглядываться на програмный интерфейс.

А интерфейс можно заставить работать с любой структурой данных.
Просто логику работы с БД надо будет сделать отдельным методом (если это объект).

sp
Сейчас вы говорите так, как будто телефонный номер - это свойство какого-то третьего объекта.
Но к наследованию - это вобще никак не относится.
Этож как же ??? разве структура Телефон -> {Телефон стац. | Телефон мобю.} не является наследованием????Я бы сказал, что "Телефон стационарный, с номером : 728-4004" - это экземпляр класса "Телефон". У этого экземпляра есть свойство "Стационарный".
Я пока так и не вижу чем отличается для вас стационарный телефон от мобильного.
а наличие у объекта свойситва "Стационарный / Мобильный" - не делает его разными классами.

sp
И еще. Реализуя в БД наследуемость так же как в C++/C# и прочих языках - вы роете себе яму.
Когда вопрос встанет, чтобы было не просто "красиво", а еще и "быстро" - переделывать красоту будет поздно.
впервые слышу о том что правильно спроектированная система будет не быстройПока что правильностью проектирования у вас не пахнет.
Если вы размахнетесь слишком широко - то дойдете до хранения данных в EAV структуре.
А потом когда дело дойдет до отчетов - будете долго думать как получать данные.
При большом количестве данных в системе - у системы могут просто начаться проблемы с производительностью, которых не возникло бы при классическом реляционном подходе при проектировании структуры.

Вобщем, вам решать как себя мучать...

аттрибут "Тип телефона" не позволяет контролировать целостность данных Оператор-КодОператора и уж никак не позволяет гарантировать что указание в типе телефона "Мобильный" наличие действительно мобильного номера а не стационарного

Разделение телефонов нв стационарный и мобильный сделано не искусственно, а из-за различных аттрибутов этих телефонов - с вашей структурой вы обречены все время искать виновных в очепятках и наказывать их и страдать... :)