Oracle 구문 - 기존 구문과 새 구문 중 하나를 선택해야 합니까?

Oracle 구문 - 기존 구문과 새 구문 중 하나를 선택해야 합니까?

저는 약 8명의 개발자들로 구성된 팀에서 약 100만 라인의 소스를 가진 코드 베이스에서 일하고 있습니다.우리의 코드는 기본적으로 Oracle 데이터베이스를 사용하는 애플리케이션이지만, 코드는 시간이 지남에 따라 발전했습니다(90년대 중반의 소스 코드가 많이 있습니다!).

오라클 데이터베이스 쿼리에 사용하는 구문에 대해 팀 간에 분쟁이 발생했습니다.현재 대부분의 쿼리는 조인에 "구" 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는 기존 쿼리를 변경할 시간이 없다는 것에 동의한다고 말합니다. 우리는 여기서 작성하는 코드에 대해 "새로운" 구문을 채택해야 합니다.그들은 개발자들이 한 번에 하나의 쿼리만 실제로 보고, 두 구문을 모두 알고 있는 한, 미래의 어느 시점에서 더 이상 사용되지 않을 수도 있는 기존 구문을 엄격하게 고수함으로써 얻을 수 있는 것은 아무것도 없다고 말합니다.

나의 충성심이 어느 그룹에 있는지 선언하지 않고, 나는 공정한 관찰자들의 의견을 듣는 것에 관심이 있습니다 - 그러니 경기를 시작합시다!

마틴.

추신. 저는 단지 노골적으로 질문 사항을 쫓는 것으로 비치지 않기 위해 이것을 커뮤니티 위키로 만들었습니다...

여기도 비슷하지만, 개발자들이 많지도 않고, 오래된 코드도 아닙니다.저는 더 새로운 것을 사용하고 있고, 나이든 남자들은 더 오래된 스타일을 사용하고 있습니다. 하지만 우리는 서로가 무엇을 하려고 하는지 알고 있습니다.

개인적으로, 저는 개인 개발자들이 사용하기 쉬운 어떤 스타일이든 상관없다고 생각합니다.벤치마크를 실행하여 하나가 다른 하나보다 빠르다는 것(예: 상당한 차이가 있음)을 확인하고, 새로운 고객과 기존 고객 모두가 표시된 쿼리를 읽고 이해할 수 있는 경우가 아니라면, 벤치마크를 변경할 필요가 없습니다.

투표는 것은구문을 입니다.JOIN모래땅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

저는 18년 이상 오래된 구문을 사용했지만, 지금은 (~2년) 거의 항상 새로운 구문을 사용합니다, 왜냐하면

• 쉬운 읽기 - 나는 놓치지 마세요 (+)
• 'join'이 새 구문에서 조인 시 주석을 추가하는 것이 더 쉽습니다. 예를 들어 조인 줄(물론 한 줄에 작성된 경우)과 테이블에서 선택된 필드입니다.조인 조건에 대한 where 절을 확인할 수 없습니다.
• 새 구문에서만 사용할 수 있는 전체 외부 조인(예: 일반적으로 더 많은 기능)
• 예를 들어 ...에 병합하는 것과 같은 기능이 없는 경우에는 적합합니다.사용 중...ON...

방법을 알려주는 코딩 표준이 없으면 원하는 대로 하십시오.

JOIN 스타일 구문 사용을 시작합니다.그런 다음 (a)를 사용하여 조인을 선호하는 부분군과 조인을 선호하는 부분군(t1.a=t2.a)을 가질 수 있습니다.

진지하게, 만약 그것이 사용 가능한 언어 기능이고 사용해도 되는지, 사용자가 결정하거나 채택된 코딩 표준을 추진해도 되는지에 대한 기준이 없다면.

새 구문을 사용합니다.더 강력하고 간결합니다.업계 표준입니다.그것은 오래된 구문보다 더 많은 사람들에 의해 이해됩니다.이것이 Oracle이 권장하는 사항입니다.

저는 @Slokun이 말한 것에 동의하며, 시간이 지남에 따라 개발자들은 JOIN 구문에 점점 더 익숙해질 것이고 WHERE 절의 조인에 덜 익숙해질 것이라는 것을 덧붙이고 싶습니다.사람들이 프로젝트를 떠나고 새로운 사람들이 도착하면, 편향은 현대 구문에 더 치우칠 뿐입니다.오라클이 아닌 DB 프로그래머들이 코드를 쉽게 볼 수 있게 해줄 것입니다.우리 프로젝트에는 SQL Server와 Oracle 직원이 모두 있으며 SQL Server 사용자는 종종 (+) 구문으로 혼동됩니다.직원들이 WHERE join 구문을 사용하는 것이 전부라면 JOIN 구문을 사용하는 데 어려움을 겪을 수도 있습니다.

시야를 넓히는 것은 항상 이익입니다.새로운 JOIN 구문을 배우고 21세기를 향한 당신의 경력을 즉시 가속화하세요!개인적으로, 저는 지난 1~2년 동안 여기서 JOIN 구문을 배우기로 의식적으로 결정했고, 제가 가는 동안 다른 사람들을 설득하기 시작했습니다.잃을 것이 있습니까?저는 새로운 구문이 훨씬 더 읽기 쉽고 유연하다는 것을 알게 되었습니다.

이전 Oracle 구문과 새 ANSI 구문 사이에는 성능 차이가 없습니다. 한 가지 이유가 있습니다.Oracle은 새 구문으로 작성된 쿼리를 가져와 Optimizer에 제출하기 전에 이전 구문으로 다시 씁니다.Oracle은 두 가지 버전의 Optimizer를 지원하지 않을 것이며 기존 구문에 대한 투자를 유지하는 것이 더 저렴합니다.

이전 버전의 Oracle(즉, 9i)에서는 이 프로세스에 버그가 몇 가지 있었습니다. 즉, 이전 버전에 비해 새로운 구문으로 쿼리를 작성하면 논리적으로 동등한 쿼리가 실행되는 속도가 느려졌습니다.이러한 버그는 이후 릴리스에 비해 수가 감소했습니다.

이 재작성 프로세스의 미묘한 부작용 중 하나는 새로운 구문에 힌트를 사용하는 것이 더 어려울 수 있다는 것입니다.이는 변환된 쿼리에 필요한 앵커 포인트가 부족할 수 있으므로 힌트가 "잃어버림"되기 때문입니다.

따라서 새로운 구문의 명확성을 통해 복잡한 쿼리를 쉽게 이해할 수 있지만 이전 구문으로 작성된 쿼리를 조정하는 것이 더 쉬울 수 있습니다.

언급URL : https://stackoverflow.com/questions/2821854/oracle-syntax-should-we-have-to-choose-between-the-old-and-the-new