|
Задавайте вопросы, мы ответим
Вы не зашли.
Привет
У меня есть БД, работая с которой, я посылаю запросы на выборку, изменение, и тому подобное...Ну, в общем, как обычно.
Мне тут сказал один человек: Ты бы, говорит, всю логику на СУБД повесил - и клиент бы тоньше стал, и изменять в одном месте только придется, если что!
Дык вот, "всю логику на СУБД повесить" - это как, это я должен насоздавать хранимых процедур для любых операций с базой?..
Тогда я могу ваще закрыть доступ к таблицам, а нараздовать прав на хранимки. Таким образом, я могу управлять доступом не к данным, а к операциям с данными...идея мне понравилась
Хотелось бы это обсудить.
Целесообразно ли все операции с данными проводить через хранимки?
Есть ли какая-то возможность, структурировать хранимки?
Так ваще кто-нибудь делает? Или так делают все?
2администрация: что за ограничение на длину заголовка, хотел понятный заголовок написать - не влез...
Неактивен
Так делают, но не все, естественно.
Причины так поступить:
1. доступ к базе из разных приложений - можно избежать дублирования кода
2. структура и количесвто таблиц меняется со временем
3. обеспечение унифицированного доступа из одного приложения к базам с разной структурой (и возможно не только MySQL)
4. требуется проверка входных, которая не может быть выполнена в триггере и требует дополнительных привелегий
Причины так не поступать:
1. таблицы достаточно простые и не меняются
2. доступ только из одного приложения к одной базе
3. доступ только для одного юзера
4. невозможность позволить себе дополнительное время выполнение на запуск процедуры
Ограничение Вы имеете в виду 70 символов в поле заголовка? Если не хватает, можно увеличить.
Неактивен
iCode написал:
Есть ли какая-то возможность, структурировать хранимки?
Что Вы имеете в виду по структурированием? Хранимая процедура имеет имя и принадлежит базе данных. Она может вызывать другие хранимые процедуры.
Неактивен
Подобный вопрос недавно на ЛОРе обсуждался (правда в специфичном ракурсе)
http://www.linux.org.ru/view-message.jsp?msgid=1942141
Неактивен
rgbeast написал:
4. невозможность позволить себе дополнительное время выполнение на запуск процедуры
Не понял...
Какое дополнительное время? К чему дополнительное?
rgbeast написал:
Ограничение Вы имеете в виду 70 символов в поле заголовка? Если не хватает, можно увеличить.
Да, конечно я имел в виду 70 символов...Это мало по-моему...Мне по крайней мере не хватило, чтобы описать в заголовке тему.
rgbeast написал:
Что Вы имеете в виду по структурированием?
Ну, скажем, возможен ли объектно-ориентированный подход при написании бизнес-логики вообще и хранимок, в частности?
Неактивен
Дополнительное время обычно играет роль на очень загруженных серверах.
Это время на получение кода процедуры, проверки прав, обработки и т.п.
ООП подразумевает наследование, инкапсуляцию и прочее. И его, разумеется
ни в каком виде тут нет: процедуры не наследуются, не принадлежат объектам.
Однако, Вы можете придумать какой-нибудь хитрый метод их структуризации,
т.к. они принадлежат базам.
Например, так:
1. Создаете пустую базу obj1
2. Создаете в ней процедуру a
3. Из "реальной" базы запускаете obj1.a
Выглядит как ООП
Хотя, если честно, по-моему это некоторое усложнение...
Неактивен
Дополнительное время играет роль, если сами запросы выполняются быстро. Например, приложение выполняет много запросов типа select 2+2; В таком случае, если данный запрос включить в процедуру, время вызова процедуры будет сравнимо со временем выполнения запроса. Если же в процедуре выполняются сложные запросы или много запросов, то время вызова процедуры будет пренебрежимо мало.
Ходит байка, что Керниган или Ритчи сказал всем, что нужно использовать функции, где это только возможно, так как их вызов осуществляется очень быстро а языке C. Все поверили и стали использовать, а потом оказалось, что вызовы функций могут занимать до 50% времени выполнения программы. Но было уже поздно
Размер поля расширен до 100 символов.
Неактивен
Не хотел начинать новую тему, коль уж разговор зашел о скорости выполнения.
Насколько быстр оператор(команда): USE db_name;
когда при выполнении запросов нужно обращаться к разным DB, так вот думаю сделать разные соединения или делать USE?
Неактивен
Это замена строки в памяти... очень быстро.
Когда надо обращаться к разным БД, можно обойтись одним соединением
и не делать USE. Например, вот так:
SELECT t1.a, t2.b FROM db1.table1 t1 JOIN db2.table2 t2 ON t1.c = t2.d
Сервер всегда полностью расшифровывает названия таблиц:
root@localhost : (none) > use mysql Database changed root@localhost : mysql > explain extended select User from user; +----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+ | 1 | SIMPLE | user | index | NULL | PRIMARY | 228 | NULL | 6 | Using index | +----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+ 1 row in set, 1 warning (0,00 sec) Note (Code 1003): select `mysql`.`user`.`User` AS `User` from `mysql`.`user`
Обратите внимание на последний запрос - это то, что реально выполняется после
прохода парсера.
Неактивен
