За положением рейсовых автобусов в крупных городах уже можно наблюдать в режиме реального времени. Но это хлеще гонок маршруточников. Особенно, когда пассажир через новомодный сервис подглядывает за рейсовым автобусом и подгоняет водителя.
Далее: кажется, что в городах с большим количеством пробок возникают ситуации, когда часть маршрута удобнее проехать на общественном транспорте или даже пройти пешком, а затем снова пересесть в такси.
В недалеком будущем, водитель пассажиру: «Уважаемый, впереди пробка 1000м. Но наша замечательная автоматизированная система о Вас уже позаботилась, в конце пробки Вас ожидает другой автомобиль. Покиньте пожалуйста такси, перейдите к другому...»
Пока нам проще подождать, может кто-то сделает это.
Тут наверное стоит задать обоюдный вопрос к разработчикам PostgreSQL.
1. Существует ли реальная задача под которую создавался RLS, или статистика с практикой применения и администрирования?
2. Реализованный RLS действительно неудобен и не отвечает реальным потребностям в прикладных задачах, какие есть планы по доработке?
В процедуре постгрес можно любую ересь написать. А в непродуманном оракле при сохранении процедуры проверяется и наличие и правильность типов всех ссылаемых объектов.
1:1 ;-)
Именно так (генерация предикатов в рантайм) и сделано у нас в версии для оракла. И именно по указанным причинам пришлось отказаться от поддержки в версии для постгреса.
Если нужен предикат в рантайме для конкретного пользователя, могу посоветовать решение из собственного опыта. В постгресе есть CREATE TEMP VIEW… Перед INSERT, UPDATE, DELETE или SELECT генерите временное представление с добавленным предикатом и работайте с ним, при этом сама таблица может быть недоступна пользователю, а во временном представлении будут доступны только нужные записи.
3… В оракле полиси это функция, которая возвращает предикат, в пг это сам предикат.
Постгрес не позволяет вставить политику, если в предикате ошибка, к примеру указано несуществующее имя поля. В оракле RLS (на зуб) не пробовал, но так понимаю он проверку не делает, а ошибки, если есть, выдает уже после обращения к данным.
Такими мелочами постгрес выглядит на голову продуманней оракла. Этим же он уступает конкуренту в скорости развития функционала.
Вообще интересно посмотреть живой проект, в котором RLS руками пишется. Я RLS рассматриваю тока как сгенерированный из какой-нибудь вспомогательной таблички.
Осмелюсь добавить пример:
Этиловый спирт СН3-СН2-ОН и диметиловый эфир СН3-О-СН3 являются изомерами — одинаковые по составу и молекулярной массе, но разные по строению и расположению атомов.
Разве поможет низкоуровневая модель строения атомов понять различие в свойствах этих соединений?
Но я лишь хотел сказать, что те модели, которые сейчас используются, противоречивы и висят в воздухе
Философский камень ищешь! Мудрено это, путь свой искать… нет для этого наставника.
Цели (решаемой задачи) в статье нет, потому и с терминами неопределенка. Когда цель (реальная задача) появится, тогда, стиснув зубы, причина появится: «Зачем кукурузе расти».
Так я не на экзамене. К Вам не нанимаюсь. Свои риски на Вас не перекладываю.
Свои идеи публикую, чтоб испытать на сторонней проблеме, понять недостатки, найти решения.
Ваших проблем, мотивов не знаю — предложить ничего не могу.
«гипотезу чего» вы приводите; иными словами — какую задачу вы пытаетесь решить.
Я предполагаю, что деление на вышеперечисленные этапы и направления деятельности позволит классифицировать и однозначно определить взаимосвязи между процессами, объектами, субъектами, прочими сущностями предприятия.
в позиции enterprise architect это может выглядеть совершенно иначе.
Положение в пространстве Солнца и Земли однозначно определяется математической формулой (для замкнутой системы). Дело техники выразить закон движения Солнца вокруг Земли, и с противоположной точкой зрения — закон движения Земли вокруг Солнца. Какую точку зрения (закон) принимать — вопрос политический, к математике отношение не имеет.
Вы бы начали, что ли, с ответа на вопрос, что такое «архитектура предприятия».
Какой смысл формулировать определение того, чего пока нет. Существует лишь отрывочные знания о классификации бизнес процессов (описанные выше в двух измерениях) помогающие (пока не на 100%) увидеть связи и зависимости, определить зоны ответственности, разграничить права доступа.
Я лишь могу предположить, что Архитектурой предприятия является совокупность бизнес процессов, их связей и еще чего-то там…
Токарь не исполнитель — он ресурс для предприятия, как станок, материал, энергия. Иванов может быть исполнителем по трудовому договору (не аутстаффинг) с предприятием о предоставлении собственных ресурсов (мастерства, времени), но в производстве Иванов исчезает, остается проданный им ресурс (мастерство и свободное временя).
Исполнителем в производстве является Мастер — который смешивает ресурсы в определенной последовательности (по технологии) и материально отвечает за конечный результат.
17 точек зрения (направлений деятельности) — взято из Плана счетов бухгалтерского учета:
УПРАВЛЕНИЕ уставным капиталом;
УПРАВЛЕНИЕ денежными средствами;
УПРАВЛЕНИЕ прибылью и убытками;
РАСЧЕТЫ с контрагентами;
РАСЧЕТЫ с персоналом;
РАСЧЕТЫ с государством;
ЭКСПЛУАТАЦИЯ, ИСПОЛЬЗОВАНИЕ зданий, сооружений, оборудования;
ЭКСПЛУАТАЦИЯ, ИСПОЛЬЗОВАНИЕ лицензий, патентов;
ЭКСПЛУАТАЦИЯ, ИСПОЛЬЗОВАНИЕ материалов, комплектующих, полуфабрикатов, деталей;
ЭКСПЛУАТАЦИЯ, ИСПОЛЬЗОВАНИЕ услуг;
ЭКСПЛУАТАЦИЯ, ИСПОЛЬЗОВАНИЕ рабочей силы;
ПРОИЗВОДСТВО основное;
ПРОИЗВОДСТВО вспомогательное;
Общепроизводственная ДЕЯТЕЛЬНОСТЬ;
Общехозяйственная ДЕЯТЕЛЬНОСТЬ;
УПАКОВКА, ОТПРАВКА, ПЕРЕДАЧА продукции;
УПАКОВКА, ОТПРАВКА, ПЕРЕДАЧА услуг;
Декартово произведение 17 этапов и 17направлений деятельности позволяет описать 17х17= 289 бизнес процессов.
Предлагаю Вам самостоятельно описать архитектуру из 289 бизнес процессов и назвать ее своим именем ;-). У меня пока не получается, некоторые процессы не сходятся в деталях, видимо еще где-то 10% процессов не охватил.
Точит токарь, а Иванов — это аналитический объект другого процесса
Возможно не по Захману, мой собственный взгляд: What:
— Изделие (двигатель);
— Деталь (шайба);
— Рабочий (токарь);
— Физическое лицо (Иванов);
How — КАК я бы заменил на СВЯЗИ, В КАКОЙ ПРОПОРЦИИ:
— 10 Шайб на 1 Двигатель;
— 0.2 часа Токаря на 1 Шайбу;
— 500 руб. Иванов хочет за 1 Час работы токарем
Who — Я бы заменил на Материально-ответственное лицо:
— Мастер цеха сборки материально отвечает за незавершенное производство двигателей;
— Мастер токарного цеха материально отвечает за незавершенное производство шайб;
— Мастер токарного цеха материально отвечает за начисление зарплаты рабочим;
— Иванов, или его представитель является дебитором/кредитором предприятия;
When — делится на КОГДА КОНЕЦ и КОГДА НАЧАЛО:
— Мастер цеха сборки назначает даты КОГДА НАЧАЛО производства двигателей и КОГДА КОНЕЦ обеспечения Шайбами;
— Мастер токарного цеха назначает даты КОГДА НАЧАЛО производства шайб и КОГДА КОНЕЦ загрузки рабочих;
— Мастер токарного цеха назначает даты КОГДА НАЧАЛО работы рабочих и КОГДА КОНЕЦ начисления зарплаты рабочим;
— Иванов, или его представитель назначает даты КОГДА НАЧАЛО начисления зарплаты (его деятельности) и когда КОГДА КОНЕЦ выплаты зарплаты на его расчетный счет;
Why — рассмотрим в обратном прядке;
— Предприятие заплатило Иванову, Иванов материально обязан погасить задолженность
— Иванов выполнил поручение мастера токарного цеха, погасил дебиторскую задолженность. Теперь мастер затраты Токаря должен переложить на производство детали или погасить зарплату Токаря из собственного кармана;
— Мастера токарного цеха переложил затраты токаря в выпуск шайб и готовые шайбы должен отдать в Цех сборки или погасить затраты на выпуск шайб из собственного кармана
— Мастера токарного цеха передал шайбы в цех сборки и теперь Мастер цеха сборки материально ответственный за затраты списанные на производство двигателей.
Потому что он обязан (получил аванс) или обяжет предприятие выплатить ему вознаграждение. Именно обязательства-потребности (разница потенциалов) создают работу — хозяйственную деятельность. Хозяйственную деятельность оформляется в виде двойной записи — бухгалтерской проводки.
Автор молодец, наглядный пример оптимизации 1С!
Но 1С-совцам лучше дать универсальную процедуру на языке 1С, которая для любой пары таблиц будет генерировать запрос распределения — это буде им проще для применения, чем каждый раз вникать в строгость неравенств по OrderTop и OrderBottom.
Основная проблема электронных таблиц ONLYOFFICE — затирание значений в скрытых фильтром ячейках при протягивании. Давно задавал вопрос в тех.поддержку. Проблема в новой версии не решена!
За положением рейсовых автобусов в крупных городах уже можно наблюдать в режиме реального времени. Но это хлеще гонок маршруточников. Особенно, когда пассажир через новомодный сервис подглядывает за рейсовым автобусом и подгоняет водителя.
В недалеком будущем, водитель пассажиру: «Уважаемый, впереди пробка 1000м. Но наша замечательная автоматизированная система о Вас уже позаботилась, в конце пробки Вас ожидает другой автомобиль. Покиньте пожалуйста такси, перейдите к другому...»
Тут наверное стоит задать обоюдный вопрос к разработчикам PostgreSQL.
1. Существует ли реальная задача под которую создавался RLS, или статистика с практикой применения и администрирования?
2. Реализованный RLS действительно неудобен и не отвечает реальным потребностям в прикладных задачах, какие есть планы по доработке?
1:1 ;-)
Если нужен предикат в рантайме для конкретного пользователя, могу посоветовать решение из собственного опыта. В постгресе есть CREATE TEMP VIEW… Перед INSERT, UPDATE, DELETE или SELECT генерите временное представление с добавленным предикатом и работайте с ним, при этом сама таблица может быть недоступна пользователю, а во временном представлении будут доступны только нужные записи.
Постгрес не позволяет вставить политику, если в предикате ошибка, к примеру указано несуществующее имя поля. В оракле RLS (на зуб) не пробовал, но так понимаю он проверку не делает, а ошибки, если есть, выдает уже после обращения к данным.
Такими мелочами постгрес выглядит на голову продуманней оракла. Этим же он уступает конкуренту в скорости развития функционала.
Вообще интересно посмотреть живой проект, в котором RLS руками пишется. Я RLS рассматриваю тока как сгенерированный из какой-нибудь вспомогательной таблички.
Может намекнёте на измерения
Этиловый спирт СН3-СН2-ОН и диметиловый эфир СН3-О-СН3 являются изомерами — одинаковые по составу и молекулярной массе, но разные по строению и расположению атомов.
Разве поможет низкоуровневая модель строения атомов понять различие в свойствах этих соединений?
Философский камень ищешь! Мудрено это, путь свой искать… нет для этого наставника.
Цели (решаемой задачи) в статье нет, потому и с терминами неопределенка. Когда цель (реальная задача) появится, тогда, стиснув зубы, причина появится: «Зачем кукурузе расти».
Свои идеи публикую, чтоб испытать на сторонней проблеме, понять недостатки, найти решения.
Ваших проблем, мотивов не знаю — предложить ничего не могу.
Вижу идеи мои Вам не интересны, а вопросов много задаете, но ответы все не те. Наверное, есть проблема, решить не можете и рассказать боитесь?
Предлагаю прийти к взаимопониманию, а затем продолжить разговор.
Я предполагаю, что деление на вышеперечисленные этапы и направления деятельности позволит классифицировать и однозначно определить взаимосвязи между процессами, объектами, субъектами, прочими сущностями предприятия.
Положение в пространстве Солнца и Земли однозначно определяется математической формулой (для замкнутой системы). Дело техники выразить закон движения Солнца вокруг Земли, и с противоположной точкой зрения — закон движения Земли вокруг Солнца. Какую точку зрения (закон) принимать — вопрос политический, к математике отношение не имеет.
Какой смысл формулировать определение того, чего пока нет. Существует лишь отрывочные знания о классификации бизнес процессов (описанные выше в двух измерениях) помогающие (пока не на 100%) увидеть связи и зависимости, определить зоны ответственности, разграничить права доступа.
Я лишь могу предположить, что Архитектурой предприятия является совокупность бизнес процессов, их связей и еще чего-то там…
Токарь не исполнитель — он ресурс для предприятия, как станок, материал, энергия. Иванов может быть исполнителем по трудовому договору (не аутстаффинг) с предприятием о предоставлении собственных ресурсов (мастерства, времени), но в производстве Иванов исчезает, остается проданный им ресурс (мастерство и свободное временя).
Исполнителем в производстве является Мастер — который смешивает ресурсы в определенной последовательности (по технологии) и материально отвечает за конечный результат.
Чтобы понять всю сложность цепочки преобразований, приведу собственную гипотезу Архитектуры предприятия © SergeyGershkovich:
17 Ключевых вопросов — Моделей (этапов) деятельности предприятия:
17 точек зрения (направлений деятельности) — взято из Плана счетов бухгалтерского учета:
Декартово произведение 17 этапов и 17направлений деятельности позволяет описать 17х17= 289 бизнес процессов.
Предлагаю Вам самостоятельно описать архитектуру из 289 бизнес процессов и назвать ее своим именем ;-). У меня пока не получается, некоторые процессы не сходятся в деталях, видимо еще где-то 10% процессов не охватил.
Захман только коснулся подобной архитектуры…
Возможно не по Захману, мой собственный взгляд:
What:
— Изделие (двигатель);
— Деталь (шайба);
— Рабочий (токарь);
— Физическое лицо (Иванов);
How — КАК я бы заменил на СВЯЗИ, В КАКОЙ ПРОПОРЦИИ:
— 10 Шайб на 1 Двигатель;
— 0.2 часа Токаря на 1 Шайбу;
— 500 руб. Иванов хочет за 1 Час работы токарем
Where:
— Цех сборки;
— Токарный цех — рабочее место;
— Токарный цех — бригада;
— Отдел кадров;
Who — Я бы заменил на Материально-ответственное лицо:
— Мастер цеха сборки материально отвечает за незавершенное производство двигателей;
— Мастер токарного цеха материально отвечает за незавершенное производство шайб;
— Мастер токарного цеха материально отвечает за начисление зарплаты рабочим;
— Иванов, или его представитель является дебитором/кредитором предприятия;
When — делится на КОГДА КОНЕЦ и КОГДА НАЧАЛО:
— Мастер цеха сборки назначает даты КОГДА НАЧАЛО производства двигателей и КОГДА КОНЕЦ обеспечения Шайбами;
— Мастер токарного цеха назначает даты КОГДА НАЧАЛО производства шайб и КОГДА КОНЕЦ загрузки рабочих;
— Мастер токарного цеха назначает даты КОГДА НАЧАЛО работы рабочих и КОГДА КОНЕЦ начисления зарплаты рабочим;
— Иванов, или его представитель назначает даты КОГДА НАЧАЛО начисления зарплаты (его деятельности) и когда КОГДА КОНЕЦ выплаты зарплаты на его расчетный счет;
Why — рассмотрим в обратном прядке;
— Предприятие заплатило Иванову, Иванов материально обязан погасить задолженность
— Иванов выполнил поручение мастера токарного цеха, погасил дебиторскую задолженность. Теперь мастер затраты Токаря должен переложить на производство детали или погасить зарплату Токаря из собственного кармана;
— Мастера токарного цеха переложил затраты токаря в выпуск шайб и готовые шайбы должен отдать в Цех сборки или погасить затраты на выпуск шайб из собственного кармана
— Мастера токарного цеха передал шайбы в цех сборки и теперь Мастер цеха сборки материально ответственный за затраты списанные на производство двигателей.
Потому что он обязан (получил аванс) или обяжет предприятие выплатить ему вознаграждение. Именно обязательства-потребности (разница потенциалов) создают работу — хозяйственную деятельность. Хозяйственную деятельность оформляется в виде двойной записи — бухгалтерской проводки.
Но 1С-совцам лучше дать универсальную процедуру на языке 1С, которая для любой пары таблиц будет генерировать запрос распределения — это буде им проще для применения, чем каждый раз вникать в строгость неравенств по OrderTop и OrderBottom.