| Nichka |
 Отправлено: 05.02.2005, 14:10 |
|
Не зарегистрирован
|
Чисто теоретический вопрос.
Никак не могу решить какой вариант использовать для хранения относительно несложных стандартных запросов.
Хотелось чтобы было быстро и просто.
1. Процедуры?
Выполняются на сервере, снижают нагрузку на сеть и вообще компилится один раз, а потом хоть обвыполняйся.
но в документации напсано:
| QUOTE | | Процедуры, содержащие простые запросы и большое количество аргументов, менее эффективны. |
(интересно, относительно чего?..)
2. Представление? (View)
в той же документации
| QUOTE | | представления ссылаются на информацию в базовых таблицах, но не содержат копий этой информации; при каждом вызове представления она вычисляется заново. |
Чтобы это значило? что select и view выполняются одинаково?
Но ведь представление уже хранится в базе и вполне может быть оптимизировано. Доказательств этому я не нашел, а проверить пока нет возможности.
Извините за тупой вопрос. |
|
| olegenty |
| Отправлено: 07.02.2005, 07:55 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
1. Какая СУБД? (скажем, для MSSQL неверно, что процедура компилится 1 раз. MSSQL сам решает, когда и что перекомпиливать, из встроенных соображений)
2. а что, средств для анализа производительности нет? для IB/FB/Yaffil это IBExpert, для MSSQL — QueryAnalizer. реализуешь оба варианта, и смотришь, какой быстрее работает. у MSSQL есть ещё возможность создавать Indexed View — это точно будет работать быстрее, чем хранимая процедура, но с ограничениями и применять нужно осторожно (много раз подумав)
|
|
| AVC |
| Отправлено: 07.02.2005, 10:26 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
Действительно, пока не известна СУБД однозначного ответа получить не удастся.
по 2. View действительно не хранит информацию а только текст Select'а. Его дествие (в первом приближении) можно рассматривать как макроподстановку в текст целевого Select. Реализация этого действа так-же сильно зависит от СУБД.
|
|
| Nichka |
| Отправлено: 07.02.2005, 13:50 |
|
Не зарегистрирован
|
База — Sybase ASA.
А производительность пока не могу проверить.
Данных в базе пока мало и все летает одинаково. |
|
| AVC |
| Отправлено: 07.02.2005, 16:36 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
В Sybase ASA 6 с процедурами, функциями и представлениями все впорядке. Можно смело пользоваться.
PS. Создать тестовую таблицу можно, например, перекопировав системные описания объектов базы данных (Select * From sys.SysTable/SysColumn) несколько раз.
|
|
| Gedeon |
| Отправлено: 07.02.2005, 17:09 |
|
Ветеран
Группа: Модератор
Сообщений: 1742
|
Было немного времени, решил для Вас поиграться.
5,5,04 Build #1965
Для таблицы с 500000 записей и разными условиями я разницы не заметил, правда проверял подряд поэтому не исключаю ситуацию, что где-то что-то кэшировалось, и данные м.б. неточными. В общем-то говоря я не очень знаю этого зверя, и не нравится он мне, но если Вас интересуют какие-нить специфические запросы могу погонять.
|
|
| Nichka |
| Отправлено: 07.02.2005, 23:14 |
|
Не зарегистрирован
|
2AVC
спасибо за идею.
Тестил на таблице в 19 столбцов с 15000 записями.
@@Version '9.0.1.1751'
Запрос проще некуда (отбирает 16 записей из всей таблицы)
| SQL | Select * From temp where a4 = 21
|
В итоге у меня получились следующие результаты:
Худший результат показала процедура вызывающая select. (~0.110sec)
Следующий результат у процедуры вызывающей View. (~0.063sec)
Второе место занимает прямой вызов select. Опережает процедуру примерно в два раза. (~0.036sec)
И на первом месте с подавляющим результатом оказался View! С опережением selecta еще в два раза. (~0.018sec)
Вот так вот.
А я хотел уже крест на представлениях поставить. |
|
| AVC |
| Отправлено: 08.02.2005, 10:10 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
То, что view показал лучший результат вам просто повезло. Скорее всего данные уже были в кеше. Еще раз повторюсь — View это просто сохраненный текст Select'а (за ним не стоят данные). Небольшой (практичиске незаметный) выигрыш можно получить только за счет сокращения размера текста запроса при использовании view. Основное назначение view — накладывание ограничений и, зачастую, упрощение текста запросов. |
|
