Блок А.Н.Бредятина,

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

Блок А.Н.Если бы была тема типа "будущее СУДБ" или "какой должна быть идеальная СУБД", то ваши рассуждения были бы к месту.
Но человек задал практический вопрос на конретную тему, а вы влезли совершенно не к месту с рассуждениями, которые не поймет не только он, но и большая часть форума. На неуместность этого я вам и указал. А хамить уж, извините, начали вы.
Впрочем, давайте прекратим, это уже совсем не в тему дискуссии.
Нет, не прекратим. Потому что:
1) Вы пишите неправду. Вы мне не на что не указывали. Вы указали автору темы, чтобы он не обращал внимания на сообщения по существу темы.
2) Вы пренебрежительно отзываетесь об авторе темы и большей части участников форума - не поймут существо вопроса.
3) Именно благодаря моему сообщению автор темы сделал важное уточнение своего вопроса (про отсутсвие объекта в БД).

EvLaUyДо сих пор я полагал, что подобная безграмотность, набравшая силу в настоящее время, свойственна только "среднестатистическому" гражданину без особых затей. А оно вона как... Оказывается так пишут высоколобые гуру с учеными степенями, претендующие на то, чтобы вещать с недостижимых высот и учить других уму разуму.
Забавно. Вы понимаете, Бредятина, что в первой фразе первого пункта поощрительно советуете человеку писать неправду? Вот к чему привела Ваша безграмотность.
Я то, конечно, понимаю)) Беда в том, что Вы никогда ничего не понимаете и при этом допускаете менторский тон в высказываниях)) Я бы на Вашем месте вычитывал тексты, чтобы не допускать, по крайней мере, откровенных глупостей. Таких, как в данном сообщении, когда Вы рассуждаете о связях с отсутствующим объектом.

EvLaUyМожет быть и слишком. В третьем случае, пожалуй, действительно опечатка. Но все мы люди, и откровенно менторская манера общения этого участника форума, честно говоря, раздражает. А по третьему закону Ньютона действие равно противодействию.
А Вас всегда раздражают знания, и привлекают незнания) Вот опять написали про ключи невесть что))

А это как понимать?)) Жирным шрифтом сами выделите?))
О связях между сущностями:

Реальная история. В Донецке в советские времена (60-е или 70-е годы) был машиностроительный завод им 15-летия комсомола Украины, может и сейчас еще существует. Крупный был, известный завод. Его директором был цыган по фамилии Катеринич, сейчас его имя носит одна из улиц. Что ж, редко, но случалось такое. И вот, остановился в окрестностях города цыганский табор. Его власти стали сгонять. Цыгане отрядили делегацию к Катериничу, чтобы тот за них заступился перед властями. А оно ему сильно надо было? И он пришедшим стал грузить, что вот мол, зачем вы ведете кочевую жизнь, учитесь, работайте как я - и достигнете того же.

О третьей нормальной форме:

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

Об объектном доступе:

Мне кажется, возвратиться к прежнему работодателю - это значит, признать своё поражение в каком-то смысле. Признать, что приняв решение сменить работу, совершил ошибку. Да и бывшие коллеги будут относиться как к неудачнику по жизни. Ну разве что если уж о-о-чень сильно позовет.

Об оптимизации запроса:

Во что она превратится в job offer'е остается лишь догадываться. А во что - при выдаче на руки лучше вообще не думать.

EvLaUyЭка как я Вас болезненно зацепил, Бредятина. Ты глянь, как засуетились.
Откровенная глупость))) Меня невозможно "зацепить". Я не для того занимаюсь базами данных, чтобы меня можно было бы зацепить... Так что и здесь не правильно говорите об ограничениях целостности. Тем более, что это ограничение целостности не имеет никакого отношения к вопросу автора темы)
EvLaUy У меня на форумах 250 сообщений, так что Вам еще, милейший, пахать и пахать.
Нет необходимости) Ткнул "случайно") Те, кто меня знают, могут Вам рассказать какое у меня чутье на ошибки)) Особенно в текстах про БД. А Ваши сообщения ведь про БД((
EvLaUyКаким-то агрессивным Вы стали. Год назад еще не были таким. Мороз крепчает. Ложь. Я здесь уже много лет всегда отвечаю адекватно. И буду отвечать))
EvLaUyА если Вы без ложной скромности позиционируете себя как носителя знаний, я как маньяк в тысячный раз спрошу Вас: где Ваши книги, светило?
Нет такого определения отсутствующего объекта у Дейта.

EvLaUyА не слишком ли смело, Бредятина? И никогда, и ничего. Как Вы бесшабашно с кванторами-то общности обращаетесь. Не к лицу серьезному ученому. Но, по счастью, Вы не относитесь к числу людей, мнением которых о себе я дорожу.
Именно никогда и ничего. Это факт.

EvLaUyТе, кто Вас знают, милейший, (а это весьма известные и уважаемые в мире IT люди) единодушны в своем мнении - Вы больной на голову. И это факт. Медицинский.
))) Заблуждаетесь. То, что Вы больной на голову, может и догадывались уважаемые люди, но только я это показал так ясно. Причем, и на простых примерах нормализации БД, а не только на примере задачи, которая рассматривается в этой теме))

EvLaUyПодумал, что надо бы принести извинения модератору за то, что здесь происходит, ибо мой оппонент, вне всякого сомнения, не сделает этого никогда.
Более того, здесь никто и никогда не сделает даже замечания таким хамам, ка Вы))
EvLaUyПо существу темы было бы неплохо, если бы высказался ТС. Бредятина с присущей ему самонадеянностью утверждает, что его посты оказали ТС-ру помощь. ТС считает так же?
Глупость. ТС написал об отсутствующем объекте. Он не писал об этом в первом сообщении. Это факт.
EvLaUyЕсли ТС Бредятину понял, то и хорошо. Если нет - сыр-бор вот про что. Бредятина считает, что называться СУБД может только такая система, которая позволяет бизнес-пользователю (в данном случае, наверное, даже аналитику предметной области) интерактивными средствами строить модель данных самому - т.е. создавать новые классы, описывать их свойства и связи между классами. Т.е. создать самому систему метаданных. Ну и, разумеется, коль скоро модель данных построена, интерфейс СУБД также должен давать пользователю (уже не аналитику, а обычному пользователю) эксплуатировать эту модель данных, т.е. создавать экземпляры классов, назначать значения свойствам и связывать экземпляры друг с другом согласно имеющейся схеме метаданных. Да, взгляд логичный и правильный. Если мы имеем "настоящую" СУБД с таким интерфейсом, то всё это, как пишет Бредятина, действительно должен делать пользователь без участия программиста. Но с чего Бредятина взял, что у ТС именно такая СУБД? У него обычная Cache, а не "великий" XMagic, коим Бредятина так гордится.
Неправда. Я не горжусь ни чем, абсолютно. А только говорю, что MUMPS - среда для создания СУБД. И если некто не хочет ее создавать, а хочет использовать СХОД, то он и дальше будет сталкиваться с многочисленными проблемами.
EvLaUyИ ТС в своем проекте решает конкретную задачу - как ему именно применительно к своему проекту это всё реализовать. На мой взгляд, ТС действительно дал слишком мало данных, чтобы ему можно было чем-то конкретно помочь. ТС, можете ли Вы сами для себя ответить на следующие вопросы:
1) Как Вы собираетесь конкретно реализовывать отношение "один-ко-многим" в Cache? Будет ли это Relationship, если да, то будет ли оно описано как one-many или как child-parent? Это очень важный вопрос, и Вам важно понять, какое именно поведение Вам требуется. Либо это будет свойство типа ArrayOfObjects? ListOfObjects? Свойство с описанием collection? Что-то еще? От ответов на эти вопросы существенным образом зависит реализация создания объектов, их связывания, сохранение, модификация, удаление, и особенно реализация поиска этих объектов в БД. Вы уже спроектировали основной класс с этой точки зрения? А в какой момент появится основной объект - это уже следующий вопрос, ответ на который зависит от того, что отвечено на предыдущие.
2) Если связанных классов действительно очень много, есть смысл подумать о хранении связей в экземплярах отдельного класса, какой-нибудь класс Chord. Связали что-то с чем-то в интерфейсе - на сервере плюс один инстанс этого класса. Да, тут придется дополнительно попрограммировать, но это окупится большой гибкостью решения.
3) Как правильно указал krvsa, нужно смотреть и в сторону дизайнеров и разработчиков интерфейса. А еще раньше - аналитиков требований. Именно они после обследования предметной области должны первыми получить представление, как пользователям обследуемого предприятия было бы оптимально вводить эти данные. Дальше - дизайнер нарисовал, верстальщик сверстал (всё это именно с учетом минимизации жмаканья клиентов по кнопкам), клиенту показали макет - понравилось. А дальше уже проектирование и корректировка решений по предыдущим пунктам. Думаете, каким образом с учетом последовательности поступления данных на сервер всё это технически лучше всего реализовать. Как-то так. У каждого свой опыт. У меня такой.
И это все тоже именно благодаря мне, придурку)) И это тоже факт.

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