TRJПокажу эту ветку проектировщикам.
Пусть посмотрят, что коллективный разум о них думает :-)
Вспомнилось одно давнее обсуждение на этом форуме, если они (проектировщики) еще не видели, то вероятно им будет интересно. В предлагаемой модели "объект-качество" (автор - U-gene - Евгений Григорьев) вопрос "Насколько допустимо хранить в одних и тех же полях разные по смыслу данные?" звучал бы чуть по-другому...

Главную идею можно передать парой цитат:
«Создавая объектную систему на базе аппратного компьютера мы ВЫНУЖДЕНЫ представлять наши объекты как набор переменных простых типов. Создавая объектную систему на базе реляционной БД мы должны представить ее как совокупность переменных типа "отношение", поскольку это единтсвенный тип, реализуемый реляционными системами.»
и далее:
«Это не маппинг. Маппинг подразумевает, что данные преобразуются из "объектных структур в реляционные". У меня объекты изначально представляют собой совокупность реляционных структур. А зачем преобразовывать что-то во что-то если требуемое уже и так есть?»

В такой модели вопрос стоял бы не о разных смыслах значений одного поля а о разных смыслах записей одной таблицы (отношения) - т.е. разных смыслах разных переменных, хоть и одного типа...
Тогда, например, можно было бы иметь "реляционный тип" (таблицу) - Период с полями
Date1, Date2, S
где Date1 и Date2 имеют всегда имеют один и тот же "реляционный" смысл (начало и конец периода), а S содержит "объектный" смысл ("рождение-смерть", "женились-развелись", срок аренды и т.п.)

ps. первые две ссылки из того обсуждения на авторскую статью не открылись, и я уже не помню что это за статья, но вот ссылки на несколько его статей:
http://www.citforum.ru/database/articles/ooo_rel_data/
http://www.citforum.ru/database/articles/moq.shtml
http://www.osp.ru/os/2000/01-02/178205/

guest_20040621> U-gene - Евгений Григорьев

До сих пор фетишей было два: Celco и Тенцер. Теперь три. Абсолютная, полная, безграмотная шуклятина.

P.S. Шуклятина - производное от Шуклин. Есть тут такой недоумок.


А для меня это оказалось нормальной, здоровой пищей:)

Идея-то (U-gene) простая, интуитивно понятная, прививка (размышления на тему), может создать иммунитет к идеям Тенцера(&Co) или "стихийным/народным" типа "хранить в одних и тех же полях разные по смыслу данные", imho.

guest_20040621 - Вам - верю. Укажите грамотную вкуснятину - непременно отведаю (попытаюсь)

guest_20040621> Идея-то (U-gene) простая, интуитивно понятная

И это-то как раз плохо. И у Celco, и у Тенцера то же самое: все буквально на пальцах и даже работает. А на самом деле - типичные антипаттерны.
У Тенцера (если я правильно помню, "измельчить" реляционные типы до такой степени, чтобы они соответсвовали простым типам ОО-языка, и как побочный результат - обессмысленные одноколоночные таблицы с характерными проблемами), согласен, явный антипаттерн (как минимум - паттерну "таблица как тип данных").
О Celco ничего сказать не могу, т.к. с его идеями не знаком (кроме всем известной "деревянной" идеи)...

guest_20040621...Как оперировать метаданными? Нет одного источника и единого подхода. Но дела обстоят примерно так... Что Вы делаете, цитируя Григорьева: Вы полагаете возможным микс из моделей и метамоделей, абсолютно никак не связанных между собой, не имеющий (и не имеющий возможности иметь) общей метамодели (или метаметамодели).
Григорьев как раз везде и подчеркивает ортогональность реляционной и объектной моделей, и (как я понял) как раз и призывает не смешивать их (в какой-то его работе обсуждалась целесообразность существования двух типов триггеров на таблице - R-триггеры и O-триггеры). Что я делаю, цитируя Григорьева в этом топике? Пытаюсь указать, что, возможно, проблему "хранить в одних и тех же полях разные по смыслу данные?" следует решать на более высоком "атомарном" уровне восприятия типа данных чем "поле таблицы", а именно на уровне "таблица как тип данных".
Все тот же пример, таблица [Период], поля Date1, Date2, S. Рассмотрим ограничения 1) Date1<=Date2, 2) Date1!=null && Date2!=null? Допустим, первое обязательно для всех записей, второе - зависит от "объектного" смысла (кто-то уже родился(Date1) но еще не умер(Date2), политика организации - в договоре(аренды) обязательно указывать срок, и т.п.). Можно ли считать, что (1) - относится к свойствам реляционного типа (таблица [Период]), а (2) - к свойствам объекта "размещенного" в этой таблице? Я считаю что да, можно. Можно попробовать возвести это в некий принцип/паттерн, и "оформить" это, например размещением проверки ограничений (1) и (2) в R-триггере и O-триггере таблицы [Период], соответственно.
Возникла ассоциация - в бухгалтерии одни и те же объекты "размещены по полочкам" как Активов так и Обязательств (две ортогональных плоскости).

guest_20040621Что предлагает Тенцер? - да ровно то же самое. Принципиальной разницы нет.
Не согласен, повторю, у Тенцера я увидел разрушение паттерна "таблица как тип данных".

guest_20040621Как дОлжно подходить к решению таких задач? Да очень просто: нужен не микс, а единая метамодель, позволяющая описать все используемые для решения задачи модели данных. Одна из моделей по условию задачи задана: реляционная. По счастью, модель достаточно простая. Значит, осталось выбрать еще одну модель данных для задачи и описать ее либо в терминах реляционной модели данных, либо реляционную модель описать в терминах это модели. Ну, или выбрать существующую метаметамодель, позволяющую описать и реляционную, и выбранную модели.
Ну так у Григорьева как раз не микс, а две ортогональных "плоскости", чем не "единая метамодель"?

guest_20040621>Есть реляционная модель данных. И есть объектная модель. Подчеркну: модель, а не модель данных. И реляционная модель данных, и объектная модель могут быть описаны с помощью MOF, например. О какой ортогональности Вы говорите?
Об ортогональности реляционной модели данных и объектной модели, квадратного и зеленого, и квадратное и зеленое может быть описано с помощью русского языка, я что-то не так понимаю?

guest_20040621> целесообразность существования двух типов триггеров на таблице - R-триггеры и O-триггеры

Не нужно покупаться на неологизмы. Триггеры - они и есть триггеры. Обычные триггеры из реляционной модели. Какие названия им кто-то придумал вместо того, чтобы называть их триггерами - абсолютно не интересно.
Да, конечно, обычные триггеры. Имелся ввиду "нотационный" аспект (если можно так выразиться) для повышения "градуса" ортогональности, в первую очередь в голове у разработчика (нотации нам строить и жить помогают :)

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

guest_20040621> "таблица как тип данных".

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

guest_20040621> Можно ли считать, что (1) - относится к свойствам реляционного типа (таблица [Период]), а (2)
> - к свойствам объекта "размещенного" в этой таблице?

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

guest_20040621Вы не хотите иметь границ между метамоделью, моделью данных и моделью предметной области. К сожалению, они есть и с этим ничего не поделать. ;) Более того, именно их наличие, собственно, и делает возможным практическое применение реляционных СУБД. ;)
Затрудняюсь что-либо ответить...слишком "высоко" для меня :)

guest_20040621Микс. Не нравится слово "микс" - назовите "каша", смысл останется тем же. ;)
:-)))

guest_20040621;) Вот я и говорю о том, что квадратное не может быть ортогонально зеленому.
Смотря каким смыслом наполнять понятие "ортогональность". В моделировании/проектировании это в первую очередь - максимальная независимость, imho. Т.е. если изменив цвет (с зеленого на красный) мы при этом не потеряем форму (осталась квадратной), то вполне можно полагать что цвет ортогонален форме, разве нет?

guest_20040621Реляционная модель существует безотносительно СУБД.
Реляционная модель -> SQL -> СУБД. Других проявлений существования я не знаю... т.е. для меня "безотносительность" весьма относительна :)

guest_20040621> Не совсем понял, что значит "описывать объекты"?

Термин "объект" в объектной модели имеет вполне себе конкретную смысловую нагрузку. Иногда этот термин используют применительно к другим моделям, обычно - абсолютно без оснований для этого, при этом не уточняя контекста и не давая определения. В реляционной структуре нет объектов. Есть сущности. Разница - принципиальна.
Т.е. в более раннем посте Вы хотели сказать что в реляционных СУБД можно описывать "сущности" но не "объекты"? ("Вы не имеете возможности описывать объекты штатными средствами реляционных СУБД").

guest_20040621> дядя Вася
ОК, если Вы настаиваете, пусть будет. ;)
Похоже, я Вас уже утомил (а может и не только Вас). Ну, извините :)
Но раз уж так много было написано(может и флуда), позволю себе еще один раз высказаться.
Проблему автора топика можно переформулировать как проблему определения домена в реляционной модели. Именно семантика домена "увязывает" реляционную модель с предметной областью. Что произойдет, если "хранить в одних и тех же полях разные по смыслу данные"? Домен исчезнет? Наверное нет. Семантика домена станет более сложной (а связь с предметной областью более мутной)? Наверное да. Как избавиться от сложности и мути?
1) отказаться от "хранить в одних и тех же полях разные по смыслу данные"
2) сложность и муть понятия относительные, цена вопроса приемлемая
3) попробовать создать надстройку "инкапсулирующую сложность и просветляющую муть"
Я не рекомендую ни 1) ни 2) ни 3), а лишь рекомендую познакомиться с существующими попытками 3).

ModelRНо проблема автора в зависимости смыслов одних атрибутов от значений других. А?
Верно. И вполне естественным выглядит желание "оформить/унифицировать" эти зависимости в некую согласованную (модель? чего? "видения" данных?) в рамках реляционной модели.
Например, можно к каждому атрибуту "прицепить" дополнительный смысловой(семантический) атрибут и получить что-то похожее на модель Тенцера. Или, посчитав, что достаточно одного семантического атрибута для всех атрибутов отношения(отношение как "тип данных моей системы"), получить что-то похожее на модель Григорьева. Или ...

TRJЛюбопытно, а описания полей любых "типов" должны так раскладываться на реляционную и объектную компоненту? Типа, когда мы пытаемся определить характеристики чего-то, то эта характеристика всегда как бы в двух плоскостях?
Если вопрос ко мне, то я затрудняюсь ответить что-либо определенное, так как сам не уверен в правомочности такого подхода (я верю guest_20040621, а он считает эти идеи безграмотной тухлятиной:Р)
В чем я уверен, так это в том, что над этими идеями стоит помедитировать, если периодически приходится заниматься проектированием БД...