使用concat的Oracle查询问题|| 算子

Question

I am trying to query a string as follows,

Currently my Oracle table has around 60 columns. So to query a string for against all columns will be as follows,

Working query:

select * from <table_name> where (col1||col2||col3...||col60) like '%string%'

Not working query:

i have added one more query to get all columns dynamically as below,

select * from <table_name> where (select LISTAGG(COLUMN_NAME, '||') WITHIN GROUP (ORDER BY COLUMN_NAME) from all_tab_columns where TABLE_NAME = '<table_name>' and OWNER = '<owner_name>' and DATA_TYPE != 'CLOB') like '%string%'

sub query :

There is no issue with the below subquery.

select LISTAGG(COLUMN_NAME, '||') WITHIN GROUP (ORDER BY COLUMN_NAME) from all_tab_columns where TABLE_NAME = '<table_name>' and OWNER = '<owner_name>' and DATA_TYPE != 'CLOB'

Where the subquery is returning output like in the working query.

I am thinking that the oracle taking the "||" concat operator only when it is hardcoding it.

Could you please help me on that?

Answer 1

Here is how I would solve your problem in a way that would scale.

CREATE OR REPLACE VIEW COLUMN_SEARCH AS

SELECT ID, COL1 AS COL
FROM TABLENAME

UNION ALL

SELECT ID, COL2 AS COL
FROM TABLENAME

UNION ALL

SELECT ID, COL3 AS COL
FROM TABLENAME

UNION ALL

SELECT ID, COL4 AS COL
FROM TABLENAME

UNION ALL

--- 

SELECT ID, COLN AS COL
FROM TABLENAME

Now with this view your query is just

SELECT TABLENAME.*
FROM TABLENAME
JOIN COLUMN_SEARCH ON TABLENAME.ID = COLUMN_SEARCH.ID
WHERE COLUMN_SEARCH.COL = 'string'

If you need this to be dynamic then just update view everytime there is a new column added.

If it is running slow then just make an index on ID, COL in the view.

---

Update based on comments

I want to add a some comments about using dynamic SQL to solve this problem. You can use dynamic SQL to solve this problem but it would be a bad idea. ( For those that don't know -- creating the query dynamically from meta data about the columns everytime you run the query would be using dynamic SQL )

Here is why I don't recommend it:

1. Dynamic SQL is really hard to maintain -- it is (by definition) more complicated than non dynamic SQL and it never looks very much the query you are really trying to run. While it seems like it would make maintenance easier "Everytime I add a column it just automatically adds in in - bim-bamb-boom!" In fact, I've found everytime you add a column it is better to make a choice "Do I want to add this in." Sometimes it helps to automatically add it but many times it will break the system.

2. Dynamic SQL breaks optimization -- SQL platforms have decades of optimization built into their compilers, they do an amazing job. Because dynamic SQL can't be per-compiled and cached you lose a lot on performance in addition to the time it takes to create the dynamic SQL.

3. Dynamic SQL can't easily be tweaked and tuned -- A lot of what a DBA does is look at how data models are being used and then add indexes, partitions, materialized queries and other tuning to make the system run quickly. It is much harder to do this kind of tuning on dynamic SQL (but not impossible).

4. Dynamic SQL is a bad code smell -- This is more subtle and may not apply to this particular question but needs to be said -- if you are using dynamic sql it is probably an indication you did something wrong with your data model or you are using the wrong tool. There are a number of "nosql" systems out there that might be better suited for solving your particular data issue.