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

Бигудь · 27.02.2009, 13:38

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

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

ice · 27.02.2009, 13:47

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

**Андре** · 27.02.2009, 13:48

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

А почему Вам хочется, чтобы это была одна таблица ?

Если речь идет об общей логике - то смотрите Data Dictionary / Maps / CustVend*

MironovI · 27.02.2009, 14:35

Цитата:

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

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

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

Аксапта же, как система сугубо буржуйская, на заветы марксизма и социального равенства плевала

Sada · 27.02.2009, 14:38

Цитата:

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

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

Аксапта же, как система сугубо буржуйская, на заветы марксизма и социального равенства плевала

longson · 27.02.2009, 14:46

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

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

Raven Melancholic · 27.02.2009, 14:48

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

**mazzy** · 27.02.2009, 14:53

Цитата:

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

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

Ну да, а также в 1С здраво рассудили, что с ним работает только один человек, который может видеть весь список

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

Бигудь · 27.02.2009, 15:25

Цитата:

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

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

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

MironovI · 27.02.2009, 15:34

Цитата:

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

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

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

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

**mazzy** · 27.02.2009, 15:43

Цитата:

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

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

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

Ivanhoe · 27.02.2009, 15:58

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

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

ZVV · 27.02.2009, 16:03

Цитата:

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

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

Доводилось как-то принимать участие в проекте (не на Аксапте), где изначально подумали примерно так-же, что лучше одна большая таблица, чем несколько поменьше и более специализированных. Вместо того чтоб сделать несколько специализированных таблиц для отдельных видов документов изначально дизайн был сделан так, что все документы системы хранились в одной таблице: "Документы". В итоге таблица заросла огромным кол-вом полей, большинство из которых очень специфичны для одного только типа документа, всё это обросло ещё пачкой дополнительных таблиц и в итоге поличилась такая тяжелоуправляемая каша...

Если проводить аналигию с Аксаптой, то это как все докуметы (закупки, заказы, журналы ГК\Производственные\Складские и т.п.) свалить в одну таблицу. Сущность то одна - документы!

Бигудь, это не было случайно Вашим следующим вопросом?

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

**mazzy** · 27.02.2009, 16:07

Цитата:

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

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

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

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

Цитата:

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

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

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

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

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

Raven Melancholic · 27.02.2009, 16:17

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

Кстати, мне лично было бы интересно послушать, что его подвигло на изменение мнения.

Ivanhoe · 27.02.2009, 16:31

Цитата:

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

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

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

Цитата:

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

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

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

Михаил Андреев · 27.02.2009, 16:33

Цитата:

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

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

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

EVGL · 27.02.2009, 16:34

Цитата:

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

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

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

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

Бигудь · 27.02.2009, 16:39

Цитата:

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

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

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

**mazzy** · 27.02.2009, 16:46

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

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

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

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

Похожие темы
Тема	Автор	Раздел	Ответов	Посл. сообщение
Организация доступа внешних веб-пользователей к DAX 4.0	alex55	DAX: Администрирование	1	07.06.2009 17:48
DAX Help Creation Quick Information	Blog bot	DAX Blogs	0	29.07.2008 04:09
Пропали обновления приложения DAX 4.0 EE SP2	pe	DAX: Администрирование	3	20.02.2008 00:28
DAX 4.0 Ген. фин. отчетов - Активное сальдо (дебет) и Сальдо дебет - в чем разница?	Aleks_K	DAX: Функционал	5	17.01.2008 01:47
Query из 7 таблиц	Cornflower	DAX: Программирование	29	15.03.2007 11:27