Согласен, что такая структура наглядна + эффективна при запросах на селект.
Однако, вставка\изменение\удаление крайне неэффективна.
При большом размере таблицы вставка записи в начало иерархии займёт огромное время + если СУБД блокировочная, то это будет эксклюзивная блокировка всей таблицы = полная недоступность её для читателей данных на всё это время.
Т.е. для условно-постоянной информации такое решение, возможно, подойдет но не более того.
Мой вопрос был не от того, что я хочу пресэйл
Хотелось бы более точного позиционирования JDA относительно других распространённых систем, где есть прогнозирование.
Думаю, другим хабровчанам тоже было бы это интересно, поэтому утаскивать это в личку не хотелось бы.
Во всех ERP есть расчёт Плана Закупок, что вы учитываете такого, что уникально?
Что такое системы класса ERP при этом, думаю, все знают, а вот JDA — это что-то новенькое.
Хотелось бы понять, для начала, какого оно размера.
Сопоставимо ли по деньгам внедрение JDA, скажем, с внедрением модуля Управления Запасами от ERP -системы?
ребят, никакая статитстика никогда не бывает полной — у оптимизатора нет полной информации о том сколько записей вернёт каждый подзапрос в плане, особенно если критерии отбора достаточно сложные. Из-за этого оптимизатор выбирает неправильный порядок соединений.
Можно написать оптимизатор на 100 млн строк кода, но с этим ничего не сделаешь — до выполнения запроса данных у оптимизатора нет. А разработчик обычно это знает.
Не спорю что в 99% случаев оптимизатор разберётся и без советов разработчика. Но ручками лазить всё равно приходится. Нужны ли обязательно хинты, когда лезешь ручками — обсуждаемо. А так тезис автора напомнил SAP facts: «SAP StreamWork has a fully automated mode that does the business decisions for you»
Для начала хотел бы поять главное -для каких задач хороша Терадата по сравнению скажем с MS SQL и для каких плоха? И не говорите, что для всех хороша.
ERP?
Система построения отчётов?
Фэйсбукоподобный интернет проект?
А то вы как-то сразу от дирижёров к хэшам и оптимизаторам.
Навскидку (на самом деле ничего не знаю про Терадату) есть подозрение, что это очередная СУБД из 70х с 1% рынка и лицензиями по 100К, хочет получить 1.01% рынка, при помощи обсуждения гик-порно в социальных сетях.
А какой порядок цифр при внедрении решения JDA по прогнозированию?
От чего зависит стоимость внедрения?
Скажем для примера, наша компания продаёт 10 000 номенклатур, около 30 поставок в день, около 1000 отгрузок.
ERP система есть — там тоже есть прогнозирование — но вдруг у вас точнее?
Если процесс получил блокировку на ресурс, как-то воспользовался этим ресурсом, то потом лишив его этой блокировки, даже под самыми благими намерениями, мы всю изоляцию транзакций нахрен порушим
Если подумать об варианте, чтобы сервак сам предпринимал, кроме отката повторную попытку выполнения транзакции, но здесь тоже ерунда может получиться- внутри транзакции могут быть ресурсы, которые не по ACID-принципу управляются — переменные, обращения к внешним ресурсам (типа файлов) итп- тоже полный ад получится.
ну рекомендация — абсолютно точная и настолько же бесполезная, как в анекдоте — «где мы? на воздушном шаре, сэр», с таким же успехом можно было порекомендовать не писать код приводящий к дедлокам.
один из комментаторов выше точно подметил, что размер транзакции определяется обычно бизнес-логикой.
На этапе борьбы с дедлоками изменение размера транзакции, как правило, не является доступной опцией
другими словами, если у меня, по бизнес-требованиям, есть возможность сделать транзакцию на только из 9 выражений, я никогда не буду делать транзакцию на 10 выражений
Мне вообще кажется, что и проще и лучше не дизаблить элементы, а разрешать их использование, но давать при этом внятную диагностику почему ими нельзя пользоваться.
Пользователь потыкавшись немного поймёт всё, что ему можно, а что нельзя.
Вот, например, хорошая
дискуссия на серверфолт на эту тему.
UPD: извиняюсь — в статье есть объяснение почему не подошли.
Однако, вставка\изменение\удаление крайне неэффективна.
При большом размере таблицы вставка записи в начало иерархии займёт огромное время + если СУБД блокировочная, то это будет эксклюзивная блокировка всей таблицы = полная недоступность её для читателей данных на всё это время.
Т.е. для условно-постоянной информации такое решение, возможно, подойдет но не более того.
Хотелось бы более точного позиционирования JDA относительно других распространённых систем, где есть прогнозирование.
Думаю, другим хабровчанам тоже было бы это интересно, поэтому утаскивать это в личку не хотелось бы.
Во всех ERP есть расчёт Плана Закупок, что вы учитываете такого, что уникально?
Что такое системы класса ERP при этом, думаю, все знают, а вот JDA — это что-то новенькое.
Хотелось бы понять, для начала, какого оно размера.
Сопоставимо ли по деньгам внедрение JDA, скажем, с внедрением модуля Управления Запасами от ERP -системы?
Можно написать оптимизатор на 100 млн строк кода, но с этим ничего не сделаешь — до выполнения запроса данных у оптимизатора нет. А разработчик обычно это знает.
Не спорю что в 99% случаев оптимизатор разберётся и без советов разработчика. Но ручками лазить всё равно приходится. Нужны ли обязательно хинты, когда лезешь ручками — обсуждаемо. А так тезис автора напомнил SAP facts: «SAP StreamWork has a fully automated mode that does the business decisions for you»
ERP?
Система построения отчётов?
Фэйсбукоподобный интернет проект?
А то вы как-то сразу от дирижёров к хэшам и оптимизаторам.
Навскидку (на самом деле ничего не знаю про Терадату) есть подозрение, что это очередная СУБД из 70х с 1% рынка и лицензиями по 100К, хочет получить 1.01% рынка, при помощи обсуждения гик-порно в социальных сетях.
От чего зависит стоимость внедрения?
Скажем для примера, наша компания продаёт 10 000 номенклатур, около 30 поставок в день, около 1000 отгрузок.
ERP система есть — там тоже есть прогнозирование — но вдруг у вас точнее?
практически игра,
освоил месяца за 3 ненапряжных занятий и русский и анлийский
«Соло» пробовал, но по сравнению с babytype'ом оно чудовищно нудное — так и не смог себя заставить
повторил на MS SQL -думал он поумнее- тоже дедлок получил
чего то мы не учитываем в наших рассуждениях
Если процесс получил блокировку на ресурс, как-то воспользовался этим ресурсом, то потом лишив его этой блокировки, даже под самыми благими намерениями, мы всю изоляцию транзакций нахрен порушим
Если подумать об варианте, чтобы сервак сам предпринимал, кроме отката повторную попытку выполнения транзакции, но здесь тоже ерунда может получиться- внутри транзакции могут быть ресурсы, которые не по ACID-принципу управляются — переменные, обращения к внешним ресурсам (типа файлов) итп- тоже полный ад получится.
один из комментаторов выше точно подметил, что размер транзакции определяется обычно бизнес-логикой.
На этапе борьбы с дедлоками изменение размера транзакции, как правило, не является доступной опцией
другими словами, если у меня, по бизнес-требованиям, есть возможность сделать транзакцию на только из 9 выражений, я никогда не буду делать транзакцию на 10 выражений
особенно про порядок захвата ресурсов
а автор тему не раскрыл совсем, особенно умиляют советы про «коммитится почаще»
Пользователь потыкавшись немного поймёт всё, что ему можно, а что нельзя.
пользователь может задуматься, что ему надо сделать чтобы ею воспользоваться
автор судя по всему не в курсе как делается ПО
или с Оракла на MS SQL?
С интересом слежу за вакансиями на МТС.ру :)