Как соотносятся AX Data Entity и Entity framework?

[belugin]

Цитата:

Сообщение от mazzy

все это указатели )
но на практике программисты всевозможными путями пытаются избавиться от указателей в пользу ссылок

казалось бы - пустая смена терминологии

Не пустая. У ссылок нет арифметики указателей. У ключей есть такая арифметика - можно сделать recid++ или accountname + 'a'

Цитата:

Сообщение от mazzy

но в результате современные программные библиотеки навязывают стиль мышления "содержит", а не "указывает".
объект "содержит" другой объект
объект "принадлежит" другому объекту.
хотя в реальной памяти конечно же работают указатели

Прочитай семантику uml - "содержит" - лишь один из видов отношений.

Цитата:

Сообщение от mazzy

и relations - это указатели в области баз данных
relations требуют суррогатных ключей.
relations требуют внимания от программиста

Не требуют relation суррогатных ключей - открой морпхикс и простой рилейшен на любых ключах.

Это ключи а не релейшены указатели. Это они требуют внимания программиста. Проблема аккаунты в том, что нельзя в запросах использовать рилейшены аи не ключи.

Цитата:

если же перейти на уровень "принадлежит", то получим структуры типа xml/json
где никаких суррогатных ключей (указателей) не требуется.

Требуется как только надо изобразить что-то сложнее иерархии.

[mazzy]

Цитата:

Сообщение от belugin

Прочитай семантику uml - "содержит" - лишь один из видов отношений.

ну да, ну да... использует, наследует...
но со ссылками почти все превращается в семантику "содержит".

кроме того, мы же находимся в контексте data entity.
а в этом контексте даже навигационные свойства к внешним data entity превращаются в "принадлежит".

я говорил в этом контексте.
согласен с тем, что сформулировано коряво.
над формулировкой нужно еще подумать.

Цитата:

Сообщение от belugin

Не требуют relation суррогатных ключей - открой морпхикс и простой рилейшен на любых ключах.

да, ты прав. это я неточно сформулировал.

я говорил не о любых relation,
а о сильно нормализованных таблицах.
в которых связь технически нужно реализовать, но отражения на реальный мир эта связь не имеет.
такие relation как правило реализуются суррогатными ключами.

в аксапте это DimId, системная номерная серия и прочие
для таких ключей в номерной серии безболезненно можно использовать & вместо # - пользователи этого не заметят.

так вот, data entity полностью устраняют потребность в таких технических ключах.

Цитата:

Сообщение от belugin

Это ключи а не релейшены указатели. Это они требуют внимания программиста. Проблема аккаунты в том, что нельзя в запросах использовать рилейшены аи не ключи.

да-да. именно это я и имел в виду.
нужно генерить искуственные ключи, чтобы их можно было использовать как Foregn Key,
и таким образом реализовать Relation в сильно нормализованных таблицах.

да, сформулировано было коряво.
надо подумать

Цитата:

Сообщение от belugin

Требуется как только надо изобразить что-то сложнее иерархии.

ну да, ну да - "если объект может принадлежать нескольким объектам".
другими словами, граф, содержащий хотя бы один нетривиальный цикл. (не дерево)

[belugin]

Цитата:

Сообщение от mazzy

кроме того, мы же находимся в контексте data entity.
а в этом контексте даже навигационные свойства к внешним data entity превращаются в "принадлежит".

Это как? У энтитей могут быть и другие отношения.

Цитата:

в которых связь технически нужно реализовать, но отражения на реальный мир эта связь не имеет.

Мне это тоже непонятно. Нельзя ли увидеть пример. Как правило у таких таблиц эта связь является отражением чего-то в предметной области (например обобщения). Но при этом платформа не содержит удобного способа работы с такими связями.

Цитата:

такие relation как правило реализуются суррогатными ключами.

в аксапте это DimId, системная номерная серия и прочие
для таких ключей в номерной серии безболезненно можно использовать & вместо # - пользователи этого не заметят.

так вот, data entity полностью устраняют потребность в таких технических relation.

Relation есть в предметной области. Entity для потребителя представляет такой relation как отсутствующий, как я понял. То есть вместо "У строки есть набор аналитик" получается "У строки есть подразделение". А сама группировка некого набора признаков в понятие "набор аналитик" исчезает.

[mazzy]

Цитата:

Сообщение от belugin

Это как? У энтитей могут быть и другие отношения.

какие?

Цитата:

Сообщение от belugin

Мне это тоже непонятно. Нельзя ли увидеть пример. Как правило у таких таблиц эта связь является отражением чего-то в предметной области (например обобщения). Но при этом платформа не содержит удобного способа работы с такими связями.

я ж приводил.
DimId - очень древний пример
DirParty - не очень древний.

Цитата:

Сообщение от belugin

Relation есть в предметной области. Entity для потребителя представляет такой relation как отсутствующий, как я понял. То есть вместо "У строки есть набор аналитик" получается "У строки есть подразделение". А сама группировка некого набора признаков в понятие "набор аналитик" исчезает.

угу.
только стоит отметить, что "исчезает" из логических рассуждений.
исчезает из концептуальной модели.
технически все остается на месте.

[belugin]

Цитата:

Сообщение от mazzy

какие?

Любые выразимые Relations в аксапте.

Например LendgerEntity\Relations\AccountingCurrency - RelationshipType=Association

Цитата:

я ж приводил.
DimId - очень древний пример
DirParty - не очень древний.

Аналитика есть в UI и в рассуждениях пользователя о системе. Это не чисто техническое понятие.

Адресная книга и виды ее элементов есть в UI.

Цитата:

угу.
только стоит отметить, что "исчезает" из логических рассуждений.
исчезает из концептуальной модели.
технически все остается на месте.

Вот, она есть в UI (то есть аналитика выделена в отдельную группу, и есть отдельный UI для работы с ней). Но для программиста она исчезает. Что неправильно

[mazzy]

Цитата:

Сообщение от belugin

Это как? У энтитей могут быть и другие отношения

Цитата:

Сообщение от belugin

Любые выразимые Relations в аксапте.

не-не. давай про энтити
я утверждаю, что relations сводятся в энтити к семантике "принадлежит".
и других семантик, кроме "принадлежит" в энтити нет.
хотя на техническом уровне relations вполне остаются.

полностью аналогично ссылкам: ссылки упрощают понимание, но на техническом уровне остаются указатели.

я так понимаю, что ты говоришь, что в энтити существуют relations-семантики.
какие типы семантик, кроме "принадлежит" существуют в энтити?

можешь сформулировать одним полным абзацем?
без отсылок к предыдущим и умолчаний?
так чтобы можно было точно понять твою мысль

Цитата:

Сообщение от belugin

Например LendgerEntity\Relations\AccountingCurrency - RelationshipType=Association

поясни?
как значение технического свойства влияет на уровень семантики?
с точки зрения понимания здесь будет - валюта принадлежит финансовой проводке.
разве не?

Цитата:

Сообщение от belugin

Аналитика есть в UI и в рассуждениях пользователя о системе. Это не чисто техническое понятие.

аналитика - да.
но не "комбинации аналитик" и не dimID.

с точки зрения рассуждений пользователя о системе - в каждой проводке указана аналитика. другими словами, аналитика принадлежит проводке.

а вот то, что это отдельная таблица - это сугубо технический аспект реализации.

Цитата:

Сообщение от belugin

Адресная книга и виды ее элементов есть в UI.

адресная книга - да.
но не разбивка на это безумное число таблиц, которые требуют связей между собой.

обрати внимание, как об этом думаешь:
адреса принадлежат поставке (поставка содержит адреса)
контактные лица клиента...
и т.п.

а вот внутри технической реализации будут нормализованные таблицы.

Цитата:

Сообщение от belugin

Вот, она есть в UI (то есть аналитика выделена в отдельную группу, и есть отдельный UI для работы с ней). Но для программиста она исчезает. Что неправильно

то, что выделено в отдельную группу - особенность реализации.
с точки зрения рассуждений пользователя особой разницы нет - будет ли аналитика в отдельной группе или не будет.

а почему неправильно?

[belugin]

Цитата:

Сообщение от mazzy

и других семантик, кроме "принадлежит" в энтити нет.
хотя на техническом уровне relations вполне остаются.

LedgerEntity\Relations\AccountingCurrency

Это relation между LengerEntity и CurrencyEntity

Цитата:

я так понимаю, что ты говоришь, что в энтити существуют relations.
какие типы семантик, кроме "принадлежит" существуют в энтити?

Я не очень понял о каких отношениях мы говорим - между entity, внутри entity или что?

Между entity могут быть любые отношения. Внутри Entity тоже, просто для внешнего потребителя эти отношения превращаются в плоский список. Что плохо.

Цитата:

поясни?
как значение технического свойства влияет на уровень семантики?

Цитата:

Это свойство не влияет на рантайм никак это просто коммент для того, чтобы мы понимали тип отношения.

с точки зрения понимания здесь будет - валюта принадлежит финансовой проводке.
разве не?

Она не принадлежит. При изменении чего-то в финансовой проводки состояние валюты не меняется. Может только возникнуть отношение с другой валютой.

Цитата:

аналитика - да.
но не "комбинации аналитик" и не dimID.

Комбинация аналитик выделена в отдельную группу для пользователя. DimID - да, это технический аспект того, как именно организована связь.

У нескольких проводок может быть одна и та же комбинация аналитик.

То есть бессмыслено

transaction.DimensionID += 'a';

Осмысленно.

transactions.Where(x => x.Dimension == currentTransaction.Dimension);

foreach(value in transaction.Dimension)
{
    print $' {value.name} - {value.value}';
}

Цитата:

с точки зрения рассуждений пользователя о системе - в каждой проводке указана аналитика. другими словами, аналитика принадлежит проводке.

Не "принадлежит" а "связано".

Цитата:

адресная книга - да.
но не разбивка на это безумное число таблиц, которые требуют связей между собой.

Продемонстрируй связь, не являющуюся ничем для пользователя.

Цитата:

обрати внимание, как об этом думаешь:
адреса принадлежат поставке (поставка содержит адреса)

При удалении поставки адрес не исчезает и здание не сносят.
Один и тот же адрес может относиться к разным поставкам.

Это если слово "принадлежит" для тебя composition.

Цитата:

то, что выделено в отдельную группу - особенность реализации.
с точки зрения рассуждений пользователя особой разницы нет - будет ли аналитика в отдельной группе или не будет.

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

Цитата:

а почему неправильно?

Потому, что это делает программную модель сложнее и не отражает ползовательскую модель.

[ax_mct]

Цитата:

Сообщение от mazzy

не-не. давай про энтити
я утверждаю, что relations сводятся в энтити к семантике "принадлежит".
и других семантик, кроме "принадлежит" в энтити нет.
хотя на техническом уровне relations вполне остаются.

полностью аналогично ссылкам: ссылки упрощают понимание, но на техническом уровне остаются указатели.

я так понимаю, что ты говоришь, что в энтити существуют relations-семантики.
какие типы семантик, кроме "принадлежит" существуют в энтити?

можешь сформулировать одним полным абзацем?
без отсылок к предыдущим и умолчаний?
так чтобы можно было точно понять твою мысль

Страшно вклиниваться в разговор умных людей, но вдруг я понимаю о чем вы говорите.

Есть связи обусловленные фактами (fact oriented) и есть связи обусловленные принадлежностью (object oriented).

"Принадлежит" это на мой вкус - "object oriented", там где есть логическое структурирование и обьектная модель,
а вот "fact oriented" - принадлежности не чувствуется.

То есть как минимум две основные семантики у связей
object oriented (принадлежность)
fact oriented (логическое указание на факт)

https://en.wikipedia.org/wiki/Semantic_data_model

Прошу прощения если увел не туда