Синтаксис Oracle - нужно ли выбирать между старым и новым?

Question

Я работаю над кодовой базой в районе около 1 000 000 строк исходного кода в команде из примерно восьми разработчиков. Наш код в основном представляет собой приложение, использующее базу данных Oracle, но этот код со временем развивался (у нас много исходного кода с середины девяностых!).

В команде возник спор по поводу синтаксиса, который мы используем для запросов к базе данных Oracle. В настоящее время подавляющее большинство наших запросов использует «старый» синтаксис Oracle для объединений, что означает, что у нас есть код, который выглядит следующим образом ...

Пример внутреннего соединения

select customers.*
       , orders.date
       , orders.value 
from customers, orders
where customers.custid = orders.custid

Пример внешнего соединения

select customers.custid
       , contacts.ContactName
       , contacts.ContactTelNo 
from customers, contacts 
where customers.custid = contacts.custid(+)

Когда к команде присоединились новые разработчики, мы заметили, что некоторые из них предпочитают использовать запросы SQL-92, например:

Пример внутреннего соединения

select customers.*
       , orders.date
       , orders.value 
from customers inner join orders 
     on (customers.custid = orders.custid)

Пример внешнего соединения

select customers.custid
      , contacts.ContactName
      , contacts.ContactTelNo
from customers left join contacts 
      on (customers.custid = contacts.custid)

Группа A говорит, что каждый должен использовать «старый» синтаксис - у нас много кода в этом формате, и мы должны ценить согласованность. У нас нет времени, чтобы пройти весь код, переписывающий запросы к базе данных, и мы бы не заплатили за него. Они также указывают, что «мы всегда так поступали, и нам это удобно ...»

Группа B, однако, говорит, что они согласны с тем, что у нас нет времени возвращаться и изменять существующие запросы, нам действительно следует принять «новый» синтаксис кода, который мы пишем с этого момента. Они говорят, что разработчики действительно смотрят только на один запрос за раз, и, поскольку разработчики знают оба синтаксиса, нечего получить от жесткого соблюдения старого синтаксиса, который может быть признан устаревшим в некоторый момент в будущем.

Не объявляя, к какой группе относятся мои сторонники, мне интересно услышать мнение беспристрастных наблюдателей - так что давайте начнем игру!

Martin.

Ps. Я сделал это вики-сообществом, чтобы не выглядеть просто нагло гоняться за вопросами ...

Answer 1

Подобная вещь здесь, но не так много разработчиков, и не так, как старый код.Я использую более новые вещи, более старые парни используют старый стиль, но мы оба знаем, что другой пытается сделать.

Лично я бы сказал, что придерживайтесь того стиля, который легче для человека.Разработчик использовать.Если вы не запустите тесты и не обнаружите, что один из них быстрее другого (как, например, достаточно различий, чтобы быть значительным), и как новые, так и старые могут читать и понимать запросы, которые они видят, нет причин для их изменения.

Тем не менее, мой личный голос будет состоять в том, чтобы оставить все как есть и написать новые запросы с использованием более нового синтаксиса, так как с помощью JOIN s, USING и ON и т. Д. Намного прощепрочитайте и узнайте, что происходит, а затем наберите AND x.col = y.col AND z.col = a.col в разделе WHERE.

Это, и новые парни, вероятно, будут дольше, так что они получат своив конце концов ...

Добавленный пример

Не знаю, как все остальные, но я бы не хотел пытаться придумать что-то подобное (или написать это), используястарый стиль соединения:

SELECT DISTINCT product_zone_map_id, zh.name_english, zh.name_french, zone_id, ad.attribute_value_english AS bullprep_region_type,
        product_zone_type_id, ad.attribute_value_english, language_english, product_code, office_code,
        (
            SELECT attribute_value_english
            FROM presentation p JOIN presentation_details ad USING(presentation_id)
            WHERE dimension_id = 4
              AND object_id = product_zone_map_id
              AND attribute_type = 'BULLPREP PARENT ID'
              AND p.usage_start_date <= TO_TIMESTAMP('2010-05-12', 'yyyy-mm-dd hh24:mi:ss')
              AND (p.usage_end_date >= TO_TIMESTAMP('2010-05-12', 'yyyy-mm-dd hh24:mi:ss') OR p.usage_end_date IS NULL)
        ) AS bullprep_parent_id,
        (
            SELECT attribute_value_english
            FROM presentation p JOIN presentation_details ad USING(presentation_id)
            WHERE dimension_id = 4
              AND object_id = product_zone_map_id
              AND attribute_type = 'BULLPREP GROUP ID'
              AND p.usage_start_date <= TO_TIMESTAMP('2010-05-12', 'yyyy-mm-dd hh24:mi:ss')
              AND (p.usage_end_date >= TO_TIMESTAMP('2010-05-12', 'yyyy-mm-dd hh24:mi:ss') OR p.usage_end_date IS NULL)
        ) AS bullprep_group_id, product_zone_seq
FROM zone z JOIN zone_history zh ON(z.zone_id = zh.zone_id)
     JOIN product_zone_map pzm ON(z.zone_id = pzm.zone_id)
     JOIN product USING(product_id)
     JOIN product_history ph USING(product_id)
     JOIN language_reference USING(language_id)
     LEFT OUTER JOIN product_zone_attribute_details pzad USING(product_zone_map_id)
     LEFT OUTER JOIN attribute_details ad USING(attribute_id)
     JOIN zone_geocode_map USING(zone_id)
     JOIN geocode USING(geocode_id)
WHERE zh.usage_start_date <= TO_TIMESTAMP('2010-05-12', 'yyyy-mm-dd hh24:mi:ss')
  AND (zh.usage_end_date >= TO_TIMESTAMP('2010-05-12', 'yyyy-mm-dd hh24:mi:ss') OR zh.usage_end_date IS NULL)
  AND pzm.usage_start_date <= TO_TIMESTAMP('2010-05-12', 'yyyy-mm-dd hh24:mi:ss')
  AND (pzm.usage_end_date >= TO_TIMESTAMP('2010-05-12', 'yyyy-mm-dd hh24:mi:ss') OR pzm.usage_end_date IS NULL)
  AND (attribute_type = 'BULLPREP REGION TYPE' OR attribute_type IS NULL)
  AND product_id = 2075
ORDER BY product_zone_seq

Answer 2

Я использовал старый синтаксис 18+ лет, но сейчас (~ 2 года) я почти всегда использую новый синтаксис, потому что

• легко читается - я не пропускаю "(+)"
• при «отладке» проще комментировать при объединении в новом синтаксисе, например строка соединения (если написано, конечно, в 1 строку) и поля, выбранные из таблицы. Не проверять условие where для условий соединения
• полное внешнее объединение доступно только в новом синтаксисе (например, больше возможностей в целом)
• отлично подходит для никогда не использующихся функций, например MERGE INTO ... USING ... ON ...

Answer 3

Используйте новый синтаксис. Это более мощный и лаконичный. Это отраслевой стандарт. Это понимают гораздо больше людей, чем старый синтаксис. Это то, что Oracle рекомендует.

Answer 4

Если у вас нет стандарта кодирования, который говорит вам, как это сделать, делайте это так, как вы хотите.

Начните использовать синтаксис стиля JOIN. Тогда вы можете иметь 2 подгруппы, одну, которая предпочитает JOIN USING (a), и одну, которая предпочитает JOIN ON (t1.a = t2.a).

Серьезно, если это доступная языковая функция, и нет стандартного заявления о том, можно ли ее использовать, вы решаете или настаиваете на принятом стандарте кодирования.

Answer 5

Нет никакой разницы в производительности между старым синтаксисом Oracle и новым синтаксисом ANSI по одной очень веской причине.Oracle принимает запросы, написанные в новом синтаксисе, и переписывает их в старый синтаксис перед отправкой оптимизатору.На самом деле очевидно, что Oracle не собирается поддерживать две версии оптимизатора, и просто дешевле сохранить свои инвестиции в существующий синтаксис.

В более ранних версиях Oracle (то есть 9i) были некоторые ошибки в этом процессе, что означало, что некоторые логически эквивалентные запросы выполнялись медленнее, если мы записали их в новом синтаксисе по сравнению со старым.Количество этих ошибок уменьшилось по сравнению с последующими выпусками.

Одним тонким побочным эффектом этого процесса переписывания является то, что может быть сложнее использовать подсказки в новом синтаксисе.Это связано с тем, что в переведенном запросе может отсутствовать необходимая точка привязки, поэтому подсказка теряется.

Таким образом, хотя ясность нового синтаксиса облегчает понимание сложных запросов, может быть проще настроить написанные запросы.в старом синтаксисе.

Answer 6

Я согласен с тем, что сказал @Slokun, и я хотел бы добавить, что со временем разработчики будут все больше и больше разбираться в синтаксисе JOIN, а в меньшей степени - с присоединением предложения WHERE. По мере того, как люди покидают проект и приходят новички, предвзятость будет только больше искажена в сторону современного синтаксиса. Программистам, работающим не с Oracle, будет немного проще взглянуть на код в крайнем случае. В нашем проекте есть сотрудники как SQL Server, так и Oracle, и люди с SQL Server часто смущаются синтаксисом (+). Это также работает в обоих направлениях - если все ваши сотрудники используют синтаксис объединения WHERE, им будет сложнее работать с синтаксисом JOIN.

Всегда полезно расширять кругозор. Изучите новый синтаксис JOIN и мгновенно подтолкните свою карьеру к 21-му веку! Лично я принял сознательное решение изучить синтаксис JOIN здесь в прошлом году или два, и начал подталкивать других к этому, когда я иду. Что тебе терять? Я нашел новый синтаксис более читабельным и гибким.