Replacing "" from scripts which has table DDLs

Question

HI,
I use an oracle version of Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production.
I have few scripts consisting of DDLs for table. But  almost all CREATE TABLE syntax  consist of double quotes "" for the column name and table name like below example:
After architecture review, we came to know that we need to remove all the double quotes from all scripts for column names and table names making sure other double quote usage are not impacted in any part of those scripts. But doing it manually by going through all scripts/tables seems to be huge effort. So am seeking suggestion if there is any way we can achieve this in a simpler way.
Thanks

Answer 1

After architecture review, we came to know that we need to remove all the double quotes from all scripts for column names and table names making sure other double quote usage are not impacted in any part of those scripts. But doing it manually by going through all scripts/tables seems to be huge effort. So am seeking suggestion if there is any way we can achieve this in a simpler way.
Yes, there are at least two much simpler ways:
1. Replace the architecture review team with people who use logic and reason as the basis for the standards that they adopt.
2. Replace the 'remove all the double quotes' requirement from the standards list.
If you plan to adopt a standard then you should adopt an industry standard. If you use any other standard then there should not only be a rational justification for NOT using the industry standard (in this case Oracle's) but there should also be some rational, and demonstrable, value to the standard that you adopt. I cannot think of any justification for NOT using the Oracle standard not am I aware of any value whatsoever to removing all double quotes from scripts.
In addition, in almost 30 years of working in the field I am not aware of ANY organization that has adopted such a standard.
Oracle both provides, and uses, extensive functionality for creating and using DDL. The DBMS_METADATA package is used by Oracle for both export and import and the standard used by that package is to enclose object names in double quotes. The reasons for this standard have already been stated by others. One example is the possible use of mixed-case for object names. But mixed-case is also used for path names in DIRECTORY objects, TABLESPACE objects, database links and for extracted passwords.
Any extraction of DDL your org does will likely etiher use the DBMS_METADATA package or a tool that follows the Oracle standard.
So your teams 'standard' not only contravenes the industry standard but imparts a substantial penalty in terms of the resources needed to constantly identify and correct the any DDL extracted from your systems.
Here is a trivial example of using the Oracle package to extract DDL for the SCOTT.EMP table.
select dbms_metadata.get_ddl('TABLE', 'EMP', 'SCOTT') from dual
CREATE TABLE "SCOTT"."EMP"
( "EMPNO" NUMBER(4,0),
"ENAME" VARCHAR2(10),
"JOB" VARCHAR2(9),
"MGR" NUMBER(4,0),
"HIREDATE" DATE,
"SAL" NUMBER(7,2),
"COMM" NUMBER(7,2),
"DEPTNO" NUMBER(2,0),
CONSTRAINT "PK_EMP" PRIMARY KEY ("EMPNO")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "USERS" ENABLE,
CONSTRAINT "FK_DEPTNO" FOREIGN KEY ("DEPTNO")
REFERENCES "SCOTT"."DEPT" ("DEPTNO") ENABLE
) SEGMENT CREATION IMMEDIATE
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "USERS"
If this were me I would use ALL of my political capital to fight the battle against this non-sensical 'standard'. There is simply no rhyme or reason for it, it will waste a lot of valuable personal resources and the cost/benefit ratio simply can't justify it.
Those resources would be MUCH better used on other tasks.