Por que o desenvolvedor SQL sugere um formato diferente para um procedimento que funcione?

Sobre o motivo de sugerir um formato diferente quando o código já funciona, é claro que é possível ter um código mal formatado que funcione, então, em princípio, não há razão para você não considerar melhorias de layout ou refatoração que possam tornar o código mais robusto, eficiente ou mais fácil de manter.

No entanto, nomes com aspas duplas são uma prática ruim porque ocultam erros de nomenclatura e forçam você a especificar maiúsculas/minúsculas, e o resultado é menos legível que o original. Eles são realmente um recurso de portabilidade para uso com aplicativos de terceiros que possuem nomes de tabelas estranhos . Os geradores de código tendem a colocar aspas duplas em tudo porque é mais fácil fazer isso do que detectar se eles são realmente necessários em cada caso. Não há nenhuma maneira que

from "C##ELLIE"."CPP" "A1"

é algum tipo de melhoria

from cpp

exceto talvez pelo uso de um alias de tabela. É uma boa ideia dar um alias à tabela (sem aspas!) e usá-lo ao se referir a colunas. Mas "A1"(ou mesmo a1) é o tipo de alias de tabela que apenas um computador imaginaria. Seria muito melhor usar um alias que fosse algum tipo de abreviação do nome da tabela, talvez neste caso c. Imagine se você estivesse juntando seis mesas - agora qual é a3? Ah certo, isso ORDER_DETAILS. (Embora, neste caso, o nome da tabela seja tão curto que não faça sentido usá-lo como alias.) Então,

SELECT "A1"."CPP" "CPP"
FROM   "C##ELLIE"."CPP" "A1"

seria muito melhor como apenas

SELECT c.cpp
FROM   cpp c

(Eu também colocaria em letras minúsculas porque não é 1974 e meu editor destaca palavras-chave de idioma usando cores e negrito, mas vamos deixar isso para lá.)

Codificar nomes de esquema é uma prática ruim porque é na melhor das hipóteses redundante (o objeto está no esquema em que você já está trabalhando, então não adiciona nada, exceto complicações desnecessárias) ou pior, limita a portabilidade (se você renomear o esquema ou mover o código que você ' vou ter que passar por isso limpando as referências codificadas).

Tenho certeza de que este é um recurso inteligente que significa bem, mas neste caso não é um bom conselho.

A1é o alias para a tabela"C##ELLIE"."CPP"

o procedimento é o mesmo, mas assim você e a oracle sabem a qual esquema a tabela cpp pertence também.

Adicional você também deve adicionar um comentário o que o procedimento faz, se você voltar em 3 anos é mais simples saber, qual esquema você usou e para que serve

Aqui está uma demonstração do que há de errado em usar aspas duplas em nomes de objetos. Leia cada comando com atenção e preste atenção à distinção entre maiúsculas e minúsculas dos nomes das tabelas, entre aspas e sem aspas.

SQL> create table test_table_1 (dob date);

Table created.

SQL> create table "test_table_2" ("dob" date);

Table created.

SQL> select * from test_table_1;

no rows selected

SQL> select * from test_table_2;
select * from test_table_2
              *
ERROR at line 1:
ORA-00942: table or view does not exist


SQL> select * from "test_table_2";

no rows selected

SQL> 
SQL> select table_name
  2  from user_tables
  3  where upper(table_name) like 'TEST_TABLE%'
  4  order by table_name;

TABLE_NAME
--------------------------------------------------------------------------------
TEST_TABLE_1
test_table_2

2 rows selected.

SQL> 
SQL> drop table test_table_1;

Table dropped.

SQL> drop table test_table_2;
drop table test_table_2
           *
ERROR at line 1:
ORA-00942: table or view does not exist


SQL> drop table "test_table_2";

Table dropped.

SQL> --
SQL> spo off

Eu provavelmente faria uma recomendação disso para o seu código:

...
    CURSOR c_data IS
        SELECT c.cpp,
               c.rfu1,
               c.rfu2,
               c.mean_rfu,
               c.charge_ph7_4,
               c.hydropathy
        FROM   cpp c
        ORDER BY LENGTH(c.cpp);
...

Estamos usando apenas uma tabela/exibição, cppportanto, o alias não é estritamente necessário, mas seria útil se, no futuro, outra tabela fosse adicionada a essa consulta.

Particularmente com mais de 2 consultas de tabela, se os nomes no SELECT não forem totalmente qualificados (mencionar um nome de tabela ou alias antes do nome da coluna), as consultas poderão ser interrompidas se forem adicionadas colunas a tabelas que tenham o mesmo nome de outra coluna em outra tabela:

PersonTable: id, name, status, addressid
AddressTable id, street

--this is ok for now
SELECT name, status, street FROM person INNER JOIN street ON person.addressid = address.id

Se adicionarmos uma coluna Status ao Address, a consulta acima falhará porque agora é ambígua. Adicionar uma coluna que causa esse tipo de problema não fará com que o banco de dados anuncie "Eu adicionei, mas, a propósito, todas essas outras consultas em todo o seu esquema e sistemas dependentes agora vão falhar" - você só terá que encontrar essas consultas com falha por meio de testes. Ou clientes reclamando ;)

Se tivéssemos qualificado totalmente:

SELECT 
  person.name, 
  person.status, 
  address.street 
FROM 
  person 
  INNER JOIN adress a ON person.addressid = address.id

Continuaria funcionando..

Repetir o nome da tabela com as colunas é um pouco tedioso e prolixo. Usar um nome mais curto não apenas melhora a legibilidade.

SELECT 
  p.name, 
  p.status, 
  a.street 
FROM 
  person p
  INNER JOIN address a ON p.addressid = a.id

..mas lembra-nos psicologicamente que podemos juntar as tabelas várias vezes por diferentes razões:

 SELECT 
  p.name, 
  p.status, 
  a_work.street as workstreet,
  a_home.street as homestreet
FROM 
  person p
  INNER JOIN address a_work ON p.work_addressid = a.id --note, i've silently upgraded Person here to track two addresses
  INNER JOIN address a_home ON p.home_addressid = a.id

Em suma, o SQLDeveloper está tentando fazer uma coisa boa aqui, pois está se movendo em direção ao bom senso de:

• Dê às suas tabelas um alias sensível, legível e contextualmente relevante
• Sempre qualifique totalmente seus nomes de coluna com o alias

Onde está caindo é:

• É escolher um nome de alias porcaria A1, que não ajuda você a lembrar de nada; não é por acaso que escolhi ppor pessoa e apor endereço, como tenho certeza que você pode apreciar. Se houvesse um partido e um projeto para participar, eu poderia usar per, proe par. Eu evitaria porque Pessoa, Partido e prProjeto têm consoantes iniciais relevantes na palavra, então não grita "é um alias para PRoject" tão obviamente quanto o uso de três letras (mas eu certamente aceitaria você argumentando , e se você quiser salvar algumas teclas :))prprpepapr
• Está colocando aspas duplas cegamente em todos os lugares, provavelmente "por segurança", mas também porque é o caminho de menor resistência - é muito mais fácil codificar uma lógica de adicionar aspas cegamente builder.addcolumn( '"' || alias_name || '"."' || col_name || '",')do que inspecionar um nome de coluna e ver se pode precisar citando e apenas adicione-os se necessário. Infelizmente, isso significa que o código acaba em uma bagunça ilegível de "todos os lugares.
• .. e começando a partir de que "apenas aspas cegamente tudo" é "e, em seguida, faça todos os identificadores ALL CAPS, porque agora os nomes de tabela/coluna não diferenciam maiúsculas de minúsculas. Tudo SELECT pErSon.NaME ...bem; mesmo que a tabela.coluna seja apenas PESSOA. NAME não faz distinção entre maiúsculas e minúsculas. Mas quando adicionamos aspas cegamente, temos que colocar os nomes em letras maiúsculas, porque adicionar as aspas faz com que sejam tratadas com distinção entre maiúsculas e minúsculas SELECT "pErSon"."NaME"! então seus identificadores de letras minúsculas cuidadosamente escritos e legíveis* desapareceram.

SQLDeveloper realmente poderia ir para toda essa introspecção e lógica de descobrir o que precisava ser citado, seja por causa de caracteres funky, espaços, case sens etc. citá-lo", "apenas maiúsculo" e "apenas crie um alias que seja uma coisa única aleatória / incremental" e isso infelizmente é uma recomendação ruim, embora o espírito de parte do que está tentando seja uma boa ideia

_{*quando crianças aprendemos letras minúsculas antes de maiúsculas; somos sempre mais rápidos a ler frases em minúsculas do que em maiúsculas}