Недавно опробовал такой подход вкупе с XML-функциями и натолкнулся на сыроватость еще xml-ных функций(например, очень хотел делать выборки а ля select * from xml_sequence(fujnction_returning_cursor())), так что пока на время это отложил.
Вы про планы каких запросов? Если из самодельного pkg_pivot, то cost увеличивается всего на 1 из-за dense_rank, а вообще в общем-то неудивительно, что запрос несколько тяжелее(не хуже, чем другие различные функции, вроде row_number,dense_rank и тд).
Сомневаюсь, что он появится в DDL, как спрашивает там ТС, но вообще, думаю было бы правильно его стандартизировать, т.к. в тех случаях, когда вся логика в самой базе это было бы удобно и правильно.
Да, его вариант в этих случаях гораздо правильнее(не нужно делать лишний запрос), но такие случаи достаточно редки, и хочется большей гибкости. Вообще, наверное, зря я не упомянул, что хотел в свое время добавить условие максимального ограничения для кол-ва столбцов прямо в функцию, но все руки не дотягивались и каждый раз делал в таких случаях просто select case when count(1)<=max_limit then count(1) else max_limit end as max_cols from…
От характера зависит… Знаю несколько людей в близком окружении, которые, наоборот, глобальные крупные задачи решают с большим интересом и усердием, чем многоэтапные унылые задачи для выполнения плана и премий. Кому-то нравится трогаться «с места в карьер», а кому-то охота медленно, но верно.
Да причем тут выборки/вставки? Сравниваем функции, причем встроенные функции и пользовательские, причем алгоритм base64 никак не быстрее простого изменения типа.
Чтобы отпали последние вопросы по поводу размеров: как и когда выполняются функции?
Как я уже говорил — размер базы и таблицы значения не имеет. Имеет значение лишь кол-во вызовов. И уж собственная хранимка для декодирования base64 однозначно будет выполняться медленнее встроенной функции преобразования.
Как хранится тут не причем, это же функции. И вообще что-то я не нашел встроенной функции в MySQL для base64.
Проверил выполнение кодировки в hex и обратно:
«select test_hex(100000) from dual» выполнился за 2.3 секунды на слабеньком железе, где
CREATE FUNCTION `TEST_HEX`(i INTEGER(11))
RETURNS int(11)
BEGIN
DECLARE v TEXT;
WHILE i > 0 DO
SELECT UNHEX(HEX('a123')) into v from dual;
SET i = i - 1;
END WHILE;
RETURN v;
END;
А если хочется ну совсем уж извратиться «гениальностью», то можно вообще в базе все только в blob'aх хранить — совсем ничего не надо будет ничего «защищать».
Для приведенного примера:
PS. и какой знаток баз данных еще и минусует?
Чтобы отпали последние вопросы по поводу размеров: как и когда выполняются функции?
Проверил выполнение кодировки в hex и обратно:
«select test_hex(100000) from dual» выполнился за 2.3 секунды на слабеньком железе, где
CREATE FUNCTION `TEST_HEX`(i INTEGER(11)) RETURNS int(11) BEGIN DECLARE v TEXT; WHILE i > 0 DO SELECT UNHEX(HEX('a123')) into v from dual; SET i = i - 1; END WHILE; RETURN v; END;