ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / Внешние ключи в OEBS, SAP, Axapta и тд.
25 сообщений из 115, страница 3 из 5
  3  все
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33423434
Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey
Участник
модкогда нужны проверки на ФК:
unsert - непротиворечивость легко обеспечивает правильное приложение
update - не требуеся, т.к. ФК не должны вообще изменяться
delete - единственный случай, когда действительно надо проверять, но это может делать приложение (все таки это редкое действие)
вывод: ФК не нужны (и разработчики ERP это прекрасно знают !)
а все чему учат в институтах - пора забыть
Уважаемый, Вы где учились?
"unsert - непротиворечивость легко обеспечивает правильное приложение" - теоретически обеспечивать должно, но от проверки отказываться не следует.
"update - не требуеся, т.к. ФК не должны вообще изменяться" - это пардон кто сказал такую чушь? те у записи нельзя поменять какие-нибудь поля состояний, или справочные поля оформленные как ФК.
"delete - единственный случай, когда действительно надо проверять, но это может делать приложение (все таки это редкое действие)" - вы что-нибудь слышали про атомарность? Как насчет случая подвисания приложения?

Кажется Вам пора снова учиться ...
...
Рейтинг: 0 / 0
07.12.2005, 19:14
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33423514
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Whateva michael_все правки - методом сторнирования! (Кроме шуток именно такую методологию в западных системах нередко можно встретить)
Вы наверное 1С-ом занимались плотно
А также Attain - ом и иже с ним, в которых модификации производятся в момент учета (posting), а записи любого справочника вместо удаления помечаются для такового, а потом пакетной процедурой, пока никто не видит чистятся. Действительно обходятся без FK. Такой подход практически во всех применяется. Записи помечаются для сервисных процедур. Естественно прямым обращением к БД можно грохнуть любые данные, концов не соберешь.
...
Рейтинг: 0 / 0
07.12.2005, 20:09
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33423746
mazzy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mazzy
Участник
iscrafm Whateva michael_все правки - методом сторнирования! (Кроме шуток именно такую методологию в западных системах нередко можно встретить)
Вы наверное 1С-ом занимались плотно
А также Attain - ом и иже с ним, в которых модификации производятся в момент учета (posting), а записи любого справочника вместо удаления помечаются для такового, а потом пакетной процедурой, пока никто не видит чистятся. Действительно обходятся без FK. Такой подход практически во всех применяется. Записи помечаются для сервисных процедур. Естественно прямым обращением к БД можно грохнуть любые данные, концов не соберешь.
?!
вы с чем-то путаете...
...
Рейтинг: 0 / 0
08.12.2005, 00:35
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33423748
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
что путаю?
...
Рейтинг: 0 / 0
08.12.2005, 00:44
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33423765
mazzy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mazzy
Участник
В Navision (бывш. Attain) нет понятия пометка на удаление и нет соответствующей процедуры.
Но это другая история.
Вернемся к вопросу о внешних ключах?
...
Рейтинг: 0 / 0
08.12.2005, 01:28
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33423812
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
mazzyВ Navision (бывш. Attain) нет понятия пометка на удаление и нет соответствующей процедуры.
Но это другая история.
Вернемся к вопросу о внешних ключах?
конкретно к Attain (бывший Navision) относилась первая часть, вернее к нему не относится пометка, неточность в тексте, сорри. Действительно в нем, что касается темы с FK проверки выполняются в триггерах (не БД, а в тех, что сидят в Codeunits, т.е. на клиенте). Опасность нарушения целостности при обращению напрямую к серверу БД это не уменьшает.
...
Рейтинг: 0 / 0
08.12.2005, 04:20
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33423814
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Здесь все таки больше коммерции, imxo. Хочешь работать безопасно с БД, используй иструментарий поставщика системы.
...
Рейтинг: 0 / 0
08.12.2005, 04:27
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33424098
bI-Ky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bI-Ky
Участник
mazzyВернемся к вопросу о внешних ключах?

А что тут обсуждать-то? Проблема высосана из пальца. Совершенно несущественные временные затраты на некритичных к скорости операциях - засчет гарантии непротиворечивости связей и упрощения бизнес-логики. Равняться в плане наличия-отсутствия внешних ключей на существующие системы бессмысленно, потому что причины их неиспользования при проектировании этих баз данных, вероятнее всего, никак не связаны с быстродействием (уж структура БД R/3 точно не образец). О селектах заботились бы лучше, а не модификаторах.
...
Рейтинг: 0 / 0
08.12.2005, 09:42
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33429421
Фотография grexhide
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
grexhide
Участник
>Вероятнее всего, никак не связаны с быстродействием (уж структура БД R/3 > точно не образец). О селектах заботились бы лучше, а не модификаторах.

1. Да, пожалуй это весьма разумное предположение. Практика доказывает,
что в любой системе оставлять "дыру" в целостности данных - практически
100% вероятность того, что конечный пользователь таки наступит в нее,
рано или поздно.

Проблема "не использования" внешних ключей банальна - множество доработок внедренцев по месту, исходя из текущих условий и требований
заказчика, усугубленных принципами - "не чини то, что работает", "не боги горшки обжигают".
Плюс необходимость системных обновлений (не всегда адекватных конечным требованиям и настройкам заказчика).
Плюс практически не поддающаяся контролю одним человеком степень сложности и лоскутно-шитый принцип построения любой ERP системы - в результате последовательность обработки той или иной транзакции или потока может, как ни странно, требовать временных (даже не в пределах транзакции БД) нарушений целостности - просто так система была внедрена и настроена (да, это неправильно, но ведь работает ?).

Да, есть еще такая вещь, как отложенные deferrable внешние ключи в Oracle, но цена использования таких возможностей в системах с >1000 пользователей - это еще вопрос. Особенно на запросах-обработках эдак нескольких миллионов записей.

И в конечном счете действительно будет не то что прощее и "быстрее" реализовать отдельные процедуры и методы проверки целостности на прикладном, а не системном уровне - это будет просто единственно "продуктивно" достижимый результат (при практике ERP систем вообще грешно использовать слово "успешный").

2. В пределах транзакции блокирование связанных таблиц по FK происходит только при явной модификации PK/удалении и отсутствию индексов по внешним ключам.
И тут - действительно да. Индексация всех внешних ключей - это очень опасная задача для оптимизатора, плюс проблема конкуренции за блоки в кластерах... (да, есть и реверсные ключи, и не суррогатные PK/FK давно не обсуждаются... но только при "новых" разработках, а что делать с существующим "багажом" ?).

Но какой смысл при проектировании новых приложений завязываться на исторически сложившиеся "особенности национальных реализаций ERP систем" ?

3. А такая милая проблема, как Multiple Organization в OEBS (когда вместо ID PK представлен как (ID, Org_ID ?) - куда тут прикажете вешать FK ?
Ну кто же мог подумать (в 80-х годах, при проектировании OEBS 1.0), что существуют ТНК ?
...
Рейтинг: 0 / 0
11.12.2005, 17:41
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33574899
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
На самом деле то, что FK "тормозят" работу -- это еще вопрос. Они могут, но это вовсе не обязательно. Например у нас были и FK, и проверки явные в логике процедур.
...
Рейтинг: 0 / 0
01.03.2006, 17:56
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33574988
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Насколько мне подсказывает логика, то не должны,

Ну вот как раз логика подсказывает, что просто обязаны.

> использование ключей - выше надежность и ниже производительность.

Не "выше надежность", а "гарантированная целостность и непротиворечивость".

> А в ERP производительность крайне важна.

Важно, чтобы летало, или все-таки важны данные? Может, лучше чуть больше денег на дисковую или на нормальную архитектуру приложения потратить?
...
Рейтинг: 0 / 0
01.03.2006, 18:21
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33575443
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
IgorTvт.к. использование ключей - выше надежность и ниже производительность. А в ERP производительность крайне важна.
Хм. Последние два месяца я занимаюсь разработкой DW для аналитики над данными недавно внедренного в крупной компании OEBS. Впечатления:

1. Производительность этой ERP, особенно ее кастомизаций, просто потрясает. 2. Ключей там нет. Точнее, есть в следовых количествах.
3. Данные уже кривые.

Если отвечать на Ваш вопрос, то:

1. По моему опыту, кривизна в данных обходится компании от "дорого" до "очень дорого". Куда дороже, нежели допустим на 10% более производительное железо. Собственно, я однажды подсчитал, что компания за год потратила на прямые работы, связанные с поиском-исправлением кривых данных больше, нежели стоил восьмипроцессорный сервак.

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

Собственно, если не лень, посмотрите второй пример в http://softwarer.ru/safety.html - там как раз про отключение таких проверок.
...
Рейтинг: 0 / 0
02.03.2006, 02:04
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33576654
mazzy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mazzy
Участник
softwarer1. По моему опыту, кривизна в данных обходится компании от "дорого" до "очень дорого". Куда дороже, нежели допустим на 10% более производительное железо. Собственно, я однажды подсчитал, что компания за год потратила на прямые работы, связанные с поиском-исправлением кривых данных больше, нежели стоил восьмипроцессорный сервак.
:)
Я не спорю с вашим утверждением. Вы правы.
Но обратите внимание, что "кривизна" данных не закладывается разработчиками изначально.

"Кривизна" как правило возникает в результате развития системы.
Что-то новое и незапланированное добавили...
Что-то ввели в пику моде, а потом оставили...
Если система живет несколько версий и тянет совместимость, то скелетов в шкафах копится немало.

Вопрос совместимости и переделки схемы данных может обойтись гораздо дороже серваков или кривизны.
...
Рейтинг: 0 / 0
02.03.2006, 12:57
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33576978
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
ИМХО одна из причин не использования ФК в ERP следующая - все ограничения целостности, даже ограничиваясь только ФК, средствами СУБД продекларировать невозможно (ну например во многих системах используются обобщенные таблицы, где смысл поля зависит от типа записи).
Значительную часть придется делать в серевере приложений. А раз СУБД все равно от кривизны не спасает, то зачем растаскивать контроль по двум серверам?
Проще сказать пользователям что лезть в БД минуя систему - тоже что писать диски ОС мимо файловой системы.
А весь контроль - на сервер приложений.
...
Рейтинг: 0 / 0
02.03.2006, 14:00
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33577144
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> во многих системах используются обобщенные таблицы, где смысл поля
> зависит от типа записи

Т. е. обычные кривые грабли.

> А весь контроль - на сервер приложений

Уточнение: кривые грабли промышленного производства. ;))

Причины: сознательно созданная невозможность оперирования данными за пределами приложения + (отчасти) тяжелое наследие предыдущих версий.

Собственно, это ответ автору вопроса.
...
Рейтинг: 0 / 0
02.03.2006, 14:43
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33577917
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mazzyНо обратите внимание, что "кривизна" данных не закладывается разработчиками изначально.
Хм. Не совсем понял Вашей мысли. Безусловно, довольно мало разработчиков сознательно закладывает в систему механику искривления данных. Вопрос в том, с какой вероятностью она возникает в каждом из случаев и насколько дорого в итоге обходится.

mazzyЕсли система живет несколько версий и тянет совместимость, то скелетов в шкафах копится немало.

Вопрос совместимости и переделки схемы данных может обойтись гораздо дороже серваков или кривизны.
Хм. Я в данном случае не говорю о кривизне схемы итп. Я говорю о том, что в системе, эксплуатируемой порядка года, уже есть просто и объективно кривые строки данных - к примеру, закупки у неизвестного (отсутствующего в системе) поставщика. Имхо это не имеет отношения к скелетам в шкафу исключая единственно "отсутствия контроля целостности в БД".
...
Рейтинг: 0 / 0
02.03.2006, 17:38
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33578369
инженер планового отдела
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
инженер планового отдела
Гость
Интересно, что может заставить людей использовать ERP на реляционных серверах, совершенно не приспособленных для таких задач ? А потом еще серьезно рассуждать о неиспользовании FK.
...
Рейтинг: 0 / 0
02.03.2006, 20:34
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33578958
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Хороший вопрос. А главное грамотный.
...
Рейтинг: 0 / 0
03.03.2006, 10:04
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33579422
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Давай те как лучше разберемся, для чего в свое время была реализована такая, по тем временам фича СУБД, как Declarative Referential Integrity.

Возьмем SQL Server 4 версии. Сколько надо было написать триггеров, чтобы реализовать эту самую RI, который ну никак не добавляли прыти быстродействию системы в целом. Слава богу, что разработчики СУБД дали нам в руки такой мощный инструмент поддержки целостности бд, как DRI, реализуемый на уровне реляционного движка.

И что мы видим в крупнейших ERP системах. Практический полный отказ от их использования, объяснить который мне не предоставляется возможным ни N-звенной архитектурой ни требованиями производительности.

Как можно в здравом уме оставлять таблицы, используюшие, например, справочник позиций, без DRI с этим справочником?! Да, конечно, в самой системе позицию так просто не удалишь, есть механизм проверки наличия "связей". Но хранилище то осталось незащищенным. И, лично я, не дам никакой гарантии, что среднее звено, используещее это хранилище, имеет 100 выверенный код по 100 проверки RI, ибо практика показывает обратное.

И в результате, на продакшен окружениях той самой OEBS с определенной периодичность всплывают такие битые ссылки. Нет никакого оправдания разработчикам, который оставил хранилище вот таким вот незащищенным. И никакие увещевания в юзер гайдах типа "Запрещается лазить в базу чем-либо другим, кроме самой системы" здесь не помогут. Детский сад какой-то, надо не просить, а на корню пресекать попытки разрушения целостности хранилища. Оно (хранилище) должно быть самодостаточно в его базовой функциональности.

IMHO.
...
Рейтинг: 0 / 0
03.03.2006, 11:40
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33581110
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
pkarklinКак можно в здравом уме оставлять таблицы, используюшие, например, справочник позиций, без DRI с этим справочником?!
Тут вопрос в том, чей ум является эталонно здравым. Я абсолютно уверен, что Вы, как и я, миллион раз слышали слова вида "у нас особый случай, пришлось придумать гениальное решение, наши опытные разработчики говорят что так и надо, а всякие авторы книг не знают жизни и пишут фигню".

Думаю, Вы не будете спорить с тем, что FK иногда мешают сделать некий хакерский трюк, а DEFERRED ключи существовали не всегда. При внесерверной логике они мешают больше, чем при серверной (а крупнейшие ERP страдают этим недостатком). Вот и начинаются....
...
Рейтинг: 0 / 0
03.03.2006, 18:10
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33581752
инженер планового отдела
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
инженер планового отдела
Гость
Правильно, pkarklin. А в объектных системах нельзя "отключать" и "включать" идентификаторы. И не нужно "декларировать ссылочную целостность" - все само собой "декларируется". Это тоже довод в пользу использования объектных систем для "ERP систем".
...
Рейтинг: 0 / 0
04.03.2006, 12:09
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33583431
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
pkarklinИ никакие увещевания в юзер гайдах типа "Запрещается лазить в базу чем-либо другим, кроме самой системы" здесь не помогут. Детский сад какой-то, надо не просить, а на корню пресекать попытки разрушения целостности хранилища. Оно (хранилище) должно быть самодостаточно в его базовой функциональности.IMHO. Ну и как должно выглядеть самодостаточное бухгалтерское хранилище? Чтобы в базовой функциональности изменение счета в проводке
- контролировалось по правилам корреспонденции счетов,
- вызывало изменение сохраненных остатков,
и др.
С точки бухгалтера все эти грехи ничем не лучше битой ссылки на счет.
...
Рейтинг: 0 / 0
06.03.2006, 11:06
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33583803
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
ModelRНу и как должно выглядеть самодостаточное бухгалтерское хранилище? Чтобы в базовой функциональности изменение счета в проводке
- контролировалось по правилам корреспонденции счетов,
- вызывало изменение сохраненных остатков,
и др.

Эээ... Я не совсем понял, что Вы хотите услышать от меня в ответ на Ваш вопрос?! Речь в топике шла о DRI.

ModelRС точки бухгалтера все эти грехи ничем не лучше битой ссылки на счет.

Эээ... Опять не понял, контроль корректности корреспонденции - это бизнес-логика, которая просто обязана пристутствать в системе, в прочем как и пересчет остатков. А Вы говорите о каких-то огрехах. И, опять же я не вижу, каким образом ее (бизнес-логики) присутствие в том или ином виде потребует отказаться от DRI?!

ЗЫ. Возможно, я все-таки не понял, что Вы хотели сказать.
...
Рейтинг: 0 / 0
06.03.2006, 12:46
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33584013
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
И, опять же я не вижу, каким образом ее (бизнес-логики) присутствие в том или ином виде потребует отказаться от DRI?!Всё довольно прозаично.
Разработка в ERP предусматривает работу в одном инструменте - IDE этой самой ERP. Написание триггеров и FK лежит вне всяких IDE. Т.е. как напишет программист на X++,ABAP,C/AL и т.д. так и будет. Забудет что-то - будут битые ссылки.
...
Рейтинг: 0 / 0
06.03.2006, 13:35
| Ответить | Цитировать | Написать  
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33586675
Whateva
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Whateva
Участник
softwarer1. Производительность этой ERP, особенно ее кастомизаций, просто потрясает.
"Вы их просто не умеете готовить" :-)
softwarer2. Ключей там нет. Точнее, есть в следовых количествах.
Ну так сложилось.
softwarer3. Данные уже кривые.
Спорю что данные стали "уже кривыми" в результате работы интерфейсов написанными 500-долларывыми разработчиками которые только вчера узнали чем SQL отличается от PL/SQL. Пока наши уважаемые "интеграторы" будут проводить политику "ввяжемся в бой а потом будет видно" так оно и будет. Чюдес не бывает.
...
Рейтинг: 0 / 0
07.03.2006, 13:11
| Ответить | Цитировать | Написать  
25 сообщений из 115, страница 3 из 5
  3  все
Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / Внешние ключи в OEBS, SAP, Axapta и тд.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]