Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
Честно говоря, не думал, что это вы серьезно спрашивали. Хм. Удобный подход. Сколько вы там приводили в пример? четыре кажется. Ну две я уже приводил, Две - это насколько я помню, созданных незнамо кем. Если Вы говорите про "ораклистов", мне были бы интересны темы людей, про которых видно, что они именно "ораклисты". вот еще три /topic/226311&hl=oracle+%ee%f0%e0%ea%eb Тема в форуме MS SQL создана человеком, который писал только в MS SQL. Да, это безусловно ораклист, который не любит MS SQL. И, кстати, судя по всему, тем в "Сравнении СУБД" Вам уже не хватило. Вы не пробовали поискать по форуму оракла, сколько там аналогичных тем от мигрантов? /topic/190896&hl=oracle+%ee%f0%e0%ea%eb+sql Изрядно притянуто за уши. Тема "Объективно существующее нарушение стандарта ANSI SQL в MS SQL SERVER" если и тянет на флейм, то только в глазах очень пристрастных фанатов. Ну или если соблюдать принцип паритета - поищите аналогичные высказывания по поводу пустых строк в Oracle, и приплюсуйте их к добавленным мной. /topic/202804&hl=oracle+%ee%f0%e0%ea%eb+sql Согласен, зачтено. Собственно из всех пяти теперь тем - единственный четкий пример. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 13:44 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
ASCRUSТо есть как раз JOIN-ы позволяют явно описать порядок соединения таблиц и таким образом избавиться от неоднозначности и дать возможность оптимизатору построить наиболее эффективный план запроса. Думаю не стоит напоминать, что чем более явно описаны соединения, тем легче оптимизатору правильно решить, что будет наиболее выгодным при выполнении запроса. Это в сайбез так? Бред какой то :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 13:51 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
softwarerКстати, подскажите - можно ли отформатировать from с использованием join-ов так, чтобы Спасибо за ответы. Названные способы однотипны, но пока к сожалению становятся неудобными, как только появляются неравномерные длины названий таблиц и дополнительные слова в join-ах, то есть начинается что-то типа Код: plaintext 1. 2. 3. 4. 5. это, конечно, решает поставленную задачу, но имхо само по себе довольно малочитабельно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 13:52 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
а если так автор from DocumentProperties p join Documents d on d.doc_id = p.doc_id left join Subscribers s on d.subscriber_id = s.subsriber_id ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 13:56 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
ой ошибся, сори Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 13:57 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
чем лично мне нравиться писать через join (я кстати тоже долго не мог привыкнуть) допустим есть запрос Код: plaintext 1. 2. 3. Код: plaintext 1. 2. 3. кагда таблиц с десяток, то выбрать таблицу и условия, по которым она связана уже становится тяжело ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 14:13 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
ASCRUSХочется посмотреть на пример. Причем такой, по которому оптимизатор однозначно бы соединял между собой b и c внутренним соединением и приводил результат соединения, как внешнее соединение к таблице a. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Собственно, хинт я здесь влепил только для того, чтобы не лазить в документацию и не проверять, есть ли теоретическая возможность развернуть это view. Практически и без него не разворачивается. ASCRUSТо есть как раз JOIN-ы позволяют явно описать порядок соединения таблиц и таким образом избавиться от неоднозначности и дать возможность оптимизатору построить наиболее эффективный план запроса. Менее эффективный план. Поскольку сужает пространство вариантов, и наиболее эффективный план запросто окажется отсеянным. ASCRUSДумаю не стоит напоминать, что чем более явно описаны соединения, тем легче оптимизатору правильно решить, что будет наиболее выгодным при выполнении запроса. "Наиболее выгодным из чертовски ограниченного пространства вариантов". Правда, Oracle здесь выглядит молодцом, поскольку все-таки умеет начхать на прописанный порядок join-ов и выбрать эффективный вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 14:42 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
Сергей84 Имхо - ужасно, по крайней мере если работать с этим в обычном текстовом редакторе. Хотя безусловно, вопрос вкусов. SergSuperи нам надо одну таблицу исключить (для отладки) - тогда коментим одну строчку и все Код: plaintext 1. 2. 3. Хм. А поля из b не входят в select? Или Вы всегда пишите *? А join e не отваливается с ошибкой "field [f] does not exist"? А в where на поля из b не наложено никаких дополнительных условий? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 14:49 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
ну как говорится на вкус и цвет во всяком случае для меня в QA - так удобнее, после чего я делаю обчно Ctrl+C и в 1С Ctrl+V добавляю ковычки что типа это текстовая переменная и все, если же что-то где-то неконтачит, открываю Profiler вылавливаю , вставляю в QA и опять получаю хорошо отформатированный и наглядный текст запроса на счет 2-го вопроса, хотя он был задан и не мне, я предпоситаю переменные одной таблици и условия описывать одной строкой, типа: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. сложнее когда поле является вычисляемым, например a.a1+b.b1 и т.п. P.S. все изложенное ИМХО, и настаивать на изменении своих взглядов на ворматирование запросов не буду как кто хочет - пусть так и делает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 14:58 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
pkarklinПредлагаю сойтись на том, что это "дело привычки". Дело привычки - безусловно. Но раз уж поднялось, хочется понять какие-то объективные различия того и другого подхода - пусть и не сходясь в оценке этих различий. softwarerИз-за этого достаточно часто начинают пихать в join дополнительные условия, которым вообще-то место именно в where или в подзапросе pkarklinРассмотрим такой запрос: ..... Т.е. вывести все записи из T2 по определенному SomeID плюс NULL. Таки надо пихать именно в JOIN. Отнюдь. Если я правильно понял, что Вы хотите получить... Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. pkarklinНасчет " join с inline view" надо конкретный запрос увидеть, чтоб понять, что Вы имеете ввиду. Да собственно говоря, Ваш же пример. Если взять суть того, что хочется получить, то для наглядности требуемого его стоит записать примерно так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Не знаю, насколько это универсальный термин, но для Oracle такой подзапрос принято называть inline view. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 15:12 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
Сергей84благодаря этому легко исключается таблица из обработки Я как раз и имею в виду, что в Вашем примере, чтобы исключить таблицу b из обработки, нужно закомментировать три строки. Если переписать его в том же стиле без join, как Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. для исключения таблицы b придется закомментировать опять же три строки. То есть, собственно, не вижу разницы между вариантами c точки зрения этого аргумента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 15:19 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
softwarer Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. для исключения таблицы b придется закомментировать опять же три строки. То есть, собственно, не вижу разницы между вариантами c точки зрения этого аргумента. К тому же, это выглядит читабельней. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 15:27 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
softwarerДело привычки - безусловно. Но раз уж поднялось, хочется понять какие-то объективные различия того и другого подхода - пусть и не сходясь в оценке этих различий. Ок. Попробуем. Для сиквел сервера в смысле плана выполнения следующие запросв эквивалентны: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Так что тут действительно дело вкуса. А вот такой уже не пройдет на сиквел сервере: Код: plaintext 1. 2. потребовав ссылок на колонки в объединении. НА счет объективного различия. Сравним результаты, казалось бы одного и того же запроса: Код: plaintext 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 16:07 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
И еще, я не представляю, как, например, следующий запрос можно переписать с объединением в WHERE: Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 16:18 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
softwarer Сергей84благодаря этому легко исключается таблица из обработки Я как раз и имею в виду, что в Вашем примере, чтобы исключить таблицу b из обработки, нужно закомментировать три строки. Если переписать его в том же стиле без join, как Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. для исключения таблицы b придется закомментировать опять же три строки. То есть, собственно, не вижу разницы между вариантами c точки зрения этого аргумента. В таком случае действительно всё равно. Но в 80% случаев удаётся и в одной строке. Например в данном случае если мы добавляем таблицу b то логичней все её условия написать в условиях связи( on a.a_id = b.b_id and b.b2 in (1,2,3) ).Таблицу "а" мы так легко не выкинем, но чаще имеет смысл выкидывать сразу "а" и "b" - "b" вторичная по отношению к "а" ЧубурашкаК тому же, это выглядит читабельней. Ce,]Очень субъективно. Мне это представляется как свалка таблиц и огород условий. А так добавили таблицу - и тут же её условия. А вообще пару лет назад я тоже как вы думал. У вас еще всё впереди :) Топик плавно перерос в тему "А чего это любители WHERE не любят JOIN?" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 16:21 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
SergSuperУ вас еще всё впереди Видать у softwarer`а тоже ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 16:28 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
SergSuper В таком случае действительно всё равно. Но в 80% случаев удаётся и в одной строке. Например в данном случае если мы добавляем таблицу b то логичней все её условия написать в условиях связи( on a.a_id = b.b_id and b.b2 in (1,2,3) О! Позволю себе отметить этот момент, почему: потому что он в точности иллюстрирует мой тезис насчет соблазна начать тащить во from то, чему полагается быть в where или в inline view. Обратите внимание: практически Вы решаете таким образом то, что я назвал недостатком join; Вы снова группируете в одном месте все, что относится к одной таблице. Разница только в том, что Вы предпочитаете собирать все во from и работать без where, я - наоборот. Не готов сходу сказать, заменяемы ли эти подходы, то есть можно ли написать в join нечто, чего нельзя написать в where. Но если подходить сугубо логически - таким образом Вам приходится тащить во from то, что не имеет никакого отношения к "соединению". where в этом плане более универсален; собственно я довольно часто повторяю фразу, что новичку проще всего представить себе выполнение sql-запроса как картезиан из таблиц во from, на который накладывается фильтр, заданный в where. SergSuperОчень субъективно. Мне это представляется как свалка таблиц и огород условий. Угу. Мне - как книга с оглавлением и текстом. Видно, что связывается, если есть вопросы, можно посмотреть, как связывается. Собственно, если бы я нашел устраивающее меня решение двух задач: во-первых, именно "четко видеть таблицы, участвующие в запросе", и во-вторых "разумным образом писать условия, не ложащиеся в концепцию связи таблиц", например, условия на несколько таблиц - думаю, согласился бы с Вами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 16:38 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
softwarerсобственно я довольно часто повторяю фразу, что новичку проще всего представить себе выполнение sql-запроса как картезиан из таблиц во from, на который накладывается фильтр, заданный в where. Дежавю. ;) Т.е. представить совсем наоборот, как происходит на самом деле! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 16:56 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
pkarklinА вот такой уже не пройдет на сиквел сервере: Хм. А что-нибудь типа Код: plaintext Впрочем, в любом случае это во-первых означает таки желательность использования inline view, во-вторых, смело можно назвать недостатком реализации (по крайней мере логики в таком ограничении я не вижу). pkarklinНА счет объективного различия. Сравним результаты, казалось бы одного и того же запроса: Ну, написать "казалось бы одинаковые" запросы можно всегда и любым инструментом. А можно писать так, как нужно: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. pkarklin И еще, я не представляю, как, например, следующий запрос можно переписать с объединением в WHERE: Хм. Не вижу проблемы. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Хм. Пока что у меня сложилось впечатление, что в MS SQL в силу каких-то странных соображений конструкция outer join via * весьма и весьма ограничена в возможностях - и все. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 17:05 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
pkarklinДежавю. ;) Т.е. представить совсем наоборот, как происходит на самом деле! Если помните, SQL - декларативный язык, призванный максимально разделить "что делать" и "как это делается". Безусловно, постепенно нужно закапываться в реализацию, но вываливать ее на новичка оправданно только если нужно убедить этого новичка бежать подальше от этого SQL. Этой фразы (с расшифровкой понятия картезиана) хватает, чтобы человек, никогда не имевший дело с БД, понял происходящее и правильно пользовался - проверено, лично мной. На столь же понятное объяснение join-ов - я бы с удовольствием посмотрел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 17:09 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
softwarerО! Позволю себе отметить этот момент, почему: потому что он в точности иллюстрирует мой тезис насчет соблазна начать тащить во from то, чему полагается быть в where или в inline view. Не сомневался что вы зацепитесь за это :) А я просто предложил писать как можно логичней. Если это еще одна основная таблица, то тогда конечно надо условия писать во where, но тогда и выкидывать её из запроса смысла нет. А если это, допустим некие аттрибуты, то очень даже логично держать условия вместе с таблицей. softwarer собственно я довольно часто повторяю фразу, что новичку проще всего представить себе выполнение sql-запроса как картезиан из таблиц во from, на который накладывается фильтр, заданный в where. А меня в школе учили писать перьевой ручкой, хотя вовсю уже были шариковые. Я тоже себе так представлял - но это потому что по другому через where не написать. (Хотя на самом деле насчет новичков - это согласен, им полезно) softwarer ...если бы я нашел устраивающее меня решение двух задач: во-первых, именно "четко видеть таблицы, участвующие в запросе"... осталость только научиться четко видеть :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 17:15 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
andy stмне, к примеру он уже не светит ввиду свежеобнаруженных баговВот это на самом деле важно. Какие баги вы уже обнаружили в MSSQL2005? Вопрос не праздный. Т.к. мы только что приступаем к тестированию MSSQL2005. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 17:24 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
SergSuperНе сомневался что вы зацепитесь за это :) Не столько ради Вас, сколько ради pkarklin-а :) SergSuperА я просто предложил писать как можно логичней. Если это еще одна основная таблица, то тогда конечно надо условия писать во where, но тогда и выкидывать её из запроса смысла нет. А если это, допустим некие аттрибуты, то очень даже логично держать условия вместе с таблицей. А если в запросе три основных таблицы? При этом в рамках отладки одну из них желательно выкинуть? Как только мы уходим от простейших примеров, "как можно логичней" становится довольно неоднозначным. Да и собственно разделение на "основные таблицы в where, вспомогательные во from" не кажется мне априори более логичным, чем "таблицы во from, ограничения на таблицы в where". SergSuperА меня в школе учили писать перьевой ручкой, хотя вовсю уже были шариковые. Если хорошо учили - искренне завидую. SergSuperЯ тоже себе так представлял - но это потому что по другому через where не написать. Дык в этом-то и идея SQL-я как языка. Согласитесь, довольно трудно и несколько странно объяснять непонимающему человеку, почему я вроде бы пишу операцию join, типа Код: plaintext 1. а если посмотреть в план - там будет merge join cartesian, и это будет наиболее эффективным планом для этого запроса. С другой стороны, с декларативным подходом никаких непониманий не возникает; написали фильтр, сервер выбрал наиболее эффективный способ его реализации, все замечательно. SergSuper осталость только научиться четко видеть :)) Дык уже. Наиболее удобный способ четко видеть я и использую ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 17:32 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
softwarerХм. А что-нибудь типа ... Такой запрос для MS SQL синтаксически не верен. softwarerВпрочем, в любом случае это во-первых означает таки желательность использования inline view, во-вторых, смело можно назвать недостатком реализации (по крайней мере логики в таком ограничении я не вижу). Эээ... Не вижу недостатка ни в использовании inline view (хоть такого термина и не существует для MS SQL), и уж тем более в реализации. Вряд ли можно отнести к недостатку реализации "запрет" на написание всего и вся в предложении WHERE. IMHO. softwarerНу, написать "казалось бы одинаковые" запросы можно всегда и любым инструментом. А можно писать так, как нужно: Я ничуть не сомневался, что вы напишите "правильный" запрос. Хотя ввод ANSI стандартом объединение во FROM как раз и был призван устранить неодназначность, которую я описал! softwarerПока что у меня сложилось впечатление, что в MS SQL в силу каких-то странных соображений конструкция outer join via * весьма и весьма ограничена в возможностях - и все. Конечно, ограничена. Просто часть "возможностей" реализована в другом месте (FROM), что опять же лично я не считаю недостаткоом реализации, а совсем наоборот. Хотя вот эта фраза, которую Вы непервый раз произносите: softwarerсобственно я довольно часто повторяю фразу, что новичку проще всего представить себе выполнение sql-запроса как картезиан из таблиц во from, на который накладывается фильтр, заданный в where. Полностью объясняет Вашу "любовь" к WHERE. softwarerЭтой фразы (с расшифровкой понятия картезиана) хватает, чтобы человек, никогда не имевший дело с БД, понял происходящее и правильно пользовался - проверено, лично мной. На столь же понятное объяснение join-ов - я бы с удовольствием посмотрел. Я не представляю уровень новичка, которому нужно было бы объяснять про прямое, левое и правое объединение более, чем их определение!!! Или этому новичку надо чем-нибудь другим заниматься. А вот "объяснение" с искажением сути происходящего, то есть с искажением того, что он увидит в плане выполнения запроса считаю в корне не правильным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 17:46 |
|
||
|
Почему ораклисты так не любят MS SQL?
|
|||
|---|---|---|---|
|
#18+
Где-то с полгода назад в Инете читал статейку, где JOIN & WHERE проходили под таким соусом (м.б. совру - тогда киньте в меня продуктом переработки пищи, т.е. стулом, но желательно не жидким): - В случае объединения с JOIN данные из связанных таблиц сначала фильтруются по условиям указанным в нем - потом объединяются. Затем из результирующего набора "вычеркиваются" записи не соответствующие WHERE - В случае объединения только с WHERE создается результирующая как декартово произведение всех таблиц, затем не соответствующие WHERE записи "вычеркиваются". Пару раз пытался уловить разницу по скорости/эффективности (правда не особо старался) - не получилось. Так что на практике использую и то и другое. Что в данный момент удобнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2005, 17:52 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=33393248&tid=1553678]: |
0ms |
get settings: |
11ms |
get forum list: |
21ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
36ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
84ms |
get tp. blocked users: |
2ms |
| others: | 176ms |
| total: | 349ms |

| 0 / 0 |
