delover Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору AlexPetrovich О, я люблю пошутить за это злюсь конечно на себя, но на этом вся ваша правота заканчивается. В ПМ могу скинуть ссылку на БД полностью в исходниках. По этому я смелюсь утверждать что знаю про что пишу не из теории...   Цитата: Да хоть 10. Это определяет разработчик в зависимости от решаемой задачи.   Как разработчику мне ни разу не понадобилось в течении 20-и лет эта возможность.     Цитата: Потому что сервер не должен "додумывать" за разработчика и заниматься "самодеятельностью".   То есть обязан лениться из принципа и быть далёким от реально возможной оптимизации.   Цитата: А с какого перепугу "пользователи" пишут SQL-запросы ?? Пользователей сервера можно назвать пользователями, пользователей моего по тоже можно назвать пользователями, тем не менее я пользователь сервера и не стесняюсь этого. У меня сейчас планирование собственного сервера и SQL как стандарт заранее не устраивает - тут подробнее.   OnWhere - выполняет фильтрацию. OnJoin - выполняет добавление полей в выборку. Насколько знаю - сильно не бейте, сначала выполняется приджойнивание (условия джойна) а потом условия where - это справедливо для того чтобы в условиях могли присутствовать поля из всех таблиц запроса. Однако.   Та база пока что не сервер. И я смотрю как реализован Selet. О чудо OnWhere выполняется до OnJoin. Я понимаю автора - в клиентской базе все данные все таблицы уже доступны в OnWhere и нет просто смысла выполнять Join данных до выполнения Join условий которые доступны в событии OnWhere... Выборка мастер детейла на двух таблицах с тремя миллионами делается в миллисекунду. Это происходит за счёт того что в первую очередь выбирается правильный индекс. То есть - берётся индекс который высчитан по условию либо больше либо меньше либо если равно то либо больше либо меньше реальный RecNo. И вся выборка первично идёт из локейта на первую позицию по условию потом чтение пока условие true.     !!! Так вот когда я могу вычленить это условие из запроса Я могу делать выборку за одну миллисекунду на трёхмиллионных таблицах и далее делать дополнительную фильтрацию дубляж джойнами и условиями конечной фильтрации. И даже больше если вы дадите запрос groupBy я его интелектуально как девелопер разберу и выполню на тех же данных что и FB сервер в сотню раз быстрее, потому что именно вычленю оптимальное условие.   Цитата: Вообще-то это стандарт, и практически всех устраивает. Слава Богу, что вы далеки от разработчиков этого стандарта...   Вы косо читали впереди я писал - сервер FB в посте выше был запрос делает 2 раза чтение в трёхмиллионных таблицах выбрав не те индексы. И он это делает когда я заранее знаю что он ничего не вернёт. Я пишу ПО далее отдаю в техподдержку которая его полгода мучает - отдает мне, после релиза мучается сама. Мои попытки реорганизовать в запросах план запроса не дали необходимых мне результатов, если вы внимательно читали что я пишу то понимаете почему - Join по 3 миллионам всегда идёт раньше чем первичное условие мастер-детайл.     ВЫВОД - Не кипятитесь теоретики, на уважаемых ресурсах. Я могу выложить все данные все ссылки все цыферки сравнения. Напишу инструкцию на русском как запустить и Вы никогда в жизни не добётесь этих же результатов на стандартном SQL    (Перед тем, как писать всякую муть на уважаемых ресурсах, славо богу если научитесь так же уважать себя). Я про экономию электроэнергии. Почему на уважаемом ресурсе не уважают экономию энергии тупо простаивающих компов?   ps Девелопер не бог, всего учесть не может даже за полгода - результат еле ворочающиеся программы и безполезный в этом случае SQL, который можно было бы оптимизировать в 100 раз, абсолютно уверен.     Добавлено: И В ПЕРВУЮ ОЧЕРЕДЬ SQL не устраивает из того принципа что сервер не должен делать предположений. Всего записей: 1395 | Зарегистр. 25-06-2007 | Отправлено: 15:43 10-05-2012 | Исправлено: delover, 01:29 27-07-2012

AlexPetrovich Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору delover Извините, но я категорически не понимаю ваш поток сознания... Удачи вам в разработке собственного SQL   Добавлено: После просмотра ваших ссылок я вроде понял о чем вы... То, что на локальной машине можно произвести выборку из локальных данных быстрее, чем это сделает SQL-сервер ?  В это верю конечно. И изредка такой подход оправдан. НО!  Это имеет смысл только в очень узко применимых задачах, когда стандартные методы не работают. Потому как теряется многопользовательская работа, транзакции, и проч.   Если вы уверены, что вашу задачу можно решить только так - ну что ж, вы разработчик, вам виднее.   Но это совсем не значит, что SQL-стандарт "плохой" и сервера БД "плохие". Просто их тоже надо уметь использовать. У меня в БД таблицы по 10 млн записей и все летает... Всего записей: 90 | Зарегистр. 08-05-2003 | Отправлено: 15:57 10-05-2012

X11 Silver Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Вот что вам даст ускорение одного запроса с 100 до 1 мс ?   когда этот проверяется на 1000 записях, то оно понятно, что разницы нет, но когда таблица вырастает до 100 тыщ или мульёна.... то разница уже сильно заметна и тогда приходится выполнять редизайн приложения. ---------- /не мы такие, жизнь такая/ Всего записей: 3253 | Зарегистр. 24-11-2005 | Отправлено: 12:49 17-05-2012

AlexPetrovich Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору X11 Цитата: когда этот проверяется на 1000 записях, то оно понятно, что разницы нет, но когда таблица вырастает до 100 тыщ или мульёна....   Опять про сферического коня...  Пример реальной задачи где ?   К тому же этот запрос как раз и работает с таблицей в которой 5 000 000 записей и ее размер ~350 МБ.   По моему 100 мс - не так и плохо.   Добавлено: delover Цитата:  Выполним на базе селект    select * from table1 t    where t.parent_id between 5 and 5 and      t.grade_id between 0 and 3000000    - хоть как оптимизируйте уже 100 миллисекунд.     И кстати - откройте для себя хинты.   "Оптимизируем" немного этот запрос:  select * from table1 t    where t.parent_id between 5 and 5 and      t.grade_id+0 between 0 and 3000000     И "внезапно" - он выполняется за 0 мс   Можно просто к исходному запросу приписать план PLAN (T INDEX (TABLE1_IDX2))   Эффект тот же.   И не нужно переписывать в 3 сджойниных подзапроса... Всего записей: 90 | Зарегистр. 08-05-2003 | Отправлено: 13:22 17-05-2012 | Исправлено: AlexPetrovich, 13:32 17-05-2012

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104

Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » InterBase и FireBird: вопросы по работе и их решение

Переход по форумам  Закладки   » Компьютеры Цифровое изображение Программы Microsoft Windows UNIX Другие OS Hardware В помощь сисадмину Прикладное программирование Игры Форумные игры   » Интернет Web-программирование В помощь вебмастеру Графика Хостинг Зацените-ка!   » Тематические Ikonboard v.2 Ikonboard v.3 Invision Board Другие форумы PHP-Nuke и другие порталы Мобила   » Общие Спорт Флейм Темы по региональным встречам Музыка и Кино Юмор Литература и Живопись   » Ru.Board Новости Помощь по форуму   » Андеграунд eBookz Варезник Раздачи и акции Мобильный варезник Андеграунд Игры и фильмы   » Специальные Тестирование