под встраивание я имею в виду использование одного кода в разных конструкциях
Не понял. Разных — это каких? Предикат, проекция, CASE, другая процедура — это разные конструкции? Или вы имеете в виду разные конструкции в форме разграничения statement/expression? Если же вы под встраиванием пытаетесь выразить inline-включение тела функции в тело главного запроса, то этого вы никаким наследованием не добьётесь. Рискну предположить, что это вообще силами SQL невозможно для общего случая, потому что предполагает слишком сильное переписывание и запроса, и самой функции. Ну не сможет никто, кроме вас, чисто преобразовать
function get_customer_name(id number) as begin
return select customer_name from customer
where customer_id = id;
end;
select
purchase_date,
get_customer_name(customer_id) customer_name
from purchases
В
select
purchase_date,
customer_name
from purchases
left join customer using(customer_id)
хранимки не подойдут
Мне кажется, вы не совсем верно понимаете чем ограничены оптимизации функций. Это зависит вовсе не от принадлежности "хранимке", а от детерминированности самой функции (в терминах ФП — от чистоты). Но при этом сам вызов особо не оптимизировать. Если детерминирована — то вызов можно мемоизировать, только и всего.
Весь Java Language Spec — это именно спецификация языка, там именно правила взаимодействия исходного кода и JVM, так что на все 600 страниц под библиотеку отведён только абсолютный минимум. Не читал HLR (только открыл пару случайных глав вот прямо пока писал), но могу предположить две вещи (обе из которых могут быть неверны):
JLS до таких объёмов разросся когда стали всплывать и разрешаться различные конфликты между текстами и тем, как их понимают разные JVM. Хаскель со временем тоже к этому придёт, если/когда на нём будет столько же писанины и способов запуска.
Хаскель обладает меньшим количеством возможных синтаксических конструкций, и/или при этом в среднем выше уровень потенциальных читателей, то есть эти конструкции можно ещё оптимизировать, если отправить пользователя RTFM какой-нибудь матан.
Опять же, посмотрите (хоть по оглавлению, как я сделал) сколько в JLS уделено описанию синтаксиса UserTypes, и сколько — HLR. Одно описание того, что и как может скрывать, оверрайдить или оверлоадить что-то ещё в Java нужно курить сравнительно долго (хотя интуитивный подход всё равно работает чаще, чем не работает).
Под встраиванием кусков кода вы имеете в виду хранение функций в виде данных, и в каждой строке таблицы иметь возможность хранить свою функцию?
Какую задачу вы бы хотели так решить?
Правда в определенном виде он есть в PostgreSQL
В Postgres больше смахивает на синтаксический сахар над теми же внешними ключами. По-прежнему не могу понять, чем эти протекающие на раз-два абстракции лучше простого и честного разделения на таблицы с честными же связями.
Вообще, всё сходится. На Android нативный интерфейс делается на Android Platform, а не C+++OpenGL. Точно так же, как же нативный интерфейс на Windows должен быть сделан через WinAPI (или UWP?), а не на Javascript'е.
У меня сложилось впечатление, что и "лечение" оболезболивающими в Америке тоже широко распространено — потому что именно лечение часто стоит очень дорого или не покрыто страховкой.
Разумеется, не везде, и не для всех, и вообще по стране многие болячки уже на правах статистической погрешности — зато вот те болезни, что остались…
Вероятно, корни и ТПО, и такого лечения именно в таких трудноустранимых "багах". С одной стороны — в устройстве мяса, с другой — в устройстве общества.
Это я в контексте монопольности платформы.
Мне самому пока ни лично, ни профессионально не приходилось сталкиваться с необходимостью писать под Андроид на C++ в принципе. Для меня очень логично считать, что раз ядро приложения на C++ — то логичным было бы и интерфейс тоже написать на C++ (ведь не от хорошей же жизни там пишут на NDK, значит экономить приходится на многом, и доставка сообщений через JNI тоже не бесплатная), но вот тут-то и происходит столкновение с реальностью.
В андроиде место react/vue занимает Android Platform. Это, практически говоря, все пакеты, начинающиеся с android. или androidx.. Очень монопольная штука. Насколько в своё время удалось найти — даже если основная логика приложения на C++, будет куда проще пользоваться JNI и писать интерфейс на Java, чем пилить прилично выглядящий интерфейс на C++.
with raw_data (id, type, quantity) as (
select
shipment_id, 'Shipment', shipped_quantity
from shipment
union all
select
receipt_id, 'Receipt', received_quantity
from receipt
)
select * from raw_data
В данном случае подзапрос определяет подтип строки таблицы, выглядящий примерно как
type raw_data_type is (
id number, type varchar, quantity number
)
И обе части UNION'a приводятся к этому типу, в итоге основное тело запроса работает с супертипом, а не с каждым подтипом отдельно. Вот это — вполне полиморфизм, с точки зрения хранилища фактов, коим SQL является, но вы же вроде бы чего-то другого добиваетесь, не так ли? Вот и объяснили бы, чего. Эти вот притянутые примеры, которыми вы продолжаете кидаться, картину не проясняют, в них слишком мало анализа с вашей стороны недостатков вашего подхода и преимуществ других подходов. Например, в чём конкретно преимущество подхода, когда вы храните все розы отдельно от остальных цветов, так что вам приходится объединять подклассы вручную через представления?
… во все необходимые абстрактные представления добавил реализации (подзапросы) для этого класса
Так а где тут полиморфизм-то? Так вы в этих представлениях по сути наплодите в итоге кучу тех самых if-ов (подзапросов, если точнее, но не суть), о которых так нелестно отзываетесь в соседней ветке комментариев. И после каждого нового класса будете плодить ещё больше "if-ов".
Тогда как при решении композицией у вас для вашей розы будет самодостаточная запись каталога цветов и рядом вспомогательная таблица атрибутов именно роз, и никаких абстрактных представлений переписывать будет не нужно. Хотите цветы — читаете из цветов. Хотите розы — читаете из роз, объединяете с цветами (и вот для этого-то какое-нибудь представление прямо идеально подходит).
Я так-то вообще всего лишь пытаюсь выяснить, для чего вам в SQL (или PL/SQL?) понадобился полиморфизм, и полиморфизм чего именно вы вообще имеете в виду.
А вместо этого вижу то столицы, то розы, то код из семидесятых.
И всё же, так и нет ответа на исходный вопрос: какие задачи вы хотите решить полиморфизмом в RDBMS? Какие части реляционной модели полиморфизм улучшит?
А вот Capital это City. А Роза — цветок.
А в чём функциональное различие capital и city, кроме единственного флага, который, к тому же, меняет своё значение во времени? Какие свойства есть у столицы? Почему, вы считаете, недостаточно сделать type Capital {CityId, ...},
или даже вообще по-рабоче-крестьянски type City { bool IsCapital, ... },
а вот обязательно надо иметь type Capital extends City?
Что улучшится при втором подходе? Как при наследовании быть если столицу перенесли? Будем удалять город? Или всё-таки только статус предадим от одного города другому?
То же самое с розами. При моделировании растений вообще намного проще иметь Traits, потому что на практически любое свойство роз, кроме ботанического определения (которое есть натуральный ключ), найдётся вид-другой роз, у которых это свойство отсутствует.
вы считаете что наследование не нужно и всегда можно обойтись композицией
С точки зрения (под)системы хранения данных — да, определённо. В общем для ООП — зависит от доменной модели.
А какой ещё, простите, функционал вы хотели бы добавить к объекту "Запись Таблицы SKU"? Других-то объектов в большинстве RDBMS нет, потому что именно тип "Запись Таблицы<T>" лучше всего решает основную задачу базы данных — хранения данных/фактов о <T>.
Полиморфизм самих данных в духе
class Location {}
class Airport extends Location {}
решается нормализацией данных — имеем отдельно таблицы Location и Airport, и в Airport также имеем foreign key к Location. Просто, оптимизируемо, и — внимание! — логически верно, так как
Или вы бы хотели хранить как значение произвольные объекты? Ну так и этого у DBMS тоже есть, и даже с полиморфизмом объектов (и иногда с неявным приведением типов, как в Oracle).
UPD: Пригляделся к вашей картинке. Судя по названиям, неправильно вы домен готовите. Если заменить наследование композицией, иерархия будет заметно проще. Всем этим документам всего-лишь нужно обладать некой общей частью, а выглядит будто вы заставляете их ещё и вести себя одинаково только по факту наличия этой общей части, но не по факту действительного наличия общего поведения. Сужу исключительно по наличию нескольких типов с одинаковым названием.
А вообще возьмите крупный проект на C++ или Java и посчитайте там количество extends /: и abstract / virtual.
Зачем полиморфизм в Java мы и так знаем. А вот в SQL он зачем? Какую задачу в SQL вы хотите решить при помощи полиморфизма, которая без полиморфизма решается плохо или не решается, например, нормализацией?
рано или поздно, замотивированный "эффективным менеджером" разработчик (я — рано), начнёт делать явные приведения в статике
Это будет ваш технический долг, только и всего. Далее остаётся только надеяться, что ваш менеджмент недостаточно эффективен, чтобы оптимизировать до нуля выплаты технического долга. Но даже если и оптимизирует, это сам принцип неверным не делает, это просто значит что менеджмент недостаточно хорошо разбирается в области и не знает, чем оборачивается большие долги в проектах.
Обычно всё же не администратора, а только с доступом к данным, без прав изменения схемы
Так неважно, что нет прав изменения схемы, ведь там разрешения — это такие же данные, а не часть схемы. Следовательно, при взломе любому пользователю возможно "нарисовать" расширенные права доступа.
Угу, завести в базе 100500 пользователей и апп-сервер будет держать соединение для каждого.
А это разве хуже чем если каждый пользователь фактически с базой общается под аккаунтом администратора, где по факту имеет все разрешения на чтение и запись (и хорошо если и не на все ddl-операции тоже, до кучи), и только ваша прослойка с ещё одним сервером контроля разрешений сохраняет ваши данные от компрометации. То есть, доступ ко всем всем вашим данным можно получить если узнать, под каким аккаунтом ваш аппсервер общался с базой, а такой аккаунт у всех один.
100500 пользователей, 100500 вьюшек для каждой таблицы
Ну если у вас требования такие, что ж поделать. Не руками ведь вам их писать, вы генератор сделали. Если хотите ограничить число сущностей — улучшите генератор, чтоб вьюшки были параметризованы, например, пользователем, и/или отслеживайте (случайные) совпадения по условиям, ведь запросы у такого числа людей редко уникальны. А раз условия не уникальны, можно оптимизировать и выдать двум пользователям одну и ту же вьюшку(но параметризовать пользователем всё равно, во имя справедливости). И тогда их будет может быть уже 50250, а может и того меньше.
Кстати, а как вы предложите решать эту задачу без вьюшек? Ну, в смысле, у вас вместо 100500 вьюшек будет 402000 уникальных, сгенерированных вашим data-store в рантайме, запросов? Или есть какие-то мне неизвестные средства, о которых я просто не подумал?
Если роли неопределённые, тогда у вас нет ролей. Но, в принципе, разрешения в СУБД можно выдавать и отдельным пользователям, насколько я помню, только это более муторно.
А если пользователь настраивает разрешения сам, то мы находимся в else моего предыдущего сообщения, и определение разрешений средствами СУБД уже не очень хорошо работает само по себе. Зато у нас есть одно из двух решений:
Разрешения тоже являются данными, и их некоторые серверы разрешений и вне SQL плохо понимают, нужен будет такой, который поймёт. При этом в самой базе скорее всего придётся-таки устроить free-for-all, где все читают всё, и надеяться что БД не скомпрометируют.
Мы можем пользователям сделать красивый интерфейс для работы с нативными разрешениями СУБД, но опять же ценой вывешивания этого интерфейса фактически в открытый доступ, под какой-нибудь ролью суперадминистратора. И иметь ассоциации ролей с какими-нибудь данными, чтобы не было возможности менять чужие разрешения, а только свои.
При этом ни для одного из вами озвученных вариантов требований нет простого пути позволить пользователям решать "может ли пользователь редактировать объект, созданный другим пользователем, или может ли простой менеджер отредактировать документ уже подписанный начальником отдела". Если вьюшки мы считаем моветоном, тогда единственный более-менее реалистичный механизм работы здесь — это императивные проверки в клиенте, где пользователю будет дан чекбокс, оные проверки выключающий, и на этом его конфигурение будет закончено. Проверки, вероятно, нужно будет выразить как некий DSL, чтобы его понимал и фронт, и сервер, либо дублировать несколько раз. На UI это нужно для отзывчивости, и на сервере для надёжности, потому что полное доверие UI в итоге обходится дорого.
Кстати, а чем плох генератор вьюшек? Ну, кроме того, что его, гипотетически, надо писать?
Кстати, не согласитесь ли вы ли вы, что ORM и есть такой генератор вьюшек, только рантайме (в общем случае)? А если "вьюшки" из релиза в релиз не меняются, зачем их генерировать каждый раз, не проще ли будет поместить их сразу в СУБД?
Можно ведь сделать Updatable View, а доступа к самой таблице не давать в принципе. Если совсем строго, можно Updatable View делать на базе Readable View, и к ним иметь разные разрешения на чтение и запись, потому что если умеет обновлять, то должен уметь и читать, а обратное уже неверно.
Не работает такое разве что в платформах, где несколько клиентов на одной базе, и у каждого свои понятия, кому и сколько можно. Ну и представлений писать придётся немало, конечно, под каждую категорию ролей.
А если никому эти проценты особо не важны, чего бы не сэкономить деньги?
Да, вот там прирост по времени 25% потому что не особо важно, и вон там тоже не особо важно было, потому там тоже +30%. А потом сидишь как дурак на компьютере за очень много денег и ждёшь когда очередная программа через дебри экономности продерётся и наконец-то среагирует на клик.
Я к чему. Сами по себе 3 секунды может и не много. Но вы правда верите, что только в единственном месте будет такой прирост? Или что он в будущем не станет ещё больше? Или что, как я выше писал, не сложится с аналогичным приростом ещё откуда-нибудь после рефакторинга?
Так вроде и для СУБД разрешения можно контролировать внутренними механизмами, без всяких процедур.
GRANT <permission> [ ,...n ] ON
[ OBJECT :: ][ schema_name ]. object_name [ ( column [ ,...n ] ) ]
TO <database_principal> [ ,...n ]
[ WITH GRANT OPTION ]
[ AS <database_principal> ]
Вот это вот всё. А то делают GRANT ALL, а потом начинают извращаться с движками проверки ролей в тридевятом царстве, а сами данные тем временем висят голым задом по system@system, и утекают при первой же возможности.
Не понял. Разных — это каких? Предикат, проекция,
CASE, другая процедура — это разные конструкции? Или вы имеете в виду разные конструкции в форме разграничения statement/expression? Если же вы под встраиванием пытаетесь выразить inline-включение тела функции в тело главного запроса, то этого вы никаким наследованием не добьётесь. Рискну предположить, что это вообще силами SQL невозможно для общего случая, потому что предполагает слишком сильное переписывание и запроса, и самой функции. Ну не сможет никто, кроме вас, чисто преобразоватьВ
Мне кажется, вы не совсем верно понимаете чем ограничены оптимизации функций. Это зависит вовсе не от принадлежности "хранимке", а от детерминированности самой функции (в терминах ФП — от чистоты). Но при этом сам вызов особо не оптимизировать. Если детерминирована — то вызов можно мемоизировать, только и всего.
Весь Java Language Spec — это именно спецификация языка, там именно правила взаимодействия исходного кода и JVM, так что на все 600 страниц под библиотеку отведён только абсолютный минимум. Не читал HLR (только открыл пару случайных глав вот прямо пока писал), но могу предположить две вещи (обе из которых могут быть неверны):
Опять же, посмотрите (хоть по оглавлению, как я сделал) сколько в JLS уделено описанию синтаксиса UserTypes, и сколько — HLR. Одно описание того, что и как может скрывать, оверрайдить или оверлоадить что-то ещё в Java нужно курить сравнительно долго (хотя интуитивный подход всё равно работает чаще, чем не работает).
Под встраиванием кусков кода вы имеете в виду хранение функций в виде данных, и в каждой строке таблицы иметь возможность хранить свою функцию?
Какую задачу вы бы хотели так решить?
В Postgres больше смахивает на синтаксический сахар над теми же внешними ключами. По-прежнему не могу понять, чем эти протекающие на раз-два абстракции лучше простого и честного разделения на таблицы с честными же связями.
Вообще, всё сходится. На Android нативный интерфейс делается на Android Platform, а не C+++OpenGL. Точно так же, как же нативный интерфейс на Windows должен быть сделан через WinAPI (или UWP?), а не на Javascript'е.
У меня сложилось впечатление, что и "лечение" оболезболивающими в Америке тоже широко распространено — потому что именно лечение часто стоит очень дорого или не покрыто страховкой.
Разумеется, не везде, и не для всех, и вообще по стране многие болячки уже на правах статистической погрешности — зато вот те болезни, что остались…
Вероятно, корни и ТПО, и такого лечения именно в таких трудноустранимых "багах". С одной стороны — в устройстве мяса, с другой — в устройстве общества.
Это я в контексте монопольности платформы.
Мне самому пока ни лично, ни профессионально не приходилось сталкиваться с необходимостью писать под Андроид на C++ в принципе. Для меня очень логично считать, что раз ядро приложения на C++ — то логичным было бы и интерфейс тоже написать на C++ (ведь не от хорошей же жизни там пишут на NDK, значит экономить приходится на многом, и доставка сообщений через JNI тоже не бесплатная), но вот тут-то и происходит столкновение с реальностью.
Особенно концерты Филиппа Киркорова. Или Элтона Джона, как прародителя моды.
В андроиде место react/vue занимает Android Platform. Это, практически говоря, все пакеты, начинающиеся с
android.илиandroidx.. Очень монопольная штука. Насколько в своё время удалось найти — даже если основная логика приложения на C++, будет куда проще пользоваться JNI и писать интерфейс на Java, чем пилить прилично выглядящий интерфейс на C++.Ну смотрите:
В данном случае подзапрос определяет подтип строки таблицы, выглядящий примерно как
И обе части UNION'a приводятся к этому типу, в итоге основное тело запроса работает с супертипом, а не с каждым подтипом отдельно. Вот это — вполне полиморфизм, с точки зрения хранилища фактов, коим SQL является, но вы же вроде бы чего-то другого добиваетесь, не так ли? Вот и объяснили бы, чего. Эти вот притянутые примеры, которыми вы продолжаете кидаться, картину не проясняют, в них слишком мало анализа с вашей стороны недостатков вашего подхода и преимуществ других подходов. Например, в чём конкретно преимущество подхода, когда вы храните все розы отдельно от остальных цветов, так что вам приходится объединять подклассы вручную через представления?
Так а где тут полиморфизм-то? Так вы в этих представлениях по сути наплодите в итоге кучу тех самых if-ов (подзапросов, если точнее, но не суть), о которых так нелестно отзываетесь в соседней ветке комментариев. И после каждого нового класса будете плодить ещё больше "if-ов".
Тогда как при решении композицией у вас для вашей розы будет самодостаточная запись каталога цветов и рядом вспомогательная таблица атрибутов именно роз, и никаких абстрактных представлений переписывать будет не нужно. Хотите цветы — читаете из цветов. Хотите розы — читаете из роз, объединяете с цветами (и вот для этого-то какое-нибудь представление прямо идеально подходит).
Я так-то вообще всего лишь пытаюсь выяснить, для чего вам в SQL (или PL/SQL?) понадобился полиморфизм, и полиморфизм чего именно вы вообще имеете в виду.
А вместо этого вижу то столицы, то розы, то код из семидесятых.
И всё же, так и нет ответа на исходный вопрос: какие задачи вы хотите решить полиморфизмом в RDBMS? Какие части реляционной модели полиморфизм улучшит?
А в чём функциональное различие capital и city, кроме единственного флага, который, к тому же, меняет своё значение во времени? Какие свойства есть у столицы? Почему, вы считаете, недостаточно сделать
type Capital {CityId, ...},или даже вообще по-рабоче-крестьянски
type City { bool IsCapital, ... },а вот обязательно надо иметь
type Capital extends City?Что улучшится при втором подходе? Как при наследовании быть если столицу перенесли? Будем удалять город? Или всё-таки только статус предадим от одного города другому?
То же самое с розами. При моделировании растений вообще намного проще иметь Traits, потому что на практически любое свойство роз, кроме ботанического определения (которое есть натуральный ключ), найдётся вид-другой роз, у которых это свойство отсутствует.
С точки зрения (под)системы хранения данных — да, определённо. В общем для ООП — зависит от доменной модели.
А какой ещё, простите, функционал вы хотели бы добавить к объекту "Запись Таблицы SKU"? Других-то объектов в большинстве RDBMS нет, потому что именно тип "Запись Таблицы<T>" лучше всего решает основную задачу базы данных — хранения данных/фактов о <T>.
Полиморфизм самих данных в духе
решается нормализацией данных — имеем отдельно таблицы Location и Airport, и в Airport также имеем foreign key к Location. Просто, оптимизируемо, и — внимание! — логически верно, так как
Или вы бы хотели хранить как значение произвольные объекты? Ну так и этого у DBMS тоже есть, и даже с полиморфизмом объектов (и иногда с неявным приведением типов, как в Oracle).
UPD: Пригляделся к вашей картинке. Судя по названиям, неправильно вы домен готовите. Если заменить наследование композицией, иерархия будет заметно проще. Всем этим документам всего-лишь нужно обладать некой общей частью, а выглядит будто вы заставляете их ещё и вести себя одинаково только по факту наличия этой общей части, но не по факту действительного наличия общего поведения. Сужу исключительно по наличию нескольких типов с одинаковым названием.
Зачем полиморфизм в Java мы и так знаем. А вот в SQL он зачем? Какую задачу в SQL вы хотите решить при помощи полиморфизма, которая без полиморфизма решается плохо или не решается, например, нормализацией?
Это будет ваш технический долг, только и всего. Далее остаётся только надеяться, что ваш менеджмент недостаточно эффективен, чтобы оптимизировать до нуля выплаты технического долга. Но даже если и оптимизирует, это сам принцип неверным не делает, это просто значит что менеджмент недостаточно хорошо разбирается в области и не знает, чем оборачивается большие долги в проектах.
Так неважно, что нет прав изменения схемы, ведь там разрешения — это такие же данные, а не часть схемы. Следовательно, при взломе любому пользователю возможно "нарисовать" расширенные права доступа.
А это разве хуже чем если каждый пользователь фактически с базой общается под аккаунтом администратора, где по факту имеет все разрешения на чтение и запись (и хорошо если и не на все ddl-операции тоже, до кучи), и только ваша прослойка с ещё одним сервером контроля разрешений сохраняет ваши данные от компрометации. То есть, доступ ко всем всем вашим данным можно получить если узнать, под каким аккаунтом ваш аппсервер общался с базой, а такой аккаунт у всех один.
Ну если у вас требования такие, что ж поделать. Не руками ведь вам их писать, вы генератор сделали. Если хотите ограничить число сущностей — улучшите генератор, чтоб вьюшки были параметризованы, например, пользователем, и/или отслеживайте (случайные) совпадения по условиям, ведь запросы у такого числа людей редко уникальны. А раз условия не уникальны, можно оптимизировать и выдать двум пользователям одну и ту же вьюшку(но параметризовать пользователем всё равно, во имя справедливости). И тогда их будет может быть уже 50250, а может и того меньше.
Кстати, а как вы предложите решать эту задачу без вьюшек? Ну, в смысле, у вас вместо 100500 вьюшек будет 402000 уникальных, сгенерированных вашим data-store в рантайме, запросов? Или есть какие-то мне неизвестные средства, о которых я просто не подумал?
Если роли неопределённые, тогда у вас нет ролей. Но, в принципе, разрешения в СУБД можно выдавать и отдельным пользователям, насколько я помню, только это более муторно.
А если пользователь настраивает разрешения сам, то мы находимся в else моего предыдущего сообщения, и определение разрешений средствами СУБД уже не очень хорошо работает само по себе. Зато у нас есть одно из двух решений:
При этом ни для одного из вами озвученных вариантов требований нет простого пути позволить пользователям решать "может ли пользователь редактировать объект, созданный другим пользователем, или может ли простой менеджер отредактировать документ уже подписанный начальником отдела". Если вьюшки мы считаем моветоном, тогда единственный более-менее реалистичный механизм работы здесь — это императивные проверки в клиенте, где пользователю будет дан чекбокс, оные проверки выключающий, и на этом его конфигурение будет закончено. Проверки, вероятно, нужно будет выразить как некий DSL, чтобы его понимал и фронт, и сервер, либо дублировать несколько раз. На UI это нужно для отзывчивости, и на сервере для надёжности, потому что полное доверие UI в итоге обходится дорого.
Кстати, а чем плох генератор вьюшек? Ну, кроме того, что его, гипотетически, надо писать?
Кстати, не согласитесь ли вы ли вы, что ORM и есть такой генератор вьюшек, только рантайме (в общем случае)? А если "вьюшки" из релиза в релиз не меняются, зачем их генерировать каждый раз, не проще ли будет поместить их сразу в СУБД?
Можно ведь сделать Updatable View, а доступа к самой таблице не давать в принципе. Если совсем строго, можно Updatable View делать на базе Readable View, и к ним иметь разные разрешения на чтение и запись, потому что если умеет обновлять, то должен уметь и читать, а обратное уже неверно.
Не работает такое разве что в платформах, где несколько клиентов на одной базе, и у каждого свои понятия, кому и сколько можно. Ну и представлений писать придётся немало, конечно, под каждую категорию ролей.
Да, вот там прирост по времени 25% потому что не особо важно, и вон там тоже не особо важно было, потому там тоже +30%. А потом сидишь как дурак на компьютере за очень много денег и ждёшь когда очередная программа через дебри экономности продерётся и наконец-то среагирует на клик.
Я к чему. Сами по себе 3 секунды может и не много. Но вы правда верите, что только в единственном месте будет такой прирост? Или что он в будущем не станет ещё больше? Или что, как я выше писал, не сложится с аналогичным приростом ещё откуда-нибудь после рефакторинга?
Так вроде и для СУБД разрешения можно контролировать внутренними механизмами, без всяких процедур.
Вот это вот всё. А то делают GRANT ALL, а потом начинают извращаться с движками проверки ролей в тридевятом царстве, а сами данные тем временем висят голым задом по
system@system, и утекают при первой же возможности.