DAX 4.0 Чем обусловлено наличие двух разных таблиц CustTable и VendTable?

[Бигудь]

Сабж, собственно. Т.е. до последнего момента я подозревал, что есть разные менюитемс "Клиенты" и "Поставщики", ссылающиеся на одну форму одной таблицы, потом оказалось формы разные, да еще и таблицы разные. Сами понимаете, спрашиваю, дабы понять логику, которая и в этом случае отлична от 1С
Если вдруг кто-то не в курсе: В 1С в типовых есть справочник "контрагенты" и у элемента есть свойство, которое может быть "Покупатель" или "Поставщик".

[ice]

посмотрите дальше: есть разные формы Заказы и Закупки, и таблицы у них тоже разные, ну и т.д., наверно все потому, что относятся к разным модулям Cust и Vend

[Андре]

Потому, что это разные сущности. И еще, например, потому, что они относятся к разным модулям, которые лицензируются отдельно друг от друга.

А почему Вам хочется, чтобы это была одна таблица ? Если речь идет об общей логике - то смотрите Data Dictionary / Maps / CustVend*

[MironovI]

Цитата:

Сообщение от Бигудь

потом оказалось

В 1С здраво рассудили, что клиент или поставщик неважно - это все равно прежде всего ЧЕЛОВЕК! А стало быть - зачем плодить разные справочники, навешивать ярлыки, множить классовое и рассовое неравенство
Аксапта же, как система сугубо буржуйская, на заветы марксизма и социального равенства плевала

[Sada]

Цитата:

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

В 1С здраво рассудили, что клиент или поставщик неважно - это все равно прежде всего ЧЕЛОВЕК! А стало быть - зачем плодить разные справочники, навешивать ярлыки, множить классовое и рассовое неравенство
Аксапта же, как система сугубо буржуйская, на заветы марксизма и социального равенства плевала

[longson]

Уже было обсуждение на эту тему. Смотрите, например

Клиенты и поставищики - почему в разных таблицах?

[Raven Melancholic]

Этот вопрос периодически всплывает. В свою очередь можно задать другие вопросы:
А почему это должна быть одна таблица?
А разве с клиентами и поставщиками работают одни и те же люди?
А почему не возникает вопроса: "Почему сотрудники, банки не в той же таблице с клиентами и поставщиками"?

[mazzy]

Цитата:

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

В 1С здраво рассудили, что клиент или поставщик неважно - это все равно прежде всего ЧЕЛОВЕК!

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

[Бигудь]

Цитата:

Сообщение от Raven Melancholic

Этот вопрос периодически всплывает. В свою очередь можно задать другие вопросы:
А почему это должна быть одна таблица?
А разве с клиентами и поставщиками работают одни и те же люди?
А почему не возникает вопроса: "Почему сотрудники, банки не в той же таблице с клиентами и поставщиками"?

Меня когда-то учили, что при разработке СУБД важно не плодить лишних сущностей. Зачем делать 2 таблицы, если можно пользоваться одной?

[MironovI]

Цитата:

Сообщение от Бигудь

при разработке СУБД важно не плодить лишних сущностей

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

А ежели про СУРБД - то там есть несколько принципов нормализации и денормализации

[mazzy]

Цитата:

Сообщение от Бигудь

Меня когда-то учили, что при разработке СУБД важно не плодить лишних сущностей. Зачем делать 2 таблицы, если можно пользоваться одной?

А вы считаете поставщиков и клиентов одной сущностью!?

[Ivanhoe]

Поставщик, клиент - сущности разные, но ссылаются на одну фактическую сущность - физическое или юридическое лицо, которое одно.


Разбиение на модули мне лично понятно, но, кажется, логичным иметь ряд реквизитов у клиента и поставщика (одного контрагента) одинаковых. Без модификаций в стандарте, к сожалению, этого не сделать. Ссылка клиента на поставщика не решает этой задачи.

[ZVV]

Цитата:

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

А вы считаете поставщиков и клиентов одной сущностью!?

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

[mazzy]

Цитата:

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

физическое или юридическое лицо, которое одно.

Физическое и юридическое лицо - разные сущности.

Но тут снова встает вопрос о нормализации и денормализации.

Цитата:

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

Разбиение на модули мне лично понятно, но, кажется, логичным иметь ряд реквизитов у клиента и поставщика (одного контрагента) одинаковых. Без модификаций в стандарте, к сожалению, этого не сделать. Ссылка клиента на поставщика не решает этой задачи.

Не надо. Права раздавать забибикаешься.
Для одинаковых методов/полей в Аксапте нужно юзать мапы.

Если хочется понять как в Аксапте неправильно сделали общими "ряд реквизитов", то посмотрите в таблицу hrmVirtualNetwork. Там объединили данные о физическом лице из таблиц сотрудники, контакты клиентов, контакты поставщиков, контакты из CRM и по-моему пользователей интернета. Ужас нах! Редкостный антипаттерн.

Начиная с ключа, который пришлось сделать невидимым для пользователей и скрыванием лукапа. Проходя через все круги ада с перехватом событий insert,delete,update (из-за чего тут же перестают выполняться групповые операции на сервере), а также с перехватом validate*. И заканчивая жуткими траблами в настройке прав доступа и RLS... В общем - Никогда так не делайте.

[Raven Melancholic]

Вообще, аргументов в пользу (или против) обоих вариантов привести можно немало.
Перечитал ссылку, которую дал longson. Интересно, является ли аргументом в пользу разделения то, что Андре в той ветке встает на защиту объединения в одной таблице, а в этой приводит доводы против объединений
Кстати, мне лично было бы интересно послушать, что его подвигло на изменение мнения.

[Ivanhoe]

Цитата:

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

Физическое и юридическое лицо - разные сущности.

Я имел в виду что есть ОДНО лицо, например ООО "Альфа" (а может, просто Иванов И.В.). Для Одного лица = контрагента, в Аксапте две сущности - поставщик ООО "Альфа" и клиент ООО "Альфа".

Цитата:

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

Не надо. Права раздавать забибикаешься.
Для одинаковых методов/полей в Аксапте нужно юзать мапы.

Надо юзать... так почему не юзает стандарт? Я сейчас только про дополнительные справочники / реквизиты ОДНОГО по сути контрагента. Ну какой же порядок будет в ЕРП, если в поставщиках ООО "Альфа", а в клиентах "АЛЬФА, ООО"???

[Михаил Андреев]

Цитата:

Сообщение от Бигудь

Меня когда-то учили, что при разработке СУБД важно не плодить лишних сущностей. Зачем делать 2 таблицы, если можно пользоваться одной?

Для чего важно? Обоснуете?

[EVGL]

Цитата:

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

Если хочется понять как в Аксапте неправильно сделали общими "ряд реквизитов", то посмотрите в таблицу hrmVirtualNetwork. Там объединили данные о физическом лице из таблиц сотрудники, контакты клиентов, контакты поставщиков, контакты из CRM и по-моему пользователей интернета. Ужас нах! Редкостный антипаттерн.

Начиная с ключа, который пришлось сделать невидимым для пользователей и скрыванием лукапа. Проходя через все круги ада с перехватом событий insert,delete,update (из-за чего тут же перестают выполняться групповые операции на сервере), а также с перехватом validate*. И заканчивая жуткими траблами в настройке прав доступа и RLS... В общем - Никогда так не делайте.

Ну что же, добро пожаловать в ад -2009. Там появились таблицы DirPartyXXX - т.н. "глобальная адресная книга". Супер вещь! Для нашего клиента - концерна с отдельными заводами, обслуживающих одних и тех же клиентов, передающих заказы друг другу через Intercompany, функция незаменимая.

[Бигудь]

Цитата:

Сообщение от Михаил Андреев

Для чего важно? Обоснуете?

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

[mazzy]

Цитата:

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

Я имел в виду что есть ОДНО лицо, например ООО "Альфа" (а может, просто Иванов И.В.).

просто Иванов И.В = ИЧП Иванов И.В
или вы приравниваете ООО и физическое лицо?

Цитата:

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

Для Одного лица = контрагента, в Аксапте две сущности - поставщик ООО "Альфа" и клиент ООО "Альфа".

Блин, совсем мешанина "лицо", "контрагент"
Сущность поставщик != сущность Контрагент.
Сущность клиент != сущность Контрагент.
Сущность клиент != Сущность поставщик

Еще раз: разберитесь с сущностями

Цитата:

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

Я сейчас только про дополнительные справочники / реквизиты ОДНОГО по сути контрагента.

С какой стати?
Как поставщик он использует одни реквизиты, как клиент он использует другие.
Например, для оплаты ему как поставщику требуется один банк,
а как клиент он платит с другого банка.

Как поставщик он имеет одни прайс-листы, скидки и договора
Как клиент он имеет совсем другие прайс-листы, скидки и договра.

Офис продаж имеет один адрес (поставщик для нас), а служба снабжения совсем другой (для нас клиент).

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

Ребяты! Ну, елы-палы...