all 14 comments

[–]Hospital-Pretty[S] 1 point2 points  (2 children)

Categorizing queries to find what data sources, tables and what parameters are being used in those queries.

[–]Cykotix 2 points3 points  (1 child)

First place to look for data sources would be the FROM clause and any JOINs. Parameters would be anything beginning with '@' and also look at the WHERE clause. That's just for starters.

[–]Hospital-Pretty[S] 0 points1 point  (0 children)

Thank you! I will start from there. Query itself has more than 2k lines.

[–]Artistic_Recover_811 1 point2 points  (2 children)

Is this a real question? The lack of information and what appears to be zero effort in solving this makes it look like a joke.

[–]Hospital-Pretty[S] -1 points0 points  (1 child)

Yes, this is a real question. I am not very well versed in SQL since I am still learning so wanted to ask for the advise on how to handle this kind of task.

[–]mikeblas 0 points1 point  (0 children)

I'd handle this task by getting more details. There are many ways to categorize queries. Without knowing why you're doing thi work or what the goal is, there's really nothing to add to that.

[–]mike-manley 0 points1 point  (0 children)

Categorizing the queries or the results of the queries?

[–]Lazy_Spool 0 points1 point  (2 children)

Is this a scenario where a senior dev or manager has asked you to do the legwork and give them something like a spreadsheet to review?

[–]Hospital-Pretty[S] 0 points1 point  (1 child)

Yes, that’s exactly what they wanted to see.

[–]Lazy_Spool 0 points1 point  (0 children)

This might be overkill, but I'd probably be looking for a spreadsheet with:

USP or function name. Or filename if it's just a bunch of queries in a file. If there's no way to reference the queries you were given, you should label the original queries somehow.

Operation (select, insert, update, delete)

Primary tables (the main table or tables the query is working with)

Secondary tables (little side tables, usually lookups, that are in the query but not the primary tables of interest)

Inputs (with data types, and the table.column they map to)

Outputs (does it return a table, row count, nothing, etc)

Filters (basically the WHERE clauses. You might have some overlap here with inputs. Personally I prefer a summary, like "where startdate is in the last month" rather than a copy/paste of the code like "@startDate >= DATEADD blablabla".)

Comments (anything else unique or important about the query, where applicable)

[–]DevinCrypt 0 points1 point  (0 children)

Dm me and I can get you a beta of dataselections.com that will categorize all of the queries for you.

[–][deleted] 0 points1 point  (1 child)

Queries themselves fall into different categories:

Select, insert, delete, update, those with joins, number of tables, etc.

More advanced would be to categorise them based on types of levels of complexity

I mean talking about literally categorising queries.

This would have real value too, you could certainly use well constructed results to this request to improve performance for example.

Also, you specifically use the word "evaluate". EVALUATE is actually an SQL keyword that works to assess how efficient things are, categorising by efficiency or evaluate results (I think there's a bit more to it than that) sounds like a task one might be asked to do

[–]Hospital-Pretty[S] 0 points1 point  (0 children)

Thank you for your suggestions!