powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / Внешние ключи в OEBS, SAP, Axapta и тд.
115 сообщений из 115, показаны все 5 страниц
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33410408
IgorTv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Интересует меня вопрос:
используются ли внешние ключи (Foreign Key) в системах ERP?
Насколько мне подсказывает логика, то не должны, т.к. использование ключей - выше надежность и ниже производительность. А в ERP производительность крайне важна. Если я для одной транзакции залочу 5-7 таблиц активно используемых, то все остальные будут курить пока моя транзакция не докомитится.

Интересует этот вопрос и по 1С и по Галактике и в принципе по всем системам

Добрый день кстати :)
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33410419
Фотография Эстонский голем
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ключи надо искать на альтовисте а не здесь просить
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33410428
IgorTv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Эстонский големключи надо искать на альтовисте а не здесь просить
мне не ключи доступа нужны а архитектура БД систем
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33410513
9
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
9
Гость
В OEBS нету внешних ключей, ВЫ совершенно правы.Но объяснение этой особенности проблемами производительности можно принять, если доказать, что внешнии ключи съедают хотябы 5-10% процентов производительности. Но есть ли у кого такая статистика?

Согласитесь, что из-за 0.2% производительности отказываться от внешних ключей смысла нет.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33410549
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgorTvиспользование ключей - выше надежность и ниже производительность. А в ERP производительность крайне важна
Система не может жертвовать надежностью ради производительности. Так что это не аргумент.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33410652
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В большинстве ERP не используют ключи по банальной причине:
Система разработки должна быть максимально независимой от СУБД. Поэтому проверка целостности делается на клиенте с вытекающими отсюда последствиями.
Так делается в большинстве западных систем. И многих отечественных тоже.

>> А в ERP производительность крайне важна
судя по тому, как там организованы схема данных/поля/таблицы производительность второстепенна.
Отсюда и почти фантастические требования под необходимое оборудование.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33410710
OA User
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgorTvиспользование ключей - выше надежность и ниже производительность. А в ERP производительность крайне важна
В OEBS вещи типа ключей, триггеров и пр. использованы по минимуму в первую очередь потому, что это трехзвенное приложение. Здесь за целостность системы отвечает по большей части сервер приложений, а не сервер БД. И в итоге в производительности вы только выигрываете, кстати. По своему печальному опыту могу сказать, что подавляющее большинство триггеров, вкоряченных талантливыми руками внедренцев в таблицы OEBS, дают ощутимую потерю скорости обработки данных.
Про сопровождение системы, масштабирование и пр. правильные слова я и не говорю.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33410734
Whateva
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
9В OEBS нету внешних ключей, ВЫ совершенно правы.
Вы в этом уверены? (Hint: HR, GM%, ABM, AX...)
IgorTvЕсли я для одной транзакции залочу 5-7 таблиц активно используемых, то все остальные будут курить пока моя транзакция не докомитится.
Каким образом наличие FK (с индексами) может залочить 5-7 таблиц применительно к Oracle?
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33410740
9
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
9
Гость
автор
Про сопровождение системы, масштабирование и пр. правильные слова я и не говорю


так а вы скажите. почему это для 3x звенки ключи стали вдруг ненужны. Пока слышно только про проблему производительности ( ито никто не может сказать на сколько выигрыш по скорости).
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33410760
IgorTv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgorTvЕсли я для одной транзакции залочу 5-7 таблиц активно используемых, то все остальные будут курить пока моя транзакция не докомитится.
WhatevaКаким образом наличие FK (с индексами) может залочить 5-7 таблиц применительно к Oracle?
Ну если я не ошибаюсь, то таблицы, на которых навешаны FK нужно обрабатывать в одной транзакции. А пока пардон тарнзакция по апдейту 5-7 таблиц не дойдет до конца, то таблицы залоченны (не углубляясь в подробности со страницами и т.д.)
Пока транзакция идет использование таблиц в ней участвующих - ограничено.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33410783
IgorTv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
9 автор
Про сопровождение системы, масштабирование и пр. правильные слова я и не говорю

так а вы скажите. почему это для 3x звенки ключи стали вдруг ненужны. Пока слышно только про проблему производительности ( ито никто не может сказать на сколько выигрыш по скорости).

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

Если ключи не использовать - сложнее программировать, целостность иногда теряется (изза ошибок программирования) но производительность будет выше т.к. грубо говоря 1 строка в таблице - 1 транзакция
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33410791
OA User
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
9
так а вы скажите. почему это для 3x звенки ключи стали вдруг ненужны. Пока слышно только про проблему производительности ( ито никто не может сказать на сколько выигрыш по скорости).
По-моему, ключи - это лишь один из инструментов обеспечения бизнес-логики, которая в OEBS, в частности, весьма сложна. Какой смысл разбрасывать реализацию этой логики по разным компонентам системы, если все можно держать на сервере приложений?
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33410799
Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgorTv
Ну если я не ошибаюсь, то таблицы, на которых навешаны FK нужно обрабатывать в одной транзакции. А пока пардон тарнзакция по апдейту 5-7 таблиц не дойдет до конца, то таблицы залоченны (не углубляясь в подробности со страницами и т.д.)
Пока транзакция идет использование таблиц в ней участвующих - ограничено.
Ошибаетесь. Ошибаетесь в том плане, что апдейт таблицы не лочит таблицу целиком. Почитайте мануал к разным БД.

Что касается например R/3, то в принципе, возможность задания foreign key существует. Но, если честно, пока я еще не встретил ни одной таблицы для которой эти ключи определены :) Правда нельзя сказать что я целенаправлено искал.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33410805
OA User
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgorTv
Ключи нужны для целостности и облегчения программирования, но при большом количестве пользователей (сотни-тысячи) будут сильно тормозить. При достижении определенного порога будет именно обвал производительности.

Если ключи не использовать - сложнее программировать, целостность иногда теряется (изза ошибок программирования) но производительность будет выше т.к. грубо говоря 1 строка в таблице - 1 транзакция
Если стандартный API использовать, с целостностью ничего не станется, и производительность будет прогнозируемой (это не менее важно, чем скорость)
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33410812
Whateva
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgorTvНу если я не ошибаюсь, то таблицы, на которых навешаны FK нужно обрабатывать в одной транзакции. А пока пардон тарнзакция по апдейту 5-7 таблиц не дойдет до конца, то таблицы залоченны (не углубляясь в подробности со страницами и т.д.)
Oracle залочит только те записи которые участвуют в транзакции (типа PO header -> PO lines -> Shipments). Собственно говоря наличие/отсутствие FK здесь иррелевантно: для консистентности данных их в любом случае надо блокировать.
IgorTvПока транзакция идет использование таблиц в ней участвующих - ограничено.
Ограниченно это будет только для транзакций пытающихся обновить/удалить заблокированные записи . Для всех других - без ограничений.
Блокировка таблицы - это как-то слишком дорого для OLTP.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33411154
9
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
9
Гость
автор
Какой смысл разбрасывать реализацию этой логики по разным компонентам системы, если все можно держать на сервере приложений?


проще всего как раз сделать внешнии ключи и не писать больше ни одной строчки исходного кода.

попробуйте сами. замерьте сколько у вас уйдет времения на написания кода для проверки внешнего ключа и сколько уйдет времени на добавление внешнего ключа средствами СУБД.

Пример вот я пишу код для внешего ключа

alter table HR.PAY_PAYROLL_ACTIONS
add constraint PAY_PAYROLL_ACTIONS_FK1 foreign key (BUSINESS_GROUP_ID)
references HR.HR_ALL_ORGANIZATION_UNITS (ORGANIZATION_ID)

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

( Кстати это пример я взял из OEBS т.е там все-такие есть FK, но используются они редко...)


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


это только так кажется. нужны исследования. Думаю всем было бы интересно узнать действительно ли это так. и при каких параметрах начинается торможение. ( хотя если проверки делать самому, Наприме с помощью процедур, то они тоже буду вызывать торможение)
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33411383
Tov. Drujba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AndreyЧто касается например R/3, то в принципе, возможность задания foreign key существует. Но, если честно, пока я еще не встретил ни одной таблицы для которой эти ключи определены :) Правда нельзя сказать что я целенаправлено искал.
Значит мало работали. Очень много таблиц с FK в САПе (EKKO, EKPO, ... всего две, потому как пример. А так почти любую не справочную открывай, не ошибешься).
Это и по сабжу. По крайней мере в R/3 FK широко используются.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33411536
Leshic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В OEBS улючи достаточно редки
в GL не встречал :)
в Scala есть, в Парусе есть
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33411572
Фотография Валентин К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Блокировки: читать мануалы по конкретным БД.

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

Нужно ли ERP внешние клюи: безсмысленный вопрос, ERP-концепкия, внешние ключи - поддержка целостности данных в различных таблицах.

в 1С нет внешних ключей, потому что dbf-ки их не поддерживают, и говорить нужны они или нет - нет смысла :)
Галактика - не показатель в принципе...

Но тем не менее в зависимости от модели хранения объектов в БД внешние ключи могут быть не применимы, но это совсем не ERP :)
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33411838
IgorTv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Tov. Drujba AndreyЧто касается например R/3, то в принципе, возможность задания foreign key существует. Но, если честно, пока я еще не встретил ни одной таблицы для которой эти ключи определены :) Правда нельзя сказать что я целенаправлено искал.
Значит мало работали. Очень много таблиц с FK в САПе (EKKO, EKPO, ... всего две, потому как пример. А так почти любую не справочную открывай, не ошибешься).
Это и по сабжу. По крайней мере в R/3 FK широко используются.
А вещи типа автоинкремент или ограничение значений в полях таблиц используются?
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33411865
Tov. Drujba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgorTvА вещи типа автоинкремент или ограничение значений в полях таблиц используются?
Именно в R/3 понятия автоинкремент нет. Если надо что-то подобное, приходится реализовывать руками. По второму пункту не понял. Что Вы имеете в виду под "ограничением значений"?
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33411867
OA User
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Валентин К
Нужно ли ERP внешние ключи: БЕССМЫСЛЕННЫЙ вопрос, ERP-концепция, внешние ключи - поддержка целостности данных в различных таблицах.

Полностью согласен, точнее не скажешь.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33411869
michael_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgorTv[А вещи типа автоинкремент или ограничение значений в полях таблиц используются?
А зачем вы это спрашиваете, вы, случайно, не в милиции работаете ? (c)

Вы свою систему проетирует или обзор какой-то делаете? Вас только конкретные системы интересуют?
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33411900
IgorTv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OA User Валентин К
Нужно ли ERP внешние ключи: БЕССМЫСЛЕННЫЙ вопрос, ERP-концепция, внешние ключи - поддержка целостности данных в различных таблицах.

Полностью согласен, точнее не скажешь.
К словам придераетесь или я не так вопрос задал. Меня интересуют реализации работы с БД конкретных ERP систем.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33411928
IgorTv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
michael_ IgorTv[А вещи типа автоинкремент или ограничение значений в полях таблиц используются?
Вы свою систему проетирует или обзор какой-то делаете? Вас только конкретные системы интересуют?
Пытаюсь сделать постановку задачи для интеграции многих маленьких систем и JDEdwards. Вот зашел спор с разработчиками маленьких, но гордых, систем как нужно БД проектировать совместного пользования, чтоб не писать в каждой системе интерфейс под каждую, а написать один общий, но чтоб все его понимали.
Я считаю, что внешние ключи будут только тормозить БД при большом количестве операций, хотя без внешних ключей код писать тяжелее.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33411956
Tov. Drujba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgorTv,
а теперь подумать сколько одновременных пользователей может быть в САПе (с ее FK), и сколько в 1С 8.0 (MS Sql) без таковых. Все дело в продуманности архитектуры (что приложения, что БД). Если нет опыта/знаний - хоть с ключами, хоть без них - дело швах будет.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33411973
OA User
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgorTvК словам придераетесь или я не так вопрос задал. Меня интересуют реализации работы с БД конкретных ERP систем.
Так Вам вроде подробно ответили. В OEBS на больших транзакционных таблицах ключей вроде нет, проверок значений тоже.
Интересная у Вас проблема, а документация по JDEdwards что говорит?
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33412022
IgorTv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OA User IgorTvК словам придераетесь или я не так вопрос задал. Меня интересуют реализации работы с БД конкретных ERP систем.
Так Вам вроде подробно ответили. В OEBS на больших транзакционных таблицах ключей вроде нет, проверок значений тоже.
Интересная у Вас проблема, а документация по JDEdwards что говорит?
JDEdwards тоже ключей не использует, и я хочу этот же принцип переложить на БД для интеграции, а разработчики маленьких, но гордых программ говорят, что это не правильно и их в институтах не так учили.
Вот у меня сомнение завелось может таки JDE не права, оказалось еще и OEBS и Axpata и Navision и BAAN и Exact не правы, да и SAPR3 тоже оказывается местами не прав.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33412135
Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Tov. DrujbaЗначит мало работали. Очень много таблиц с FK в САПе (EKKO, EKPO, ... всего две, потому как пример. А так почти любую не справочную открывай, не ошибешься).
Это и по сабжу. По крайней мере в R/3 FK широко используются.
Да я и не спорю. Раз возможность имеется, то скорее всего ее кто-то использует :) Сам-то я в базисе по большей части вожусь и там не встречал.

IgorTvВот у меня сомнение завелось может таки JDE не права, оказалось еще и OEBS и Axpata и Navision и BAAN и Exact не правы, да и SAPR3 тоже оказывается местами не прав.
Вообще-то раз внешние ключи производители всех БД продолжают поддерживать, то наверное это явное доказательство их нужности. А когда утверждают обратное, то это как правило от большой лени или от неправильного проектирования системы, что случается чаще.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33412155
OA User
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AndreyВообще-то раз внешние ключи производители всех БД продолжают поддерживать, то наверное это явное доказательство их нужности. А когда утверждают обратное, то это как правило от большой лени или от неправильного проектирования системы, что случается чаще. Это явное доказательство их нужности В РЯДЕ СЛУЧАЕВ, не более того. Кстати, данные которые собрал автор, весьма красноречиво это подтверждают. Думаю, у производителей ERP (а не баз данных) было время подумать над проектированием.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33412166
Tov. Drujba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andrey
Да я и не спорю. Раз возможность имеется, то скорее всего ее кто-то использует :) Сам-то я в базисе по большей части вожусь и там не встречал.

Ну я вообще тоже все в базисе. Это сейчас в FI пришлось переползать. Ну тогда вот: TADIR (DEVCLASS), TVDIR(DEVCLASS, CLTCODE), ... Ну и так далее :)
Возьмете меня в SAP AG?
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33412173
bI-Ky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgorTvЯ считаю, что внешние ключи будут только тормозить БД при большом количестве операций, хотя без внешних ключей код писать тяжелее.
Дадад, делайте на MySQL, там никаких таких рюшечек нету - очень быстро все летает. А то навыдумывали, транзакции, форен кии, триггеры всякие.

Неужели Вы думаете, что если целостность реляционной (sic!) БД контролировать во внешнем приложении вместо нативного механизма внешних ключей, она станет работать быстрее?
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33412245
OA User
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
bI-KyНеужели Вы думаете, что если целостность реляционной (sic!) БД контролировать во внешнем приложении вместо нативного механизма внешних ключей, она станет работать быстрее?
я так думаю, что если без всяких проверок добавлять заведомо непротиворечивые данные, медленнее не будет уж точно.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33412270
Tov. Drujba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OA Userзаведомо непротиворечивые данные
Идиалист, однако. Эта заведомая непротиворечивость откуда возьмется? Проверками на клиенте? Но это противоречит КС. Работать должен сервер. Толстые клиенты не камильфо, ИМХО.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33412305
Фотография Валентин К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgorTv
JDEdwards тоже ключей не использует, и я хочу этот же принцип переложить на БД для интеграции, а разработчики маленьких, но гордых программ говорят, что это не правильно и их в институтах не так учили.
Вот у меня сомнение завелось может таки JDE не права, оказалось еще и OEBS и Axpata и Navision и BAAN и Exact не правы, да и SAPR3 тоже оказывается местами не прав.

Насчет Axpata могу сказать только то, что разработчики из кожи вон лезли чтобы она быстрее работала, так реалии сервера БД не переплюнешь :)
видимо и ключей внешних поснестли, чтобы БД поменьше размером была, типа какой у нас продукт получилсо...

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

А вы господин афтар сначала попробуйте спроектировать, разработать и написать учетную систему вообще без фк для 100-200 пользователей - тогда вы сами ответите на свой вопрос :).
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33412312
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgorTv wrote:
> JDEdwards тоже ключей не использует, и я хочу этот же принцип переложить
> на БД для интеграции, а разработчики маленьких, но гордых программ
> говорят, что это не правильно и их в институтах не так учили.
> Вот у меня сомнение завелось может таки JDE не права, оказалось еще и
> OEBS и Axpata и Navision и BAAN и Exact не правы, да и SAPR3 тоже
> оказывается местами не прав.
вообще говоря, ключи можно не юзать, надо только каким-то образом
ГАРАНТИРОВАТЬ непротиворечивость данных. Если Вы строго контроллируете
код, достаточно тестируете свои приложения - то ключами, наверное, можно
пренебречь.
А вот если вы "Малэнкий, но гордый кантор с гор!", тогда вы
предполагаете, что в вашем ПО могут быть ошибки, что на себя слишком уж
полагаться не стоит, ну и применяете всякие там внешние ключи и
ограничения - как последний рубеж обороны, так сказать...

Тем паче... не знаю, где как, я на MS SQL 2000 пробовал и с йими, и без
йих - интересно было, наскоко изменится скорость. Ну, получил 2%
прироста, шо дальше? Стану я из-за такой мелочи рисковать целостностью?
да ни в жисть! 2% никто не заметить, в обчем-то, а вот васю, который
удалит часть корневого справочника... ага, тут-же! а попу, пардон,
порвут уже мне - дурак мол, не обеспечил...

--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33412340
OA User
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Tov. DrujbaИдиалист, однако. Эта заведомая непротиворечивость откуда возьмется? Проверками на клиенте? Но это противоречит КС. Работать должен сервер. Толстые клиенты не камильфо, ИМХО.
Мы вообще-то о трехзвенке говорили, а не о толстых клиентах. Что касается OEBS, то видимо горой стандартных пакетов в каждом модуле, в частности, эта целостность и обеспечивается. В любую форму залезьте, там их вызовы будут. И интерфейсы почти все через стандартные API сделаны. Может, я чего и не понимаю, но мы их используем и вопросов по целостности системы как-то не возникает.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33412527
IgorTv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
bI-Ky IgorTvЯ считаю, что внешние ключи будут только тормозить БД при большом количестве операций, хотя без внешних ключей код писать тяжелее.
Неужели Вы думаете, что если целостность реляционной (sic!) БД контролировать во внешнем приложении вместо нативного механизма внешних ключей, она станет работать быстрее?
Уверен. Есть у вас таблица с продажами и таблица с заголовками продаж + таблица складских операций + бухгалтерских проводок (не считая всякие справочники где надо сальдо дебитора проапдейтить, свобдное количество изменить и т.д.). Все связаны FK. В каждой таблице допустим по миллиону записей или около того. Теперь вы вставляете туда новую продажу допустим на 500 строк. Что происходит? правильно таблица (страница) лочится и туда идет вставка. А что делает такойже процесс рядом стоящий? правильно стоит ждет пока первый закомитится вставив, проапдейтив 3-5 таблиц нехилых размеров и перестроив индескы. А если таких процессов одновременно 100. то все они выполняются строго последовательно потому что у вас FK навешаны. А если я сначала вставляю в одну таблицу, освобождаю ее для следующего аналогичного процесса, потом в другую и т.д. Получается что процессы обрабатываются параллельно какбы со сдвигом. Такчто все 100 процессов отработают быстрее.

А проверки на корректность данных выносят на сервера приложений. Их продублировать\распараллелить проще, а БД всегда узким местом является в любой системе.

В идеале вообще должно быть 1 строка=1 транзакция.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33412540
Whateva
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgorTvкошмар поскипан
Ну Вам же уже объяснили что это не так. По крайней мере в Oracle RDBMS.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33412572
Tov. Drujba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgorTv, ну Вы как из каменного века. Кто Вам сказал, что лочится вся таблица? Для САПа это, мягко говоря, не совсем верно. Отсылаю к Lock Objects документации на saphelp.com. В крацее: лочится может одна строка, группа строк и в крайнем случае - вся таблица. Но это действительно крайний случай . Об механизмах сохранения непротеворечивости данных я расказывать не буду, увольте.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33412625
Joker_Ya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgorTv bI-Ky IgorTvЯ считаю, что внешние ключи будут только тормозить БД при большом количестве операций, хотя без внешних ключей код писать тяжелее.
Неужели Вы думаете, что если целостность реляционной (sic!) БД контролировать во внешнем приложении вместо нативного механизма внешних ключей, она станет работать быстрее?
Уверен. Есть у вас таблица с продажами и таблица с заголовками продаж + таблица складских операций + бухгалтерских проводок (не считая всякие справочники где надо сальдо дебитора проапдейтить, свобдное количество изменить и т.д.). Все связаны FK. В каждой таблице допустим по миллиону записей или около того. Теперь вы вставляете туда новую продажу допустим на 500 строк. Что происходит? правильно таблица (страница) лочится и туда идет вставка. А что делает такойже процесс рядом стоящий? правильно стоит ждет пока первый закомитится вставив, проапдейтив 3-5 таблиц нехилых размеров и перестроив индескы. А если таких процессов одновременно 100. то все они выполняются строго последовательно потому что у вас FK навешаны. А если я сначала вставляю в одну таблицу, освобождаю ее для следующего аналогичного процесса, потом в другую и т.д. Получается что процессы обрабатываются параллельно какбы со сдвигом. Такчто все 100 процессов отработают быстрее.

А проверки на корректность данных выносят на сервера приложений. Их продублировать\распараллелить проще, а БД всегда узким местом является в любой системе.

В идеале вообще должно быть 1 строка=1 транзакция.

Интересно, вы хоть раз читали про механизмы блокировок для конкретных СУБД. Уже лет 8 или более с появления Oracle 7 блокировки накладываются только на модифицируемые строки. Причем есть разные виды блокировок. Печально, что человек занимающийся внедрением таких крупных систем не знает основ работы хранилищь данных которые используются. Проверка целостности на уровне БД будет происходить намногнг быстрее чем та которую вы сможете написать сами на сервере приложений. Даже если вы примените одни и те-же алгоритмы у вас еще всегда будут накладные расходы на получение данных с сервера БД и создание структур для хранения этих данных в памяти. Поверте мне при определенном кол-ве записей эти затраты весьма существенны. В сервере БД механизмы блокировок реализованы на уровне ядра. Используют специальные структуры которые доступны постояно в процессе работы сервера (например кеш данных). В связи с этим эффективность внешних ключей на порядок выше. Другое дело что обеспечить переносимость между серверами и использовать их при разработке с помощью API достаточно сложно поэтому и используют в таких системах достаточно редко.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33413084
9
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
9
Гость
автор
Ну, получил 2%
прироста, шо дальше


мои результаты тоже блезки к этим. прирост производительности не более 2%. Так стоит из-за этого отказываться от потенциальных проблем с целостностью?
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33413164
Фотография AnS1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
в sap нет FK на уровне СУБД
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33413241
Tov. Drujba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AnS1в sap нет FK на уровне СУБД
На уровне СУБД - возможно. Я напрямую в БД никогда не ходил. Только через R/3. Да и что там делать, таблицы то в сапе не только transparent но и cluster...
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33420542
Фотография AnS1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Tov. Drujba AnS1в sap нет FK на уровне СУБД
На уровне СУБД - возможно. Я напрямую в БД никогда не ходил. Только через R/3. Да и что там делать, таблицы то в сапе не только transparent но и cluster...

не только. Используя стандартный open sql вы можете похерить любую целостность, заданную на уровне словаря данных
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33420565
Tov. Drujba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AnS1не только. Используя стандартный open sql вы можете похерить любую целостность, заданную на уровне словаря данных
Кто бы сомневался :). Ломать не строить. Но я не могу представить себе ситуацию, когда бы мне пришлось прибегать к подобным методам.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33423061
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
когда нужны проверки на ФК:
unsert - непротиворечивость легко обеспечивает правильное приложение
update - не требуеся, т.к. ФК не должны вообще изменяться
delete - единственный случай, когда действительно надо проверять, но это может делать приложение (все таки это редкое действие)
вывод: ФК не нужны (и разработчики ERP это прекрасно знают !)
а все чему учат в институтах - пора забыть
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33423206
bI-Ky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
модкогда нужны проверки на ФК:
unsert - непротиворечивость легко обеспечивает правильное приложение
update - не требуеся, т.к. ФК не должны вообще изменяться
delete - единственный случай, когда действительно надо проверять, но это может делать приложение (все таки это редкое действие)
вывод: ФК не нужны (и разработчики ERP это прекрасно знают !)
а все чему учат в институтах - пора забыть
Ну да, а разработчики RDBMS об этом не догадываются. Перестаньте себя считать умнее настоящих специалистов.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33423234
michael_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
модкогда нужны проверки на ФК:
unsert - непротиворечивость легко обеспечивает правильное приложение
update - не требуеся, т.к. ФК не должны вообще изменяться
delete - единственный случай, когда действительно надо проверять, но это может делать приложение (все таки это редкое действие)
вывод: ФК не нужны (и разработчики ERP это прекрасно знают !)
а все чему учат в институтах - пора забыть

Правильно! Ну эти UPDATE и DELETE, только INSERT, все правки - методом сторнирования! (Кроме шуток именно такую методологию в западных системах нередко можно встретить) А при "unsert - непротиворечивость легко обеспечивает правильное приложение" (с)
)
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33423391
Whateva
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
michael_все правки - методом сторнирования! (Кроме шуток именно такую методологию в западных системах нередко можно встретить)
Вы наверное 1С-ом занимались плотно
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33423434
Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
модкогда нужны проверки на ФК:
unsert - непротиворечивость легко обеспечивает правильное приложение
update - не требуеся, т.к. ФК не должны вообще изменяться
delete - единственный случай, когда действительно надо проверять, но это может делать приложение (все таки это редкое действие)
вывод: ФК не нужны (и разработчики ERP это прекрасно знают !)
а все чему учат в институтах - пора забыть
Уважаемый, Вы где учились?
"unsert - непротиворечивость легко обеспечивает правильное приложение" - теоретически обеспечивать должно, но от проверки отказываться не следует.
"update - не требуеся, т.к. ФК не должны вообще изменяться" - это пардон кто сказал такую чушь? те у записи нельзя поменять какие-нибудь поля состояний, или справочные поля оформленные как ФК.
"delete - единственный случай, когда действительно надо проверять, но это может делать приложение (все таки это редкое действие)" - вы что-нибудь слышали про атомарность? Как насчет случая подвисания приложения?

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

А что тут обсуждать-то? Проблема высосана из пальца. Совершенно несущественные временные затраты на некритичных к скорости операциях - засчет гарантии непротиворечивости связей и упрощения бизнес-логики. Равняться в плане наличия-отсутствия внешних ключей на существующие системы бессмысленно, потому что причины их неиспользования при проектировании этих баз данных, вероятнее всего, никак не связаны с быстродействием (уж структура БД R/3 точно не образец). О селектах заботились бы лучше, а не модификаторах.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33429421
Фотография 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
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33574899
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На самом деле то, что FK "тормозят" работу -- это еще вопрос. Они могут, но это вовсе не обязательно. Например у нас были и FK, и проверки явные в логике процедур.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33574988
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Насколько мне подсказывает логика, то не должны,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЗЫ. Возможно, я все-таки не понял, что Вы хотели сказать.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33584013
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И, опять же я не вижу, каким образом ее (бизнес-логики) присутствие в том или ином виде потребует отказаться от DRI?!Всё довольно прозаично.
Разработка в ERP предусматривает работу в одном инструменте - IDE этой самой ERP. Написание триггеров и FK лежит вне всяких IDE. Т.е. как напишет программист на X++,ABAP,C/AL и т.д. так и будет. Забудет что-то - будут битые ссылки.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33586675
Whateva
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer1. Производительность этой ERP, особенно ее кастомизаций, просто потрясает.
"Вы их просто не умеете готовить" :-)
softwarer2. Ключей там нет. Точнее, есть в следовых количествах.
Ну так сложилось.
softwarer3. Данные уже кривые.
Спорю что данные стали "уже кривыми" в результате работы интерфейсов написанными 500-долларывыми разработчиками которые только вчера узнали чем SQL отличается от PL/SQL. Пока наши уважаемые "интеграторы" будут проводить политику "ввяжемся в бой а потом будет видно" так оно и будет. Чюдес не бывает.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33586702
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WhatevaНу так сложилось.

Ага! А не из-за того, что система писалась теми самыми "500-долларывыми разработчиками"?!


WhatevaСпорю что данные стали "уже кривыми" в результате работы интерфейсов написанными 500-долларывыми разработчиками которые только вчера узнали чем SQL отличается от PL/SQL. Пока наши уважаемые "интеграторы" будут проводить политику "ввяжемся в бой а потом будет видно" так оно и будет. Чюдес не бывает.

Будь разработчик хоть семи пядей во лбу и с зарплатой в 5 000 - это не даст 100% гарантии сохранности целостности бд при разработке кастомизаций, если сама бд в ее базовой конфигурации эту целостность не поддерживает.

"Нечего на зеркало пинять,коли рожа крива". ((с) не помню чей).
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33586711
Whateva
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pkarklinИ в результате, на продакшен окружениях той самой OEBS с определенной периодичность всплывают такие битые ссылки. Нет никакого оправдания разработчикам, который оставил хранилище вот таким вот незащищенным. И никакие увещевания в юзер гайдах типа "Запрещается лазить в базу чем-либо другим, кроме самой системы" здесь не помогут. Детский сад какой-то, надо не просить, а на корню пресекать попытки разрушения целостности хранилища. Оно (хранилище) должно быть самодостаточно в его базовой функциональности.

IMHO.
То же самое. Не надо давать неокрепшим горе-разработчикам доступ "пиши чего хочешь" к базе. Тем более PROD. На PROD разработчики в принципе доступа иметь не должны. А администратору за такие вещи надо по шапке надавать - работу он свою плохо делает.
Вы в свою машину масло наливаете в соответствии с рекомендациями производителя или какое придётся? А то ведь под капот в принципе можно чего угодно залить. Следуя вашей логике капот надо закрывать на замок и открывать только на авторизированных станциях тех. обслуживания.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33586746
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Whateva

Считаю Вашу аналогию с заменой масла абсолютно не уместной. А вот аналогию с прессом могу привести. Может быть видели, когда пресс с ручной загрузкой опускается, там перед рабочей областью проскакивает "железяка", которая отбрасывает руку зазевавшегося оператора, дабы ИСКЛЮЧИТЬ НА КОРНЮ САМУ ВОЗМОЖНОСТЬ травмотизма. И именно с этим можно сравнить наличие ограничений в самом хранилище.

WhatevaСледуя вашей логике капот надо закрывать на замок и открывать только на авторизированных станциях тех. обслуживания.

Следуя моей логике надо создавать хранилише так, чтоб потом "не было мучительно больно", даже если в систему залезет полный 0.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33586775
Whateva
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pkarklinАга! А не из-за того, что система писалась теми самыми "500-долларывыми разработчиками"?!
А Вы в курсе кем писались основные финансовые модули или там process manufacturing? Отсутствие (Ок, практическое отсутствие) декларативной целостности на уровне RDBMS сложилось задолго до переноса разработок в Бангалор.
pkarklinБудь разработчик хоть семи пядей во лбу и с зарплатой в 5 000 - это не даст 100% гарантии сохранности целостности бд при разработке кастомизаций, если сама бд в ее базовой конфигурации эту целостность не поддерживает.

"Нечего на зеркало пинять,коли рожа крива". ((с) не помню чей).
Вы не поверите, но опыт незаменимая штука. И наличие или отсутствие декларативной целостности не спасёт от грязи в базе в "умелых" руках.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33586832
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WhatevaА Вы в курсе кем писались основные финансовые модули или там process manufacturing? Отсутствие (Ок, практическое отсутствие) декларативной целостности на уровне RDBMS сложилось задолго до переноса разработок в Бангалор.

В курсе. И что?! Я должен испытывать трепет от этого?! Да ни за что?! Не от чего там трепетать?! Как раз на оборот, только волосы дыбом на всех частях тела встают от такого, с позволения сказать, хранилища.

WhatevaВы не поверите, но опыт незаменимая штука. И наличие или отсутствие декларативной целостности не спасёт от грязи в базе в "умелых" руках.

Вы не поверите, я в курсе, что такое опыт! А Вы, пытаясь оправдать отсутствие в хранилишще ограничений, то приводите аргументы в виде 500-долларовых разработчиков, то, вдруг, "умелые руки". 500-долларовй разработчик, нарвавшись на ограничение не сможет (из-за 500 долларовых знаний) его отключить, а "умелые руки" 100 раз подумают перед отключением, основываясь на том самом опыте.

Свою позицию по сабжевой проблеме я высказал и пока достойных аргументов в ее оправдание я не вижу.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33587935
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Whateva"Вы их просто не умеете готовить" :-)
Не я. Я в данном случае пришел сбоку посмотреть на это чудо.

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

WhatevaНу так сложилось.
Это-то понятно.

Но это не ответ.

WhatevaСпорю что данные стали "уже кривыми" в результате работы интерфейсов
Представления не имею, и не знаю способа узнать.

Впрочем, не вижу какая разница. Главное - результат: данные кривые. "Кто виноват" - нехай интересует прокурора. Мне, как не самому рядовому специалисту, важно "что делать" с этим дерьмом при условии, что на выходе от меня ожидают конфетку.

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

WhatevaПока наши уважаемые "интеграторы" будут проводить политику "ввяжемся в бой а потом будет видно" так оно и будет. Чюдес не бывает.
То есть Вы предлагаете брать гуру и хотеть от них чудес? Хмм... не думаю, что хоть один гуру пойдет на такую скучную работу как OEBS.

Нет уж, я предпочту методику, достаточную для получения пристойного результата от среднего разработчика. И ключи являются ее частью. Да и время гуру совершенно незачем тратить на такую хрень.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33587936
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WhatevaТо же самое. Не надо давать неокрепшим горе-разработчикам доступ "пиши чего хочешь" к базе. Тем более PROD. На PROD разработчики в принципе доступа иметь не должны.
И какое отношение эта эскапада имеет к описанной мной ситуации? Разработчики доступа на прод не имеют. Данные на проде кривые - только сегодня нашли очередные. Что дальше?

WhatevaА администратору за такие вещи надо по шапке надавать - работу он свою плохо делает.
Администратор там - отдельный вопрос. Я рассказал ему кое-что, чего он не знал, но у меня нет никаких оснований считать его "плохим администратором OEBS".

Пока что видна в основном Ваша склонность к непомерным обобщениям. Которая обычно лезет из двух причин - либо из опыта решения большого количества проблем, попытка сначала на рефлексе выдать типовое решение, либо наоборот, из малого опыта, который представляется большим.

WhatevaСледуя вашей логике капот надо закрывать на замок и открывать только на авторизированных станциях тех. обслуживания.
Следуя нашей логике, вход для масла должен отвергать попытку налить в него жидкость, не соответствующую критериям производителя. Например воду.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33588894
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pkarklin ModelRНу и как должно выглядеть самодостаточное бухгалтерское хранилище? Чтобы в базовой функциональности изменение счета в проводке
- контролировалось по правилам корреспонденции счетов,
- вызывало изменение сохраненных остатков,
и др.

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

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

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

ЗЫ. Возможно, я все-таки не понял, что Вы хотели сказать.
Сорри за поздний ответ, но возможно еще интересно....
Мысль в том, что RI - часть бизнес-правил, бизнес-ограничений в целом, причем по объему - очень небольшая часть. С точки зрения ERP нарушение RI ничем не отличается от нарушения корееспонденции счетов - транзакция отвергается. Так зачем размазывать контроль бизнес-ограничений: проверять RI через DRI в СУБД, а корреспонденцию - на сервере приложений? Тем более, что реакцию на эксепшион СУБД все равно нужно как-то обработать в приложении.
Ну будет СУБД ловить 5% нарушений при попытке влезть в СУБД в обход ERP - а база все равно станет не корректной из-за нарушения корреспонденции.
Так что архитектура с отказом от ФК в СУБД вполне логична, если существует слой контроля бизнес-ограничений в приложении.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33589034
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelRМысль в том, что RI - часть бизнес-правил, бизнес-ограничений в целом, причем по объему - очень небольшая часть.

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

ModelRС точки зрения ERP нарушение RI ничем не отличается от нарушения корееспонденции счетов - транзакция отвергается. Так зачем размазывать контроль бизнес-ограничений: проверять RI через DRI в СУБД, а корреспонденцию - на сервере приложений? Тем более, что реакцию на эксепшион СУБД все равно нужно как-то обработать в приложении.

Вот и я всегда спрашиваю - а зачем размазывать?! Для тех, кто не в курсе - я противник пихания N-звенок куда не поподя. Почему бы ВСЕ не контролировать в хранилище?! Что-то с помощью DRI, а что-то с помощью хп, триггеров и т.п., реализующих требования бизнес-логики. Пусть Ваш "средний слой" будет клиентом самодостаточного хранилища, дергающим нужные хп (пакеты) для выполнения той или иной бизнес-процедуры. В принципе, OEBS - это PL\SQL клиент, где подавляющее большинство логики реализовано имеено в пакетах.

ModelRНу будет СУБД ловить 5% нарушений при попытке влезть в СУБД в обход ERP - а база все равно станет не корректной из-за нарушения корреспонденции.

СУБД может\должна ловить до 100% нарушений!!!

ModelRТак что архитектура с отказом от ФК в СУБД вполне логична, если существует слой контроля бизнес-ограничений в приложении.

Не хочу снова разводить флейм, но логики в переносе операций обработки данных подальше от самих данных я не вижу. Флэйм можно почитать здесь: Странные мысли о 3-звенном приложении

Все вышесказанное - IMHO.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33589060
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pkarklinДля тех, кто не в курсе - я противник пихания N-звенок куда не поподя.
Хорошо рассуждаете. Только обсуждаемая проблема никак конечно с n-звенностью приложений не связана.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33589100
OA User
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelR
Так что архитектура с отказом от ФК в СУБД вполне логична, если существует слой контроля бизнес-ограничений в приложении.

Поддержу. Судя по экземпляру OEBS, который крутится у нас, 95% проблем связаны с кривой "кастомизацией". Приятные вещи вылезают, когда, например вместо pub-пакетов используются pvt-пакеты, и при обновлении системы форма просто разваливается. Отчеты, "заточенные" на определенные значения полей, выдают "прекрасные" результаты. Глюки самой системы тоже присутствуют, но они практически все были вылечены обновлениями.
Я бы не стал так уж раздувать проблему отсутствия ФК, по моим наблюдениям, залезая ниже определенного уровня API, наши мастера selecta'а и insert'а многое могут угробить, да так талантливо, что никакие ФК не спасут.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33589161
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafm pkarklinДля тех, кто не в курсе - я противник пихания N-звенок куда не поподя.
Хорошо рассуждаете. Только обсуждаемая проблема никак конечно с n-звенностью приложений не связана.

Эээ... ModelR аргументировал отсутвие DRI в хранилище присутсвием среднего звена, реализующего все и вся, т.е. отказом от размазывания реализации ограничений на разных уровнях системы. Поэтому я и спросил\сказал, а задлянафига вообще такое размазывание, имея в виду N-звенки, приведя тред с обсуждением на эту тему.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33589215
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelRМысль в том, что RI - часть бизнес-правил, бизнес-ограничений в целом, причем по объему - очень небольшая часть.
Можно так считать. Причем следует отметить, что эта часть также неочевидная в проявлениях и плохо проверяемая при разработке.

ModelRТак зачем размазывать контроль
Потому что для надежности решения крайне рекомендуется проверять везде, где только возможно и не слишком напряжно. И из занятий репликацией, и из других работ я вынес простой принцип: проверок много не бывает. Также, надеюсь, Вы согласитесь с тем, что для столь масштабного проекта надежность каждой детали имеет значение "выше среднего".

По сути, Вы говорите примерно следующее: если LookupComboBox не способен выбрать запись, отсутствующую в справочнике, делать внешний ключ на этот справочник необязательно, все и так будет хорошо. В чем-то это верно, но на практике рано или поздно вылезет проблема, например при удалении из этого справочника.

ModelRНу будет СУБД ловить 5% нарушений при попытке влезть в СУБД в обход ERP - а база все равно станет не корректной из-за нарушения корреспонденции.
По этой логике мыться бессмысленно, потому как в итоге все равно умрешь. Нужно проверять и то, и другое, и третье. Есть возможность проверить это "третье" исключительно дешево и надежно. И отказываться от этого - примерно так же оправданно, как прыгать с парашютом без запаски.

ModelRТак что архитектура с отказом от ФК в СУБД вполне логична,
Не вижу "логичности". Вы доказываете, что она не "однозначно самоубийственна" - и это так. Она просто глупа и неудачна.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33589269
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OA UserПоддержу. Судя по экземпляру OEBS, который крутится у нас, 95% проблем связаны с кривой "кастомизацией".
Нисколько не спорю. И кому легче от того, что знают, что ругать надо именно "кастомизаторов"? Допустим, сейчас кто-нибудь подойдет и вылечит диск на Вашем сервере NDD версии 4.0 - Вам что, станет легче от мысли, что дядя Петя Нортон тут не при чем?

OA UserЯ бы не стал так уж раздувать проблему отсутствия ФК,
Вопрос в том, что значит "так уж". Можно жить без ФК, без транзакций, без чего угодно. Можно подменять их самописками. Вопрос лишь в качестве результата.

Прямо сейчас у меня есть конкретные наблюдения. Есть хранилище под OLAP, закачиваемое из OEBS. Есть цифры, которые сходятся с ожидаемыми заказчиком. И есть некоторые записи/цифры, с которыми неизвестно чего делать, потому как внешние ключи попросту битые.

OA Userпо моим наблюдениям, залезая ниже определенного уровня API, наши мастера selecta'а и insert'а многое могут угробить, да так талантливо, что никакие ФК не спасут.
Могут. И если им придется думать еще и о внешних ключах - наверняка угробят. Так хоть есть шанс.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33589326
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OA UserСудя по экземпляру OEBS, который крутится у нас, 95% проблем связаны с кривой "кастомизацией". Приятные вещи вылезают, когда, например вместо pub-пакетов используются pvt-пакеты, и при обновлении системы форма просто разваливается. Отчеты, "заточенные" на определенные значения полей, выдают "прекрасные" результаты. Глюки самой системы тоже присутствуют, но они практически все были вылечены обновлениями.

Опять позволю себе процитировать классика: "Нечего на зеркало пинять, коль рожа крива" - читай "кривая" архитектура хранилища. Каковы бы не были по уровню знаний\опыта мои разработчики, реализующие бизнес-логику в хп, они никогда не смогут по своей невнимательности\неопытности удалить шапку документа, предварительно не удалив табличную часть, или удалить клиента, у которого есть заказ. Т.е. обойти ограничения, заложенные в базовую архитектуру хранилища.


OA UserЯ бы не стал так уж раздувать проблему отсутствия ФК, по моим наблюдениям, залезая ниже определенного уровня API, наши мастера selecta'а и insert'а многое могут угробить, да так талантливо, что никакие ФК не спасут.

Спору нет. Но если им еще придеться в каждой процедуре "вспоминать" о необходимости выполнения проверок RI, которую не поддерживает хранилище, то они точно забудут это сделать!
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33589440
OA User
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
По сути, Вы говорите примерно следующее: если LookupComboBox не способен выбрать запись, отсутствующую в справочнике, делать внешний ключ на этот справочник необязательно, все и так будет хорошо. В чем-то это верно, но на практике рано или поздно вылезет проблема, например при удалении из этого
Тут ведь и другой вариант возможен - система сделает запись в справочнике неактивной, и ничего удалять не придется, проблема, соответственно , не вылезет.
Конечно, средствами БД удалить запись запросто, а на уровне бизнес-логики это уже не сделаешь. А мне, как пользователю системы, это ведь безразлично, правда? Главное, что ненужная для выборки запись в эту выборку не попадет. Пример тривиальный, но показательный весьма.
Другой случай. Разработал один коллега модуль, по функционалу похожий на concurrent manager. Т.е. сам запускает нужное количество запросов, сам ждет их выполнения и т.д. Целостность не нарушил. Все бы хорошо, но с родным менеджером в итоге случается dead lock со всеми вытекающими последствиями. Сделано было только из-за того, что человек не стал с наборами запросов разбираться. Переделали, в итоге обошлись без дополнительного кода вообще.
Я хочу сказать, что дорабатывая некую ERP-систему, надо придерживаться определенных правил игры, в которых информация о наличии/отсутствии ФК, в частности, не столь существенна. Повторюсь, но, по-моему, проверка заранее непротиворечивых данных не всегда имеет смысл.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33589475
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pkarklinЭээ... ModelR аргументировал отсутвие DRI в хранилище присутсвием среднего звена, реализующего все и вся, т.е. отказом от размазывания реализации ограничений на разных уровнях системы. Поэтому я и спросил\сказал, а задлянафига вообще такое размазывание, имея в виду N-звенки, приведя тред с обсуждением на эту тему.
Все и вся реализовать на среднем уровне нет возможности, в этом я с Вами согласен. А n-звенки призваны решать другие задачи.

ModelR , спрогнозируйте поведение системы на рисунке ниже. В различных ситуациях, в зависимости от того, кто первый стартанет транзакцию. Ведь практически все называют множество серверов приложений в качестве средства масштабирования, и это нормально. Вот только с целостностью данных (не путайте с правильностью транзакций с точки зрения бизнес-логики)в этом случае нужно что-то делать. Иначе и через рекомендуемый API такого понаделают. Или будете играться уровнями изоляции сводя на нет достигнутую таким образом производительность?
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33589505
OA User
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pkarklin
Опять позволю себе процитировать классика: "Нечего на зеркало пинять, коль рожа крива" - читай "кривая" архитектура хранилища. Каковы бы не были по уровню знаний\опыта мои разработчики, реализующие бизнес-логику в хп, они никогда не смогут по своей невнимательности\неопытности удалить шапку документа, предварительно не удалив табличную часть, или удалить клиента, у которого есть заказ. Т.е. обойти ограничения, заложенные в базовую архитектуру хранилища.

Отлично, но здесь аналогичные ограничения заложены не в базовую архитектуру хранилища, а выражены в соответствующих пакетах, которыми пользуется разработчик и т.д. Если их изучить и корректно использовать, то почему Вы потеряете в надежности?
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33589549
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OA UserОтлично, но здесь аналогичные ограничения заложены не в базовую архитектуру хранилища, а выражены в соответствующих пакетах, которыми пользуется разработчик и т.д. Если их изучить и корректно использовать, то почему Вы потеряете в надежности?

На протяжении уже нескольких страниц я пытаюсь донести, что проблема кроется как раз в этом самом "Если..."! Т.е. такое хранилище имеет УСЛОВНУЮ поддержку целостности. А это, с моей точки зрения, является грубейшим просчетом проектирования. А к чему такие "просчеты" приводят, уже говорилось.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33589627
OA User
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pkarklin

На протяжении уже нескольких страниц я пытаюсь донести, что проблема кроется как раз в этом самом "Если..."! Т.е. такое хранилище имеет УСЛОВНУЮ поддержку целостности. А это, с моей точки зрения, является грубейшим просчетом проектирования. А к чему такие "просчеты" приводят, уже говорилось.
А с моей точки зрения это самое "Если..." и есть критерий знания разработчиком системы в целом, не СУБД, не средств разработки, не сетевых там каких-то вещей, а именно системы. Все неудачные примеры, которые я приводил, сделаны-то людьми весьма грамотными с точки зрения просто разработки на PL/SQL в частности. Они с Oracle не один год работали, но подход, к которому они привыкли, механически перенесенный в среду определенной системы, дает совершенно непредсказуемые результаты.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33589632
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer ModelRТак зачем размазывать контроль
Потому что для надежности решения крайне рекомендуется проверять везде, где только возможно и не слишком напряжно. И из занятий репликацией, и из других работ я вынес простой принцип: проверок много не бывает. Также, надеюсь, Вы согласитесь с тем, что для столь масштабного проекта надежность каждой детали имеет значение "выше среднего".
.Чем плохи общие рассуждения? Их легко довести до абсурда :). Для надежности может и проверку CRC всюду собственную засандалить. softwarer
По сути, Вы говорите примерно следующее: если LookupComboBox не способен выбрать запись, отсутствующую в справочнике, делать внешний ключ на этот справочник необязательно, все и так будет хорошо. В чем-то это верно, но на практике рано или поздно вылезет проблема, например при удалении из этого справочника.Нет, я говорю, что удаление - также операция среднего слоя, и он проверяет все бизнес-правила, связанные с удалением, включая наличие ссылок на удаляемый объект. ФК СУБД в этом случае греет воздух вхолостую - проверяет уже проверенное. Его единственное назначение - а вдруг кто пойдет в обход? - но не будем повторяться.
Кстати, даже удаление может быть связано с логикой, не доступной DRI. Скажем, если ссылающийся объект "дешевый" - то CASCADE его, а иначе RESTRICT. softwarer
ModelRНу будет СУБД ловить 5% нарушений при попытке влезть в СУБД в обход ERP - а база все равно станет не корректной из-за нарушения корреспонденции.
По этой логике мыться бессмысленно, потому как в итоге все равно умрешь. Нужно проверять и то, и другое, и третье. Есть возможность проверить это "третье" исключительно дешево и надежно. И отказываться от этого - примерно так же оправданно, как прыгать с парашютом без запаски.
Не внимательны, коллега. Вопрос не нужно/ненужно, а где проверять и сколько раз. Следуя Вашим примерам - Иногда нужно все-таки выходить из-под душа. А если повесить десяток запасок, боюсь будет тоже, что не брать парашют вообще.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33589729
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OA UserА с моей точки зрения это самое "Если..." и есть критерий знания разработчиком системы в целом, не СУБД, не средств разработки, не сетевых там каких-то вещей, а именно системы. Все неудачные примеры, которые я приводил, сделаны-то людьми весьма грамотными с точки зрения просто разработки на PL/SQL в частности. Они с Oracle не один год работали, но подход, к которому они привыкли, механически перенесенный в среду определенной системы, дает совершенно непредсказуемые результаты.

Я не пытаюсь оспаривать Вашу точку зрения. Я излагаю свою, без привязки к какой-то конкретной ERP системе. И мои высказывания касаются моего мнения об общих подходах к проектирования такой ответственной части, как хранилище системы класса ERP. Сабжевый вопрос касался имеено общих подходов, так как "под раздачу" попали крупнейшие на сегодняшний день ERP системы.

Я считаю, что такое понятие как Разработчик хранилища, а еще круче Архитектор хранилища не должно иметь к себе приписку с названием и условностями той или иной системы. Я готов смириться с особенностями некоторых ERP систем, но вот с "условностями поддержки целостности", извините меня, смириться не могу.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33589738
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafm ModelR , спрогнозируйте поведение системы на рисунке ниже. В различных ситуациях, в зависимости от того, кто первый стартанет транзакцию. Ведь практически все называют множество серверов приложений в качестве средства масштабирования, и это нормально. Вот только с целостностью данных (не путайте с правильностью транзакций с точки зрения бизнес-логики)А как не путать-то? Что СУБД по счастью умеет декларативно - это целостность, а остальное - не целостность? iscrafmв этом случае нужно что-то делать. Иначе и через рекомендуемый API такого понаделают. Или будете играться уровнями изоляции сводя на нет достигнутую таким образом производительность?
В вашем примере через аппсервер выполняется нативный кода СУБД. по сути это работа в обход аппсервера. Результат ИМХО тот же - 95% бизнес правил остаются без внимания.
Или я чего-то не понял?
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33589802
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelRА как не путать-то? Что СУБД по счастью умеет декларативно - это целостность, а остальное - не целостность?

Есть отличие между неправильной транзакцией (исправимо) и безадресной транзакцией. Вам о чем-то говорит платеж клиента {90676D43-82AD-11DA-947D-0020ED19160F}? Или так - CST00128, если суррогатные ключи не любите.


ModelRВ вашем примере через аппсервер выполняется нативный кода СУБД. по сути это работа в обход аппсервера. Результат ИМХО тот же - 95% бизнес правил остаются без внимания.
Или я чего-то не понял?

Сервер приложений с БД в конечном итоге общается на понятном ей языке. Я привел пример конечного итога, упустив моменты, каким образом этот код образовался. В данном вопросе это не важно.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33590001
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmЕсть отличие между неправильной транзакцией (исправимо) и безадресной транзакцией. Вам о чем-то говорит платеж клиента {90676D43-82AD-11DA-947D-0020ED19160F}? Или так - CST00128, если суррогатные ключи не любите.Не понял разницу. Безадресная исправима проставлением нужного адреса, или добавлением адресата - смотря как понять"безадресная". Вот скажите, правило "Структура изделия не содержит циклов" это разве не целостность данных? Или пока соотвествующая кляуза не появится в SQL - оно и не целостность? iscrafm
Сервер приложений с БД в конечном итоге общается на понятном ей языке. Я привел пример конечного итога, упустив моменты, каким образом этот код образовался. В данном вопросе это не важно. ИМХО важно. Скорее всего этот код будет частью некоторых транзакций, которые будут содержать блокировки и проверки, что и обеспечит целостность.
Насчет как блокировать тут коллеги по соседству бодаются . И если аппсервер имеет собственный механизм блокировок, то они просто не видимы для СУБД и тут даже ФК не спасет при работе мимо приложения.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33590017
OA User
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pkarklin
Я считаю, что такое понятие как Разработчик хранилища, а еще круче Архитектор хранилища не должно иметь к себе приписку с названием и условностями той или иной системы. Я готов смириться с особенностями некоторых ERP систем, но вот с "условностями поддержки целостности", извините меня, смириться не могу.
Мы, наверное, друг друга не поняли. Я ни в коем случае не рассматриваю отказ от в ФК как краеугольный принцип проектирования подобных систем. Речь идет о разумном, с моей точки зрения, компромиссе. Если проектировщик системы (не хранилища) заранее знает, что при использовании определенного API во всей системе в таблицу не попадут непротиворечивые данные, то зачем ему дополнительная страховка в виде ФК? Ей вполне можно пожертвовать в угоду производительности и прочих вещей.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33590087
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OA UserРечь идет о разумном, с моей точки зрения, компромиссе.

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

OA UserЕсли проектировщик системы (не хранилища) заранее знает, что при использовании определенного API во всей системе в таблицу не попадут непротиворечивые данные, то зачем ему дополнительная страховка в виде ФК?

И опять у Вас "Если..." не буду повторяться.

авторЕй вполне можно пожертвовать в угоду производительности и прочих вещей.

Замена FK (механизма, работающего на уровне реляционного движка) на самописные провекри на уровне какого-либо API никак не добавит производительности системы. И с этим спорить бесполезно. А вот про "прочие вещи", в угоду которым Вы готовы пожертвовать DRI я готов рассмотреть.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33590231
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
С одним наверно все согласятся.
Наличие внеших ключей - не гарантия целостности.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33590430
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelRС одним наверно все согласятся.
Наличие внеших ключей - не гарантия целостности.

Эээ... 100% гарантию дает только бог. ;) Естественно, что если обременный правами человек отключил ограничения для проведения какой-либо затейлевой операции, а потом забыл их включить, или создал их без проверки на соответствие имеющихся данных новому ограничению, то да.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33590485
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OA UserТут ведь и другой вариант возможен - система сделает запись в справочнике неактивной, и ничего удалять не придется, проблема, соответственно , не вылезет.
Вылезет другая - например, по какой-нибудь операции типа "создать документ на основании документа" ссылка будет откопирована в новый документ, а там в комбобоксе такого варианта уже нет, поскольку запись в справочнике неактивна. Любое решение порождает свои проблемы, и отказ от FK, безусловно, кое-где помогает - но в целом..... мне довелось работать с разными структурами баз, в том числе более извращенными, чем с отсутствующими FK, но в "классической" мне комфортнее. Меньше проблем.

OA UserКонечно, средствами БД удалить запись запросто, а на уровне бизнес-логики это уже не сделаешь. А мне, как пользователю системы, это ведь безразлично, правда? Главное, что ненужная для выборки запись в эту выборку не попадет.
Вам, как пользователю системы, важно, чтобы в системе не было кривых данных. К примеру, мы проверили - в соответствующие формы ввода-просмотра эти записи не попадают, видимо битые ключи не пускают. А в каком-нибудь отчете, как опять же догадываетесь, наверняка суммируются. То есть данные не то что некорректны - противоречивы внутри бизнес-логики. И куда это годится?

OA UserЯ хочу сказать, что дорабатывая некую ERP-систему, надо придерживаться определенных правил игры,
Хм. Безусловно, разрабатывая кастомизацию, нужно следовать технологии, предложенной вендором и не плодить своих противоречащих ей решений. И я безусловно далек от мысли помочь клиенту, создав-таки внешние ключи на OEBS-ных таблицах.

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

OA UserПовторюсь, но, по-моему, проверка заранее непротиворечивых данных не всегда имеет смысл.
А где Вы нашли "заранее непротиворечивые данные"?

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

Собственно, сегодня один из ключевых пользователей во всеуслышанье сказал банальную фразу - "у Oracle есть один хороший продукт: база, а все остальное - полное ..." В общем-то это относилось в первую очередь к Collaboration Suite, и явно было вызвано не только и не столько FK, но тем не менее - названные Вами правила игры приводят к результату..
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33590569
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelRЧем плохи общие рассуждения? Их легко довести до абсурда :). Для надежности может и проверку CRC всюду собственную засандалить.
Доведение до абсурда - хороший критерий для анализа утверждений. В данном случае обратите внимание на "где не слишком напряжно". То есть там, где разумно по качество/цена.

Я не очень в курсе, где в OEBS используется CRC и как, но например CRC-подобные возможности БД, исключающие, в частности, возможность легко и просто подправить руками файлы базы, вполне уместны, и отключение их, будь оно возможным, было бы глупостью.

ModelRФК СУБД в этом случае греет воздух вхолостую - проверяет уже проверенное. Его единственное назначение - а вдруг кто пойдет в обход?
Не единственное, хотя основное. Второе - защита от ошибок в бизнес-правилах и во внутренней реализации бизнес-логики.

ModelRКстати, даже удаление может быть связано с логикой, не доступной DRI. Скажем, если ссылающийся объект "дешевый" - то CASCADE его, а иначе RESTRICT.
Если извращаться из принципа, то DRI можно описать очень много :) Другой вопрос, что это не имеет практического смысла.

Я нисколько не пытаюсь доказать, будто FK спасут от всех бед. Они всего лишь очень дешево спасут от некоторых реально существующих бед. И красивые рассуждения о централизованной проверке бизнес-правил нисколько не мешают мне любоваться кривыми записями, относительно которых никто не знает, что с ними делать, никто не признается, что это его работа и никто не хочет взять на себя смелость их грохнуть.

ModelRНе внимательны, коллега. Вопрос не нужно/ненужно, а где проверять и сколько раз.
Да не сказал бы, что именно я невнимателен, если учесть, что именно об этом говорил в первых фразах.

ModelRСледуя Вашим примерам - Иногда нужно все-таки выходить из-под душа. А если повесить десяток запасок, боюсь будет тоже, что не брать парашют вообще.
Дык ведь не следуя же. Вы предлагаете ни одной не вешать; один централизованный парашют и все.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33590680
OA User
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerА где Вы нашли "заранее непротиворечивые данные"?

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

Собственно, сегодня один из ключевых пользователей во всеуслышанье сказал банальную фразу - "у Oracle есть один хороший продукт: база, а все остальное - полное ..." В общем-то это относилось в первую очередь к Collaboration Suite, и явно было вызвано не только и не столько FK, но тем не менее - названные Вами правила игры приводят к результату..
Тривиальный пример: Практически на любой транзакционной таблице в OEBS есть поля LAST_UPDATED_BY и CREATED_BY. Туда пишутся ID пользователей, которые модифицировали/создали данную запись. Есть табличка FND_USERS , там по ID расшифровывается вся информация, т.е. типичный справочник в данном случае. Текущий ID пользователя можно получить легко после авторизации через fnd_global.USER_ID (боюсь наврать, вроде так :)). Спрашивается, что даст наличие внешнего ключа, если пользователь уже авторизован в системе, т.е. ID заранее непротиворечив? Наличие FK все-таки некий перебор индексных ключей предполагает, не ошибаюсь? И я, кстати, говорил не о замене FK другим механизмом проверки, а об отсутствии такой проверки вообще там, где без нее можно обойтись.
И таких ситуаций очень много. Кроме того, в зависимости от настроек системы некоторые ограничения могут и не потребоваться вообще. Что с ними делать? Включать/отключать каждый раз? :) По-моему, такого монстра поддерживать не проще будет, чем горы пакетов, пусть и сомнительного качества.

P.S.
А репутация Oracle пусть ее акционеров волнует, если честно. Пока вроде они не сильно расстраиваются.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33590746
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OA UserСпрашивается, что даст наличие внешнего ключа, если пользователь уже авторизован в системе, т.е. ID заранее непротиворечив?

Вы пошутили, или действительно не понимаете, к чему может привести отсутствие контроля ссылочных ограничений?!

OA UserТекущий ID пользователя можно получить легко после авторизации через fnd_global.USER_ID

Можно, никто не спорит. Но кто запретит при написании пакета по недосмотру или злому умыслу взять и удалить из таблички FND_USERS запись о пользователи, который числиться в авторах изменений?! Что будет в этом случаи с "по ID расшифровывается вся информация"?!

OA UserНаличие FK все-таки некий перебор индексных ключей предполагает, не ошибаюсь?

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

OA UserИ я, кстати, говорил не о замене FK другим механизмом проверки, а об отсутствии такой проверки вообще там, где без нее можно обойтись.

Приведенный Вами пример как раз описывает обратную ситуацию. Проверки нет там, где она должна была быть. :(

OA UserИ таких ситуаций очень много. Кроме того, в зависимости от настроек системы некоторые ограничения могут и не потребоваться вообще. Что с ними делать? Включать/отключать каждый раз? :) По-моему, такого монстра поддерживать не проще будет, чем горы пакетов, пусть и сомнительного качества.

Каких таких?! Если ограничение завасит от настроек системы, т.е. ограничение, зависящее от бизнесч логики, то естественно, оно не может быть реализовано в виде DRI. Здесь помогут, например, триггера. И включать\выключать ничего не надо будет и поодерживается это на раз-два.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33590755
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer ModelRЧем плохи общие рассуждения? Их легко довести до абсурда :). Для надежности может и проверку CRC всюду собственную засандалить.
Доведение до абсурда - хороший критерий для анализа утверждений. В данном случае обратите внимание на "где не слишком напряжно". То есть там, где разумно по качество/цена.О. И я про тоже. softwarer
Дык ведь не следуя же. Вы предлагаете ни одной не вешать; один централизованный парашют и все.Интересно, Вы вешаете еще и триггер, если уже есть ФК? а ну как отключат, а ну как в СУБД баг. Исходя из разумно по качество/цена иногда от запасок совсем отказываются.
З.Ы.Сколько ни летал, ни разу парашюта собаки не дали:)
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33590860
OA User
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pkarklinВы пошутили, или действительно не понимаете, к чему может привести отсутствие контроля ссылочных ограничений?!

Отчетливо понимаю, к чему может привести, если ДРУГИХ механизмов нет. Я пытаюсь донести мысль, что работа с СУБД и работа с некоей системой, в данном случае OEBS, реализованной пусть на той же СУБД - суть разные вещи.
pkarklin
Можно, никто не спорит. Но кто запретит при написании пакета по недосмотру или злому умыслу взять и удалить из таблички FND_USERS запись о пользователи, который числиться в авторах изменений?! Что будет в этом случаи с "по ID расшифровывается вся информация"?!

Попробуйте это сделать средствами OEBS.
pkarklin
Эээ... Скажем так, наличие индекса на полях, составляющих внешний ключ увеличивает скорость проверки. Впрочем, это поведение аналогично любому другому использованию индекса.

Не спорю, ФК - вещь декларативная, ее реализация - отдельный разговор.
pkarklin
Приведенный Вами пример как раз описывает обратную ситуацию. Проверки нет там, где она должна была быть. :(
OA UserИ таких ситуаций очень много. Кроме того, в зависимости от настроек системы некоторые ограничения могут и не потребоваться вообще. Что с ними делать? Включать/отключать каждый раз? :) По-моему, такого монстра поддерживать не проще будет, чем горы пакетов, пусть и сомнительного качества.
Каких таких?! Если ограничение завасит от настроек системы, т.е. ограничение, зависящее от бизнесч логики, то естественно, оно не может быть реализовано в виде DRI. Здесь помогут, например, триггера. И включать\выключать ничего не надо будет и поодерживается это на раз-два.
Зачем это проверять еще раз?
Можно попробовать навесить все внешние ключи, перенести максимум логики в триггеры и т.д. Не думаю, что работа типичной OLTP системы порадует Вас своей скоростью. Не уверен также, что логика, разбросанная по разным объектам базы данных будет поддаваться какому-либо сопровождению.
В проектировании любых систем всегда имеет место компромисс, и эта история с внешними ключами - типичный тому пример. Видимо, при достижении определенного уровня сложности в бизнес-логике, требований к производительности, надежности и других критериев такое решение вполне имеет право на жизнь.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33591073
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OA UserТривиальный пример: Практически на любой транзакционной таблице в OEBS есть поля LAST_UPDATED_BY и CREATED_BY.
Это пример полей, которые нафиг никому не нужны и которые никак (может быть за очень редкими исключениями) не влияют на работу системы.

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

OA UserКроме того, в зависимости от настроек системы некоторые ограничения могут и не потребоваться вообще. Что с ними делать? Включать/отключать каждый раз?
Нафига? Там будут NULLы, которые не будут ни индексироваться, ни проверяться.

OA UserПо-моему, такого монстра поддерживать не проще будет, чем горы пакетов, пусть и сомнительного качества.
Не очень вижу, как этот вывод следует из ранее изложенного материала. Даже если зачем-то потребуется отключать лишние ключи - написать код, который делает это в одном месте, на два порядка технологичнее, нежели вручную затыкать каждое место, где используется таблица.

OA UserА репутация Oracle пусть ее акционеров волнует, если честно. Пока вроде они не сильно расстраиваются.
Это можно ставить эпитафией ко всему обсуждению. Что бы мы тут ни решили, OEBS от этого не изменится.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33591084
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelR softwarerДык ведь не следуя же. Вы предлагаете ни одной не вешать; один централизованный парашют и все.Интересно, Вы вешаете еще и триггер, если уже есть ФК?
Нет, не вешаю. Это прорва дополнительного кода, нуждающегося в поддержке, это большие траты производительности на переключения контекста, это возможность нарваться на table mutating - итого получается "напряжно".

ModelRИсходя из разумно по качество/цена иногда от запасок совсем отказываются.
Угу. Например, камикадзам парашютов не давали. Как раз тот случай :)

ModelRЗ.Ы.Сколько ни летал, ни разу парашюта собаки не дали:)
Угу. А я знаю ребят, приземлявшихся на запаске :)
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33591755
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OA UserОтчетливо понимаю, к чему может привести, если ДРУГИХ механизмов нет. Я пытаюсь донести мысль, что работа с СУБД и работа с некоей системой, в данном случае OEBS, реализованной пусть на той же СУБД - суть разные вещи.

Я готов бы с Вами согласится, если бы работа с упомянутой системой происходила только на "среднем" уровне, т.е. не имелось бы в принципе возможности обхода ограничений, заложенных на этом уровне. Но на самом деле работа с системой подразумевает ПРЯМОЙ доступ разработчика к хранилищу (через написание пакетов, например, при кастомизации workflow) со всеми вытекающими отсюда последствиями в условиях отсутсвия ограничений.

OA UserПопробуйте это сделать средствами OEBS.

Эээ... Написание пакета в описанном мной выше случаи это разве не "средства OEBS". И что, "это средство OEBS" не даст мне наломать дров?

OA UserЗачем это проверять еще раз?

Что значит "проверять еще раз"?! Проверять надо в одном месте - там где данные храняться, а на среднем звене или классическом клиенте обрабатывать исключительные ситуации.

OA UserМожно попробовать навесить все внешние ключи, перенести максимум логики в триггеры и т.д. Не думаю, что работа типичной OLTP системы порадует Вас своей скоростью.

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

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

Гм... Опять позволю себе с Вами не согласится. Вся логика OEBS разбросана по куче пакетов (десятки тысяч), а не на мифическом "среднем" уровне. Такой же подход использую и я при разработке - использование хп (триггеров) для реализации бизнес-логики. Клиенту остается только в нужный момент вызвать нужную хп. И сопровождаются такие (классические 2ву звенки, даже с многотысячным числом объектов) гараздо проще, чем монстроподорбные N-звенки. IMHO.

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

Вот уже на протяжении 5ти страниц пока еще никто не привел аргументации, кроме надуманных проблем с производительностью и сложностью системы, которая действительно могла бы полсужить отправным моментом в отказе от использования контроля целостности на уровне СУБД.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33592089
OA User
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pkarklin OA UserОтчетливо понимаю, к чему может привести, если ДРУГИХ механизмов нет. Я пытаюсь донести мысль, что работа с СУБД и работа с некоей системой, в данном случае OEBS, реализованной пусть на той же СУБД - суть разные вещи.

Я готов бы с Вами согласится, если бы работа с упомянутой системой происходила только на "среднем" уровне, т.е. не имелось бы в принципе возможности обхода ограничений, заложенных на этом уровне. Но на самом деле работа с системой подразумевает ПРЯМОЙ доступ разработчика к хранилищу (через написание пакетов, например, при кастомизации workflow) со всеми вытекающими отсюда последствиями в условиях отсутсвия ограничений.

OA UserПопробуйте это сделать средствами OEBS.

Эээ... Написание пакета в описанном мной выше случаи это разве не "средства OEBS". И что, "это средство OEBS" не даст мне наломать дров?


Еще раз попробую объяснить. Дело не в n-звенности системы, а в самом подходе. Система не подразумевает, а допускает прямой доступ к данным, этого никто и не отрицает. Вы можете писать любые пакеты, процедуры и т.д. , качество работы будет напрямую зависеть от того, насколько вы хорошо знаете структуры таблиц, их взаимосвязи и т.д. Это есть работа средствами СУБД. С другой стороны, можно использовать тот функционал, который предлагает сама система, и который, кстати, она сама в своих формах использует. Например, если в AR нужно загрузить платежи, можно ведь средствами СУБД заполнить соответствующие таблицы, а можно изучить матчасть, заполнить интерфейсные таблицы, вызвать определенный пакет и система сама выполнит необходимые действия. Это есть работа средствами OEBS, те самые "правила игры". И если разработчики системы полагают, что эти правила будут соблюдаться, то они полностью вправе отказаться от ряда ограничений по целостности системы. Я сам довольно давно занимался разработкой подобного API для системы еще на dbf-файлах, сами понимаете, там пользователя никак нельзя было ограничить, так вот, после перевода пользотельского кода на этот API количество проблем с пользовательским кодом снизилось на порядок, и не потому что я такой мегапрограммист был, а потому, что поведение системы стало прогнозируемым, вот и все.
Представьте, Вы отдаете свою систему на сторону, садится там очередной гений, ему неохота разбираться, что там OA User и pkarklin понаписали, он все, что надо, отключает и ваяет свое. Значит, он не будет соблюдать установленные Вами правила, и Вы гарантируете, что Ваша система будет работать?
Пример с LAST_UPDATED_BY совсем не надуманный, кстати, потому что документы бывают разного свойства, в том числе и весьма щекотливого, и я бы не назвал эти поля бесполезными.
Я - больше практик, и для меня надежность системы, грубо говоря, обратно пропорциональна количеству звонков на хелпдеск в единицу времени, и по моему опыту больше всего проблем создавали именно доработки, связанные с нарушением "правил игры", в том числе и триггеры, повешенные на транзакционные таблицы, дополнительные индексы, кривые блокировки и т.д. Проблем, вызванных отсутствием ФК, я не припомню. Посему и делаю вывод, что, как и наличие ФК не является панацеей от всех бед, так и отказ от них является не догмой, а разумным в данном случае компромиссом.
...
Рейтинг: 0 / 0
Внешние ключи в OEBS, SAP, Axapta и тд.
    #33592350
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OA UserЕще раз попробую объяснить. Дело не в n-звенности системы, а в самом подходе. Система не подразумевает, а допускает прямой доступ к данным, этого никто и не отрицает.

Ды и я об этом говорю, что система "допускает". Ни более, ни менее.

OA UserВы можете писать любые пакеты, процедуры и т.д. , качество работы будет напрямую зависеть от того, насколько вы хорошо знаете структуры таблиц, их взаимосвязи и т.д. Это есть работа средствами СУБД.

И с этим не спорю. Но опять напомню, про заведомые условности при поддержке целосности.

OA UserС другой стороны, можно использовать тот функционал, который предлагает сама система, и который, кстати, она сама в своих формах использует. Например, если в AR нужно загрузить платежи, можно ведь средствами СУБД заполнить соответствующие таблицы, а можно изучить матчасть, заполнить интерфейсные таблицы, вызвать определенный пакет и система сама выполнит необходимые действия. Это есть работа средствами OEBS, те самые "правила игры". И если разработчики системы полагают, что эти правила будут соблюдаться, то они полностью вправе отказаться от ряда ограничений по целостности системы.

Хм... Вы привели пример, где действительно достаточно "уметь пользоваться интерфейсными таблицами", и где возможность наступания на грабли сведена к минимум. Можно привести другой пример, где надо действительно напрямую работать с таблицами (представлениями системы) и уже где возможность наступить на грабли отсутствия DRI возрастает. Я не утверждаю, что это обязательно случится, но спорить с тем, что это может произойти, надеюсь, Вы не будете.

OA UserЯ сам довольно давно занимался разработкой подобного API для системы еще на dbf-файлах, сами понимаете, там пользователя никак нельзя было ограничить, так вот, после перевода пользотельского кода на этот API количество проблем с пользовательским кодом снизилось на порядок, и не потому что я такой мегапрограммист был, а потому, что поведение системы стало прогнозируемым, вот и все.

Не кажется ли Вам, что ограничения на уровне СУБД можно представить тем самым "API", который как раз сведет кол-во проблем с целостностью к минимому? Так зачем тогда он него отказываться?

OA UserПредставьте, Вы отдаете свою систему на сторону, садится там очередной гений, ему неохота разбираться, что там OA User и pkarklin понаписали, он все, что надо, отключает и ваяет свое. Значит, он не будет соблюдать установленные Вами правила, и Вы гарантируете, что Ваша система будет работать?

С дуру можно любой орган человеческого тела сломать. ;) Про 100% гарантию я уже говорил и повторятся не буду. Я просто опять стараюсь сделать упор на то, что и softwarer говорил. Если знаешь место, где можно упасть, то соломки стоит подстелить заранее.

OA UserЯ - больше практик, и для меня надежность системы, грубо говоря, обратно пропорциональна количеству звонков на хелпдеск в единицу времени, и по моему опыту больше всего проблем создавали именно доработки, связанные с нарушением "правил игры", в том числе и триггеры, повешенные на транзакционные таблицы, дополнительные индексы, кривые блокировки и т.д. Проблем, вызванных отсутствием ФК, я не припомню. Посему и делаю вывод, что, как и наличие ФК не является панацеей от всех бед, так и отказ от них является не догмой, а разумным в данном случае компромиссом.

Хм... Спасибо, что отнесли меня к "теоретикам". :) Хотя все выводы, которые я здесь пытаясь привести, из чисто практического опыта. Разумная достаточность должна присутствовать в любом случаи, но существуют моменты, где лично я не готов идти на компромис.


Резюмируя. По-моему, мы уже твердо определили точку зрения каждого из нас, и думаю, что каждый из нас в любом случаи останется при своей.
...
Рейтинг: 0 / 0
115 сообщений из 115, показаны все 5 страниц
Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / Внешние ключи в OEBS, SAP, Axapta и тд.
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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