|
|
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
_модДля меня Накладные - это объекты супертипа Событие (или операция, т.е. то что имеет дату-время). Хм. А Вы множественное наследование применяли или нет? Или только от "операции" "наследуетесь"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2009, 12:54 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
Сергей ВаскецовХм. А Вы множественное наследование применяли или нет? Или только от "операции" "наследуетесь"? Чистая иерархия: сущности -> объекты-> типы объектов сущности -> операции-> типы операций ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2009, 13:39 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
Сергей ВаскецовУ меня бывали циклы в похожей ситуации. Ничего страшного не было. согласен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2009, 13:40 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов, авторСахават бы с удоволствием стер бы с словаря слова - класс, свойство, тип и т.д. Каждый понимает что хочет под этими словами. А я думаю, что обсуждающие как раз примерно одинаково понимают термин "класс", но некоторые не выделяют все необходимые формальные свойства, необходимые для моделирования классов. А также смешивают разные метамодели классов в одну кучу, превращая эту кучу в нецелостную и противоречивую. Грубо говоря, подход к классификации тогда станет легитимным и общепризнанным, когда совокупность классов, экземпляров и т.д. в ней будет компилируема однозначным образом. Ты же програмист, заводишь переменную определенного типа, класса и только в допустимом смысле это имя потом и используешь. Но в "русском" языке ты почему-то начинаешь себя вести совершенно иначе, жонглируя неопределенными словами. И при классификации ведешь себя иначе, предполагая что компилляцию типов будет делать кто-то за тебя. авторНа самом деле нет никаких классов. Класс - это шаблонное видение классифициующего под который кастируются реальные объекты. Тут никто не возражает против этого. Классов, свойств в природе нет. Имеются объекты. Субъекты вольны их раскладывать в определенные кучки по определенным правилам (например, свойствам объектов). Чтоб не путаться, так и говорят, что класс может иметь структуру (набор свойств и значений) и совокупность объектов этой структуры. Классы - это понятия. Каждое понятие имеет уникальный идентификатор (термин), чтобы не было синонимии, может (но не обязано) иметь структуру понятия и объем понятия (в частном случае нулевой, если под понятие не подходит не один объект). Свойства придуманы для простоты работы с отношениями, задание которых представляется трудным, трудоемким и т.д. В определенном смысле свойства без хотя бы двух объектов не существуют. Покопавшись в каждом свойства найдете отношение на объектах, участие в котором и означает это свойство. Цвет - это участие объектов в отношении отражения света на определенной частоте. Эталонные объекты для мер и весов хранятся, чтобы ни у кого не было сомнений в единицах измерений. Имя, идентификатор свойством не является. Это выделенная фигня для различения объектов. Конечно, могут быть всякие частичные имена, не образующие первичного ключа. Вот они свойства. авторВ любом случае класс= (Имя, идентификатор) + {свойств для отбора объектов}. Это при классификации по существующим свойствам объектов. (Select * where имеется {свойств для отбора объектов}) Обобщим до наличия свойства, а не только классификация по значению. У тебя тут только 2 задачи, есть масса других, для чего используют классы и классификации: - размещение объекта в класс по свойствам и значеиям; - отбор, автоматическое формирование множества, объема понятия, соответствующего классу. Еще выделяют задачи поиска объекта (в системе классов), использования объектов классов и т.д. Предполагается, что все объекты некоторого класса можно использовать одинаковым образом (то есть класс как бы имеет совокупность методов класса). Если почему-то подклассы класса, объекты класса нельзя использовать одинаковым для всех образом, то классификация НЕ ВЕРНА. Именно об этом я тебе и талдычу. Разное образует разные метаклассы, их нельзя использовать одинаковым образом, ошибки будут. авторДругой вид классификации - агрегирующий, классификатор является СВОЙСТВОМ для всех агрегрированных объектов, у которых изначально НЕТ такого свойства. Например Мои_Друзья(перечень идентификаторов классов и отдельных объектов). Нет возражений. То же можно сделать и с классами, имеющими свойства и значения - присваивать их объектам класса. Тут нет никакой принципиальной разницы, чтобы выделять эту модель классов в какие-то "агрегирующие". Все классы агрегирующие, то есть представляют множество своих объектов. авторЭти два вида классифицирующих объектов составляет единый навигационный классификатор со множеством классифицирующих входов. Не понятно. На картинке у тебя слева - это только классы? Экземпляров там нет? Кроме того, как я говорила, там есть лишнее - то, что туда не может попасть. Типы данных, свойства, отношения разной структуры могут образовывать только отдельные непересекающиеся классификаторы. авторКлассификатор не дерево. А где я предлагала дерево. Я изначально предлагала множественный классификатор, которые отобразим на дерево. авторОтнощение такой же класс как и остальные. Единственное отличие - объекты этого класса не имеют осмысленного имени. Нельзя ИД1,Работает1, чел1, цех1 ИД2,Работает2, чел2, цех2 Совсем не такой же. Отдельный, причем каждое отношение отдельно. Пробую объяснить. Классы одного классификатора образуют подклассы, объединение экземляров дочерних дает исходный класс. Никогда отношение на классах не сможет стать подклассом или надклассом, оно всегда в отдельном классификаторе. Несколько разных отношений иногда могут быть в одном классификаторе, если все они построены на одной ступени (являются подмножествами одинакового декартова произведения двух классов, то есть подклассами). Таким образом классификаторы объектов и классификаторы разных отношений никогда не пересекаются. Если ты желаешь утверждать, что отношение "состоит" из классов (в данном случае у тебя, например, классов Люди, Цеха), то это также не верно. Так как в отличие от классов отношение - это некоторое подмножество декартова произведения, и вовсе не все объекты обязаны в него входить, а только некоторые или соответствующие определенным условиям целостности. Далее, мы говорили, что каждый объект классификации является уникальным, то есть представим единственным образом (узел имеет единственное нижнее замыкание, единственное (множественное) поддерево. Классы, объекты классов могут входить в разные отношения, причем иногда по нескольку раз в одно отоншение в разных ролях. По Людям и отношению "работают в" можно найти цеха. Цеха не являются подклассом Людей, и помещение их в классификатор может быть только условностью, выделенной атрибутикой метамодели. Подмножества Цехов для каждого человека свои, то есть это разные множества и назвать их именем отношения не допустимо в силу уникальности классов. По Цехам в свою очередь может быть найдена проекция соответствующих Людей. Об этих навигационных циклах речь? Запретить такие циклы - опять же нарушить уникальность раскрытия объекта, класса. Не запретить - бред. Так что это никакое не раскрытие, и к классификатору не имеет отношения вообще. Но показать, выделив явным образом, можно. авторМожно создать агрегирующий классифицирующий объект Документ и приписать к нему отношения. Т.е. ничем классификация отношений не отличается. Не понятно ниче ты пишешь. Отношением принято называть множество. Документ - это элемент отношения, экземпляр. И куда ты его в классификаторе засунешь, кроме как в само отношение? авторПроекция - динамическая классификация по свойству классификатора (свойства классификатора является фильтром в select. Любой узел графа классифицирующего является оператором Select. Нет, я имела в виду операцию взятия проекции отношения, то есть получение подмножества соответствующего класса или другого отношения. авторТипы данных, свойства, объекты (экземпляры), классы это принципиально разные вещи, обращаться с ними надо по-разному. У Сахавата «тип» - это сборная солянка из всего, и отношение это сборная солянка из всего. авторЭто все одна и та же фигня с точки зрения возможности приведения в вид (ИД, Наименование). Это вообще не при чем. Идентификатор имеют, конечно, но на этом схожесть заканчивается. авторЕдиница измерения, цвет (есть у него такие в списке) – это не объекты, а свойства. Классификатор объектов никогда не может быть смешан с классификатором свойств. Свойства не образуют множеств, и с ними нельзя обращаться как с множествами. Нельзя посчитать число элементов «множества свойства». Число заданных значений иногда можно посчитать (для перечислимых свойств), но это бессмысленно и совсем другое. Но можно посчитать число красных объектов. авторНу, прогеры привыкли, что есть класс "Color"и справочник "Едизм" с несколькими свойствами. Проггеры привыкли с разными классами работать по разному. Посмотри на свой код для разных справочников. Справочники справочникам рознь. авторЧтобы EAV стала работоспособной, необходимо добавить более жесткие метаструктуры и навесить атрибутику на них, чтобы потом работать со всем правильно, а не складывать Сахавата и 52. авторДык, это дело прикладника, а не проги моей. Пусть опишет правильно. :) Это станет твоим делом, когда прога начислит тебе неправильную зарплату или разобьется самолет с твоей дочерью? Если метамодель некомпиллируема, то кодом потом ты их исправишь только в частных случаях. Если ты делаешь прогу для себя - то и бог с тобой. Ты владелец своих моделей. А если хочешь сделать нечто отчуждаемое, то надо все переделывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2009, 20:41 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
_мод, авторYulka Чтобы EAV стала работоспособной, необходимо добавить более жесткие метаструктуры и навесить атрибутику на них, чтобы потом работать со всем правильно авторЯ бы сказал наоборот: для реализации метаструктуры можно применить EAV (и не только - есть и другие методы). Т.е. под цель подбираются средства. Согласна. Как физически хранить - это отдельный вопрос. EAV - для уникального, например для задания самих метамоделей самое оно. А все множества удобней жестко хранить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2009, 20:44 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
Yulka_мод, авторYulka Чтобы EAV стала работоспособной, необходимо добавить более жесткие метаструктуры и навесить атрибутику на них, чтобы потом работать со всем правильно авторЯ бы сказал наоборот: для реализации метаструктуры можно применить EAV (и не только - есть и другие методы). Т.е. под цель подбираются средства. Согласна. Как физически хранить - это отдельный вопрос. EAV - для уникального, например для задания самих метамоделей самое оно. А все множества удобней жестко хранить. Нет. ЕАВ имеет приумещества для классификации. если сделать жестко, то придется продублировать ИД, Наим в отдельной таблице и махаться с синхронизацией и нецелостностью технической в виде вьюшки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2009, 21:08 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
_модСергей ВаскецовУ меня бывали циклы в похожей ситуации. Ничего страшного не было. согласен а как с памятью? создаете новые классы при рекурсии или используете устаревший кеш? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2009, 21:09 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов_модСергей ВаскецовУ меня бывали циклы в похожей ситуации. Ничего страшного не было. согласен а как с памятью? создаете новые классы при рекурсии или используете устаревший кеш? классы = экземпляры ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2009, 21:09 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовНет. ЕАВ имеет приумещества для классификации. если сделать жестко, то придется продублировать ИД, Наим в отдельной таблице и махаться с синхронизацией и нецелостностью технической в виде вьюшки. Конкретно: все объекты всех типов хранятся в двух таблицах: список самих объектов и св-ва объектов. Никаких проблем с целостностью нет и вьюшек нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 10:30 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифова как с памятью? создаете новые классы при рекурсии или используете устаревший кеш? при навигации один и тот же модуль вызывается рекурсивно. ессно памяти может не хватить, но при нынешней технике не вижу проблемы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 10:32 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
_модпри навигации один и тот же модуль вызывается рекурсивно Я тоже так сначала делал. Но когда стали возникать ситуации, что состояние вызывающего не дает ему возможности быть вызванным, я стал делать кастрированные (с функциональной точки зрения) новые экземпляры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 10:36 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовЕАВ имеет приумещества для классификации. если сделать жестко, то придется продублировать ИД, Наим в отдельной таблице и махаться с синхронизацией и нецелостностью технической в виде вьюшки. Сахават, неужели дублирование какого-то ИД и Наим сравнимо с этим?: _модпри навигации один и тот же модуль вызывается рекурсивно. ессно памяти может не хватить, но при нынешней технике не вижу проблемы Читаю и не пойму в чем преимущества? Считаю EAV порочной практикой в принципе. Видимость легкости пополнения атрибутного состава объектов на фоне невозможности полноценного их использования. Любой отчет с использованием этих атрибутов превращается просто в геморрой, а вы про навигацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 10:43 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
Сергей Васкецов Но когда стали возникать ситуации, что состояние вызывающего не дает ему возможности быть вызванным, я стал делать кастрированные (с функциональной точки зрения) новые экземпляры. Тоже вариант ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 10:57 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
iscrafmВидимость легкости пополнения атрибутного состава объектов на фоне невозможности полноценного их использования. Любой отчет с использованием этих атрибутов превращается просто в геморрой, а вы про навигацию. Новые объекты и/или св-ва вводятся как раз для их "полноценного использования" (причем мгновенного). Никаких проблем с отчетами пока не наблюдалось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 13:08 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
Сергей Васкецов_модпри навигации один и тот же модуль вызывается рекурсивно Я тоже так сначала делал. Но когда стали возникать ситуации, что состояние вызывающего не дает ему возможности быть вызванным, я стал делать кастрированные (с функциональной точки зрения) новые экземпляры. А говорили с циклическими релейшнами нет проблем :) Тут уж либо кастраты в виде объектов без релейшн, либо новая копия всех объектов :( в принципе можно в пожарном порядке временно отключать мешающие циклические ссылки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 14:50 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
iscrafmСахават ЮсифовЕАВ имеет приумещества для классификации. если сделать жестко, то придется продублировать ИД, Наим в отдельной таблице и махаться с синхронизацией и нецелостностью технической в виде вьюшки. Сахават, неужели дублирование какого-то ИД и Наим сравнимо с этим?: _модпри навигации один и тот же модуль вызывается рекурсивно. ессно памяти может не хватить, но при нынешней технике не вижу проблемы Читаю и не пойму в чем преимущества? Считаю EAV порочной практикой в принципе. Видимость легкости пополнения атрибутного состава объектов на фоне невозможности полноценного их использования. Любой отчет с использованием этих атрибутов превращается просто в геморрой, а вы про навигацию. С ЕАВ очень удобная классификация и хошь не хошь не привязываешься к наименованиям полей таблиц. А так можно с этой же метаструктурой генерировать плоские таблицы и работать с ними. Я эту возможность оставляю. пока никак с реентерабельностью не разберусь, ошибка где то в логике. :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 15:00 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов пока никак с реентерабельностью не разберусь, ошибка где то в логике. :( фу, тупая ошибка была :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 15:33 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифовв принципе можно в пожарном порядке временно отключать мешающие циклические ссылки. на этом остановлюсь, правда формы дальше по циклу уже модальные :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 15:35 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовА говорили с циклическими релейшнами нет проблем :) Я писал, что ничего страшного нет. Любая циклическая зависимость всегда требует своеобразного подхода. Сахават ЮсифовТут уж либо кастраты в виде объектов без релейшн Просто у экземпляра признак, что он "ущербный", он много чего не делает (например, сериализоваться ему запрещено в нашем случае) и умрет сам, как только в нем не будет необходимости. Сахават Юсифовв принципе можно в пожарном порядке временно отключать мешающие циклические ссылки. В начале так и делали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 15:38 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифовправда формы дальше по циклу уже модальные :( Вот это и есть первая но не единственная беда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 15:39 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
Сергей ВаскецовСахават Юсифовправда формы дальше по циклу уже модальные :( Вот это и есть первая но не единственная беда. сказал а, скажи б что там еще плохого будет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 15:43 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
_модКонкретно: все объекты всех типов хранятся в двух таблицах: список самих объектов и св-ва объектов. Никаких проблем с целостностью нет и вьюшек нет. Значит вы внешние ключи держите в таблице свойств? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 16:04 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифовчто там еще плохого будет? Ну, потенциально любое состояние формы, когда она не готова принять навигацию. Например, наличие несохраненных изменений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 16:08 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовЗначит вы внешние ключи держите в таблице свойств? В метаописании как ссылки на сущности или классификаторы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 16:46 |
|
||
|
(_мод)
|
|||
|---|---|---|---|
|
#18+
Сергей ВаскецовСахават Юсифовчто там еще плохого будет? Ну, потенциально любое состояние формы, когда она не готова принять навигацию. Например, наличие несохраненных изменений. Так. ВСЕ с этим. Никакик кастратов, никакой лишней памяти. Никаких циклов. Всего этого больше НЕТ. Неправильная парадигма визуализации была. Поменял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2009, 17:49 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35811235&tid=1542394]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
149ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
68ms |
get tp. blocked users: |
1ms |
| others: | 200ms |
| total: | 451ms |

| 0 / 0 |
