- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
Declare
alph Varchar2(26) := 'ABCDEFGHIJKLMNOPQRSTUVWXYZ';
ch Varchar2(1);
Begin
dbms_output.put_line('Starting search: ' || srch);
For i In 1..26 Loop
Select Substr(alph,i,1) Into ch From dual;
with
v_tab_col as (
Select '"' || c.Table_Name || '"' As Table_Name,
'"' || c.Column_Name || '"' As Column_Name,
'"' || c.Owner || '"' As Owner,
Row_Number() Over(Partition By c.Owner, c.Table_Name Order By c.Column_Id) As Rn
From Dba_Tab_Columns c, Dba_Objects o
Where Data_Type In ('CHAR', 'VARCHAR2')
And c.Table_Name = o.Object_Name
And o.Object_Type = 'TABLE'
And o.Owner = c.Owner
And o.object_name Like ch || '%' -- checking by letter
Циклическая выборка таблиц, начинающихся на букву алфавита, в каждом следующем прогоне берется следующая.
Follow us!
Для мускула нонрмального нет
зачем вообще ходить по каталогу и искать текстовые колонки?
почему нужно именно цикл по буквам, почему одним запросом это всё нельзя сделать?
там дальше в коде жирнющий поиск ключевого слова по содержимому таблиц (тоже редкостный ад) путем генерации поисковых запросов ко всем варчарным столбцам каждой отдельной таблицы. в аутпут уходят таблицы, где что-нибудь нашлось (я, в принципе, могу полный текст привести). данных дохрена, если скрипт грохнется (а он грохнулся, например на таблице со слишком большим количеством столбцов - сгенеренный запрос в 4000 не поместился), то хочется знать, где это произошло. а так - не одна здоровая выборка, а 26 поменьше, понятно, с какой точки перезапускать, в случае чего.
это либо моё незнание методов поиска в содержимом таблиц, либо одно из двух.
на что только не пойдут люди, чтобы ректально решить какие-то ректальные бизнес-задачи
из того, что ты рассказал, я могу сделать вывод, что это пиздец одноразовая задача - тебе принесли чужую базу и ты не хочешь разбираться в схеме, а хочешь погрепать ну где же хранится название чего-либо
я бы посоветовал сделать текстовый дамп и искать грепом, греп хорошо ищет, поверь
если говорить о тонкостях реализации, чего ты сейчас тут понаписал
- массив букв норм, см. следующий пункт
- ..26 не норм, есть же length
- ch varchar2 не норм, есть же char(1)
- like ch || '%' ваще не норм, есть же substr(foo, 1, 1), гораздо быстрее будет работать (а ты уповаешь, что оптимизатор смилуется и сделает этот субстр за тебя)
- dba_objects не норм, есть же dba_tables (открыл первую попавшуюся под руки базу - count(*) в dba_objects - 71268, count(*) в dba_tables - 2491)
- Да И Вообще Этот Стиль Не Норм - sql прекрасно смотрится в ловер кейсе, но это моё имхо
- на скорость исполнения одноразовой задачи тебе явно пофиг, поэтому я не буду наматывать сопли на кулак про смесь sql и pl/sql, bulk collect - это не сюда
ну и
> поиск ключевого слова ... ко всем варчарным столбцам
ты ведь построил фулл текст индекс?
я бы хотел сказать эластик/сфинкс, но я уже выше предложил греп
Ты удивишься тому, что он напишет ....
- length умнее, не спорю.
- я такой джуниор, что принципиального смысла в char не вижу, варчар2 по привычке.
- принято, благодарю.
- аналогично, не подумалось.
Чем тебе кэмелкейс навредил? от капса, да, глаза кровоточат, а кэмел вроде норм.
а про индекс придется rtfm.
-
насколько она прирастает за сутки/неделю?
как часто надо искать?
если я правильно посмотрел (по sys.ts$), то всего 500 метров.
многоразовая - делаешь один раз одну таблицу один раз её наполняешь
строишь один фул текст индекс
профит
там выше что-то негативное в сторону грепа высказывали. why?
2) создай новую таблицу в другом месте. у тебя же оракл, дблинк есть в стандарте.
1. Если нужен поиск по ключевым словам, то какого хрена ключевые слова до сих пор не вынесены в отдельную таблицу?
2. Нахуя создавать таблицу с таким количеством столбцов? Упрощать схему не учили? Или тупо набрали кодомакак, которым пофиг на сложность и поддержку?
3. Самое главное. Дебаггер в SQL в принципе невозможен, т.к. сам язык предназначен для сокрытия внутренних процессов. Да, есть разной подробности логи, есть сообщения об ошибках, есть explain. Но дебаггера там никогда не было.
Когда ты перестанешь возиться с наколенным игрушечным дерьмом типа MySQL, для тебя откроется огромный новый мир настоящих СУБД:
Да, давайте говорить сейчас о PG/SQL, T/SQL функциях! Типа, если мы можем по ним step through, то это есть истинный и православный дебаггер, ага.
Эскуэльщики вообще знают, что такое дебаггер? Если я в селект напихаю 100500 джойнов и оно будет тормозить, как я это буду дебажить?
Не помогает?
Вообще в современном ПО много чего скрыто от посторонних глаз. Декодер графических файлов вроде GIF или JPEG не выдаст подробности, на чём именно он споткнулся при попытке разобрать повреждённый файл. Браузер не скажет, как именно он разбирал страницу, только выдаст в отладчике коды ошибок и номера строк, на которых он споткнулся.
SQL-запрос нельзя оттрассировать по шагам, в отличие от программы на Бейсике/Си/Паскале и даже на JS, потому что SQL не является вполне императивным (хотя и допускает императивные действия в подпрограммах). Да и операции, выполняемые СУБД в данный момент, могут относиться не только к нашему запросу, но и к другим, потому что они могут быть связаны транзакциями. Так что если их открыть, увидим слишком много лишнего.
Самое главное, что СУБД не обязана повторяться: один и тот же запрос при первом выполнении и при повторах может исполняться по разной схеме. Возникает вопрос, нужна ли пошаговая отладка, если в боевых условиях запрос всё равно будет исполняться по-другому.
Спасёт только разбиение задачи на части и написание тестов для каждого участка.
ну и с запросами всё так же абсолютно
если писать хитровыебанный запрос на 5 пейдждаунов для хитровыебанного отчета, то в нормальных субд есть отличная вещь with, которая позволяет емко и просто описывать каждый шаг - и всегда можно вставить на нужном месте select * from stepX и посмотреть, что же насобирал запрос до этого места, всё ли хорошо
однако, этому тоже есть цена - когда, например, оракловый оптимизатор видит такую кучу with, он начинает материализовывать промежуточные результаты когда ему угодно (или наоборот, не материализовывать, но слава богу есть хинт) и можно прилично потерять в скорости, если внутри каждого блока будет по ляму неиндексированных записей под хеш джойн
в какой то момент проект, в котором оказываются востребованными такие пиздецовые приемчики, должен дозреть до того, что его статистика требует предаггрегации в соответствии с бизнес-потребностями - вплоть до олап - в этом случае разработчик разносит задачу на части распределенные по времени и способу хранения, что тоже соответствует "разбиение задачи на части"
Так точно.
> я в селект напихаю 100500 джойнов и оно будет тормозить
Тогда тебе нужен профайлер...
Для мускула нормального тоже нет, согласен.
select * from all_all_tables
where regexp_like(table_name,'^[A-Z]{1}.')
order by table_name
Чем не устраивает?
Data_Type In ('CHAR', 'VARCHAR2') - это чтоли?
это не поиск в содержимом ....
я вижу только поиск таблиц, начинающихся на буквы A-Z с полями CHAR или VARCHAR2....
ps. нахера столько многозначительных многоточий, друг?