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, а он считает эти идеи безграмотной тухлятиной:Р)
В чем я уверен, так это в том, что над этими идеями стоит помедитировать, если периодически приходится заниматься проектированием БД...