В архитектуре «бизнес-логика на сервере» у клиента не будет прав на select в таблице users, потому что все случаи ее использования (аутентификация, смена пароля, изменение имени, и т.п.) будет реализованы в виде хранимых процедур, и grant на select просто не будет предоставлен разработчиком.
Поэтому реализация бизнес-логики на сервере БД более безопасна.
«Ну вот создали новую функцию и забыли ограничить права»
Не ограничить, а назначить. Если забыли, прав на вызов ни у кого не будет. Поэтому забыть невозможно. Главное сознательно не давать права тем, кому они не положены
>затраты на план — величина меньшего порядка, чем собственно выполнение
Заблуждение. Построение плана сложного запроса требует анализа словаря БД, статистики (а это те же самые запросы к БД и анализ их результатов), выставления блокировки на добавление в список планов (что тормозит все остальные запросы, которые требуют хард-парсинга). Если такой запрос в итоге читает несколько блоков из кеша буферов, то задержки на парсинг будут в разы больше времени чтения.
А бюджет проекта (стоимость разработки и 1 года поддержки) можете прикинуть? Чтобы как-то сравнить ТСО?
По надежности и отказоусточивости ИМХО ничто не сравнится с двумя разнесенными стендбаями Oracle. Тем более такая технически сложная система как описана в посте. Потенциальных точек для сбоев очень много, специалистов по самописной системе интеграции Oracle/Tarantool на рынке нет. Выглядит все очень уязвимо.
Интересно, сколько выиграли в деньгах.
Что мешало просто поднять standby Oracle и использовать его как кэш? Или реплицировать в cache-Oracle избранные таблицы через GG. Структура таблиц ведь осталась та же? Зачем весь этот геморрой с перекачкой 2.5 Tb через csv-файлы? А «прогрев» — просто востановление из бекапа вообще без нагрузки на master-Oracle, да и не нужен он будет на практике почти никогда. И изменения в DDL автоматом бы реплицировались. Для Oracle 10 Тыс запросов в секунду это семечки, если речь идет о мелких запросах, типичных для OLTP.
Для от поставщика, когда пикнул паллету, получил SSCC код. А как система по SSCC понимает место на складе? Откуда артикульный состав паллета берется? Поставщик предоставляет в электронном виде?
Для мульти-SKU как же вы обходитесь без буферной зоны? Где происходит рассортировка на монопаллеты, прямо у ворот?
>И как вы вообще собираетесь определять ситуации изменения и что именно там изменилось (количество или склад)? Триггерами?
Именно. В триггере из :old берем старую строку реестра по ключам артикул/склад, вычитаем старое кол-во. Из :new берем новую строку и увеличиваем количество.
Но вообще такая операция, как изменение склада в «выполненном» документе (документе в финальном статусе, в терминах 1С можно сказать в проведенном) — недопустима. Так как на разных складах разные мат.ответственные лица. И это должно делаться в два этапа: откат документа из финального статуса делает мат отвестветвенный старого склада, а проставление нового склада и перевод в финальный статус — мат.ответственный нового склада. Таким образом с точки зрения СУБД все сводится у удалению старых проводок и созданию новых. Изменение проводок не требуется.
По поводу двойного учета и у типа договора не готов дискутировать, потому что не понимаю, какая предметная область и как реализовано. На первый взгляд, изменение типа договора вообще не должно влиять на реестр остатков, так как договор не является документом товародвижения, то есть основанием для проводок.
Вчера в 17:18 вы спросили: «Как именно это делать?»
Я привел рабочую схему. И да, я сделал материализацию, которая НА ПРАКТИКЕ решает проблемы с производительностью, которые вызывает ваша очень теориетически правильная вьюха остатков.
Не вижу никакой проблемы с обовлением таблицы проводок. Блокиурется запись реестра, выполняется добаление/изменение/удаление проводки, снимается блокировка с записи реестра.
Я об устройстве 1С уже довольно смутно помню. Но терминология устоявшаяся, понятная широким массам.
В таблице проводок каждая запись — это: артикул, количество-дельта изменения остатка, ссылка на документ-основание.
Суммирование всех записей в таблице проводок с group by по артикулу приводит к получению актуальных остатков. Но делать это никогда не приходится, так как эта информация хранится в реестре остатков — таблице, которая в общем по структуре напоминает матвью такого запроса.
Сам факт изменения остатков (в плюс или минус) фиксируется добавлением записи в таблицу проводок. Как и откуда это инициируется — более широкая тема. Ну допустим, в терминах 1С при «проведении документа-основания». Но ничто не мешает делать это индивидуально по каждой строке документа. В зависимости от правил системы можно запретить на таблице любые dml кроме insert: откат проводок только через сторнирование. А можно и разрешить удаление и редактирование. В любом случае, в триггере уровня записи на таблице проводок мы знаем без лишних запросов, какой update выполнить на реестр, чтобы поддержать там актуальные остатки.
Ну и естественно, в эти таблицы можно добавить внешний ключ на склады, типы остатков или другие разрезы, кому что необходимо в учете
Есть реестр остатков, он напрямую из бизнес-логики не меняется. Есть журнал проводок. Остатки меняются только через добавление записей в таблицу проводок, в проводке ссылка на документ-основание.
Изменение реестра остатков делается либо триггером на таблице проводок, либо в API функциях, которые выполняют запись в таблицу проводок
Если все меняют одну и ту же базу данных одновременно с разных копий, при этом база растет последовательно, звено за звеном, то как достигается всеобщая синхронизация? Почему не возникает в разных копиях у одного звена два разных продолжения? Как решается этот конфликт?
Если операция добавления нового звена такая затратная по вычислительным ресурсам, то почему проверка не требует этих ресурсов?
Речь идет о выводе списка товаров. Для списка имеются два основных параметра:
а) условие отбора или другими словами фильтр
б) порядок сортировки
Достаточно перечислить условия отбора и порядок сортировки по пунктам в виде текстового списка, например
а) Условия отбора
1. Не более 5
2. Совпадает группа
3. Есть наличие
4. Один из ценовой ценовой группы 0-20%… и т.д.
…
б) Порядок сортировки
1. Цена по возрастанию
Для такой простой задачи блоксхема не нужна, так как излишне громоздка. Сам автор нарисовав несколько квадратиков в итоге перешел к текстовому описанию. Блоксхемы приветствуются если есть сложный бизнес-процесс, чтобы описать этапы этого процесса, показать общую картину. Опускаться до изображения на блоксхеме каждого if'а, который должен написать программист, не следует.
Сам по себе формат ТЗ вообще мало что дает. Рисовать в visio можно и макаку научить. А вот предусматривать все граничные условия, типа «а если нет в наличии, а если слишком дорого, а если все в одну цену, а если нет ни одного» вот это из постановщиков редко кто делает. Обычно такие вопросы по ТЗ задает сам программист или они всплывают, когда показывают результат работы, а он не удовлетворяет.
Как добиться такого подхода от постановщика задачи, вот эта тема не раскрыта.
В сообщении https://geektimes.ru/company/lamptest/blog/271166/#comment_9029658 от 17 февраля я допустил ошибку. Думал что лампа накаливания, которую заменил на шарик космос, была 60 Ватт. Вчера проверил ее, оказалось что она 40 Ватт. Тогда понятно, почему с заменой на Старт "аналог" 75 ватт стало гораздо светлее.
Так что сомнений в достоверности тестов lamptest больше не имею!
Был неправ, вспылил :)
Неделю назад поменял лампу в туалете с накаливания 60 ватт на шарик Старт "аналог" 75 ватт. Вся семья заметила что стало заметно светлее. Напряжение в сети нормальное около 220V. Теперь этим тестам так безоглядно не верю.
Поэтому реализация бизнес-логики на сервере БД более безопасна.
Не ограничить, а назначить. Если забыли, прав на вызов ни у кого не будет. Поэтому забыть невозможно. Главное сознательно не давать права тем, кому они не положены
Заблуждение. Построение плана сложного запроса требует анализа словаря БД, статистики (а это те же самые запросы к БД и анализ их результатов), выставления блокировки на добавление в список планов (что тормозит все остальные запросы, которые требуют хард-парсинга). Если такой запрос в итоге читает несколько блоков из кеша буферов, то задержки на парсинг будут в разы больше времени чтения.
По надежности и отказоусточивости ИМХО ничто не сравнится с двумя разнесенными стендбаями Oracle. Тем более такая технически сложная система как описана в посте. Потенциальных точек для сбоев очень много, специалистов по самописной системе интеграции Oracle/Tarantool на рынке нет. Выглядит все очень уязвимо.
Интересно, сколько выиграли в деньгах.
Для мульти-SKU как же вы обходитесь без буферной зоны? Где происходит рассортировка на монопаллеты, прямо у ворот?
Именно. В триггере из :old берем старую строку реестра по ключам артикул/склад, вычитаем старое кол-во. Из :new берем новую строку и увеличиваем количество.
Но вообще такая операция, как изменение склада в «выполненном» документе (документе в финальном статусе, в терминах 1С можно сказать в проведенном) — недопустима. Так как на разных складах разные мат.ответственные лица. И это должно делаться в два этапа: откат документа из финального статуса делает мат отвестветвенный старого склада, а проставление нового склада и перевод в финальный статус — мат.ответственный нового склада. Таким образом с точки зрения СУБД все сводится у удалению старых проводок и созданию новых. Изменение проводок не требуется.
По поводу двойного учета и у типа договора не готов дискутировать, потому что не понимаю, какая предметная область и как реализовано. На первый взгляд, изменение типа договора вообще не должно влиять на реестр остатков, так как договор не является документом товародвижения, то есть основанием для проводок.
Я привел рабочую схему. И да, я сделал материализацию, которая НА ПРАКТИКЕ решает проблемы с производительностью, которые вызывает ваша очень теориетически правильная вьюха остатков.
Не вижу никакой проблемы с обовлением таблицы проводок. Блокиурется запись реестра, выполняется добаление/изменение/удаление проводки, снимается блокировка с записи реестра.
В таблице проводок каждая запись — это: артикул, количество-дельта изменения остатка, ссылка на документ-основание.
Суммирование всех записей в таблице проводок с group by по артикулу приводит к получению актуальных остатков. Но делать это никогда не приходится, так как эта информация хранится в реестре остатков — таблице, которая в общем по структуре напоминает матвью такого запроса.
Сам факт изменения остатков (в плюс или минус) фиксируется добавлением записи в таблицу проводок. Как и откуда это инициируется — более широкая тема. Ну допустим, в терминах 1С при «проведении документа-основания». Но ничто не мешает делать это индивидуально по каждой строке документа. В зависимости от правил системы можно запретить на таблице любые dml кроме insert: откат проводок только через сторнирование. А можно и разрешить удаление и редактирование. В любом случае, в триггере уровня записи на таблице проводок мы знаем без лишних запросов, какой update выполнить на реестр, чтобы поддержать там актуальные остатки.
Ну и естественно, в эти таблицы можно добавить внешний ключ на склады, типы остатков или другие разрезы, кому что необходимо в учете
Изменение реестра остатков делается либо триггером на таблице проводок, либо в API функциях, которые выполняют запись в таблицу проводок
А можно поподробнее раскрыть тему замены jira на bugzilla и многократного ускорения заведения тикетов? За счет чего?
Если операция добавления нового звена такая затратная по вычислительным ресурсам, то почему проверка не требует этих ресурсов?
а) условие отбора или другими словами фильтр
б) порядок сортировки
Достаточно перечислить условия отбора и порядок сортировки по пунктам в виде текстового списка, например
а) Условия отбора
1. Не более 5
2. Совпадает группа
3. Есть наличие
4. Один из ценовой ценовой группы 0-20%… и т.д.
…
б) Порядок сортировки
1. Цена по возрастанию
Для такой простой задачи блоксхема не нужна, так как излишне громоздка. Сам автор нарисовав несколько квадратиков в итоге перешел к текстовому описанию. Блоксхемы приветствуются если есть сложный бизнес-процесс, чтобы описать этапы этого процесса, показать общую картину. Опускаться до изображения на блоксхеме каждого if'а, который должен написать программист, не следует.
Сам по себе формат ТЗ вообще мало что дает. Рисовать в visio можно и макаку научить. А вот предусматривать все граничные условия, типа «а если нет в наличии, а если слишком дорого, а если все в одну цену, а если нет ни одного» вот это из постановщиков редко кто делает. Обычно такие вопросы по ТЗ задает сам программист или они всплывают, когда показывают результат работы, а он не удовлетворяет.
Как добиться такого подхода от постановщика задачи, вот эта тема не раскрыта.
Так что сомнений в достоверности тестов lamptest больше не имею!
Был неправ, вспылил :)