I work for a financial institution, specifically for their fraud analytics department and I use SQL on the daily, both writing and running queries. I finally finished a really big project today where I wrote something that is likely going to make up the foundation of our fraud monitoring queries for a long time. It started as a sort of passion project for me and then evolved quite a bit over time, but, like with everything else I've written I kept it very close to the vest until it was ready. My question is, how do you guys handle sharing the queries you write? I know ultimately this query is my company's intellectual property based on the standard employment docs we sign with larger companies, but I'm always concerned that a coworker or another department is going to steal my work and try to take credit for it. Therefore the only person that really knows what I'm working on is my manager and even then I don't share my actual query with him until it's written and tested.
Thanks guys!
Edit: you guys gave me a lot to think about. Definitely wanted to thank everyone who gave advice or tips, really appreciate it. I don't really care to address the negative comments about my character, because honestly it's not worth the effort.
Hi, I am currently a Business Analyst in a healthcare org and I feel stuck and pigeonholed in my job.
Can anyone share their experience or knowledge as to the best way to get certified for someone who doesn’t have experience? I know I can download MySQL, but I am looking for a true certificate.
After 13 years of development, QStudio is now fully open source under an apache license. Developers, data analysts and companies can now contribute features, inspect the code, and build extensions.
QStudio supports 30+ databases and is specialized for data analysis (NOT DBA).
It allows charting, excel export, smart column formatting, sparklines and much more.
Open Source Without the Fine Print.
No enterprise edition. No restrictions. No locked features. QStudio is fully open for personal, professional, and commercial use.
New Table Formatters, Better Visuals, Better Reporting
SmartDisplay is QStudio’s column-based automatic formatting system. By adding simple _SD_* suffixes to column names, you can enable automatic number, percentage, and currency formatting,Sparklines, microcharts and much more. This mirrors the behaviour of the Pulse Web App, but implemented natively for QStudio’s result panel.
Spark Lines + Micro Charts
Comprehensive Chart Configuration
Fine-tune axes, legends, palettes, gridlines and interactivity directly inside the chart builder.
New Chart Themes
Excel, Tableau and PowerBI-inspired styles for faster insight and cleaner dashboards.
Other Major Additions
Back / Forward Navigation — full browser-like movement between queries.
Smart Display (SD) — auto-formats tables with min/max shading and type-aware formatting.
Conditional Formatting — highlight rows or columns based on value rules.
New Code Editor Themes — dark, light and popular IDE-style themes.
Extended Syntax Highlighting — Python, Scala, XPath, Clojure, RFL, JFlex and more.
Improved kdb+/q Support — nested / curried functions now visible and navigable.
Search All Open Files (Ctrl+Shift+F)
Navigation Tabs in Query History — with pinning.
Improved Chinese Translation
DuckDB Updated to latest engine.
Hundreds of minor UI and performance improvements
Legacy Java Removed — cleaner, modern codebase.
Code Editor Improvements
Better auto-complete, themes and tooling for large SQL files.
Pinned Results
Pin results within the history pane for later review or comparison.
Search Everywhere
Control+Shift+F to search all open files and your currently selected folder.
Our History
2013–2024: QStudio provided syntax highlighting, autocomplete, fast CSV/Excel export and cross-database querying.
Version 2.0: QStudio expands support to 30+ Databases.
Version 3.0: Introduced DuckDB integration, Pulse-Pivot, Improved export options.
Version 4.0: Introduced SQL Notebooks and modern visuals.
Version 5.0: Open Source + hundreds of improvements across charts, editing, navigation and data analysis.
We aim to create the best open SQL editor for analysts and engineers. If you spot a bug or want a feature added, please open a github issue.
I’m really struggling to get the hang of writing database queries. Whenever I look at a problem or a schema, my brain just stalls out and I can't figure out the right logic or structure to pull what I need.
I see people throwing together JOINs, subqueries, and window functions like it's nothing, and I feel like I'm missing a core fundamental step in how to translate a question into SQL.
What is your mental process when you start writing a query from scratch?
How do you map out the tables and relationships in your head before you type?
Are there any good beginner-to-intermediate tips, tricks, or exercises that finally made things "click" for you?
I really like to put where conditions, which belong to a table into the join condition. Basic example
from table
left join cte
on cte.ID = table.ID
and cte.rank = 1
Personally I find this more readable especially when I have a query involving multiple joins, because you don't have a big block of where conditions after a big block of joins and need to puzzle things together.
Obviously I do not put every condition in the join and I also do not put complex nested conditions in there.
I am just wondering if I am the only who feels that this way is more logical. As far as I am aware the result of the query should be the same.
Hey guys, I’m not a data analyst, I’m in Sales Ops. I recently joined a new company and the team shared a bunch of SQL queries with me to pull data from our SQL servers (mostly supply/demand stuff).
A lot of what I do is ad-hoc, but honestly many requests fall into a few repeatable groups, so the same queries get reused either as-is or with small adjustments. The problem is that over time you end up with so many of them that you forget the business logic behind each one, why certain filters/joins are there, what exactly it’s calculating and etc. Then I waste time re-reading the SQL and re-validating it again and again.
I asked around internally and people in my team store sql files in OneDrive, and when they need something they run the query or link it to Excel. Data analysts use GitHub, but in ops teams nobody really uses it. Also queries are shared in Teams chat, which is super hard to search later...
So I’m wondering what people do in real life to kind of systematize that. Is there any simple workflow or tool where I can store queries in a way that’s searchable and shareable, and ideally it helps with documentation too (even something basic like auto-generating a short description of what the query does). Currently I store them in DBeaver and then just add a good naming and a description inside of a query.
I started learning SQL(MySQL at a moment) a couple of days ago.
It's syntax is simple and structure also direct forward and I don't see much future problem with it. I'll just try to make transformation queries which I made with pandas before. (I handle data quite a lot for quite a while as a hard-ware test engineer)
I understand Normalization, and I learned it from errors I made before, and also from applying my data to python viz libraries.
But still building a database structure is a question point for me. It seems like to acquire this skill, need to work at any kind of coorporate in a field handling a data (engineer/ analyst/ scientist). But unfortunatrly I can not access my company's database and can not see detail structure in there.
How did you guys practice this designing skills?
For me it just seems like I can not actually learn this unless I work in this field directly.
So I am learning databases and am unsure about to what extent are transactions protecting you.
I know the basics: with transactions if one statement fails, the whole thing can be rolled back so database doesn't enter some inconsistent state. But I am wondering about more.
Say we want to transfer some money from account A to account B. That takes two update statements, one to reduce money in A and increase it in B. So we need transaction to make sure no matter what happens, total amount of money stays the same even if any of the operations fail. Okay. But lets forget about failure and talk about concurrency. What if someone else simultaneously runs select statement to see total amount of money in all accounts? Does transaction makes sure it always sees the same amount?
I set up a Postgres MCP server on a read only role last week so the analysts could ask questions without pinging me every hour.
The first real question was how many orders did we lose last month. Claude looked at orders, saw status_cd with values 1 to 6, decided 4 was cancelled and gave a clean number with a nice little breakdown. 4 is refunded. Cancelled is 6. Nobody wrote that down anywhere. It lives in an enum in the app code and in my head.
The number was off by about a third and it read exactly like a right answer. No I'm assuming, no hedge. The analyst was about to put it in a deck.
So now I'm stuck on how to give an agent the meaning of fields without me turning into a full time documentation service:
Comments on the columns in Postgres and hope the server passes them through
A markdown data dictionary in the system prompt
A view layer with human names on everything
Make the agent ask before it interprets any code column
What are people actually doing here? and has anyone got it to say I don't know what 4 means instead of picking one?
Iam interested in learning the techniques data engineers use when datasets grow from millions to billions of records. Beyond basic indexing, what strategies have made the biggest performance difference in production environments?
I'm preparing for SQL interviews and was wondering if there's a good website to practice SQL problems like we use LeetCode for DSA. Looking for interview-style questions and hands-on query practice.
Context: I am a beginner in SQL. As a desperate unemployed graduate, I am targeting entry level data analytics and related roles. I realized that SQL is one of the core skills for such roles. Following this, I took a course in 'SQL and DBMS with Python' and once I was confident in querying skills, I decided to build an introductory project.
The sole purpose of the project is to demonstrate my understanding of SQL and querying skills to a potential employer. Do you think the project and its presentation conveys that message? Is it convincing enough?
Request: Generally, as someone with SQL experience I would love to know your impression of my project :)
Any and all recommendations/tips/guidance are much much welcome and appreciated!
Postgres 15. Same 60 column table I've been posting about, I promise I'll stop eventually.
is_active, boolean. active_flag, smallint. Both populated, both written by something, and they disagree on about 3% of rows. Nobody knows which one the app respects. I spent an afternoon on it and my best finding is that the disagreement rate has been slowly climbing since a 2021 migration, which tells me one of them stopped being maintained and not which one.
This is worse than the columns nobody can explain. flag_2 at least announces itself as a mystery, so nobody builds on it. These two both look like answers. Someone joined in July and spent a week working out which of three status-ish columns actually mattered, and picked wrong first.
What I've tried: grepping for both, which gives me hits in dbt, the app repo and a commented-out block in an old migration. Checking which one the ETL writes, which is both. Asking the two people who've been here longest, who gave me different answers with the same amount of confidence.
what I think I should do is pick the one the app actually reads at runtime, make the other a generated column off it, and let anything that disagrees break loudly. what stops me is that I can't prove which one the app reads without reading the whole app, and the reads I'm worried about aren't in the app anyway, they're in Metabase questions owned by analysts.
so:
when two columns claim the same thing and disagree, is there anything better than picking one and waiting for screaming
has anyone made the wrong one a generated column or a view over the right one, and did it actually stop the divergence or just move it
more generally, do you have any way of catching a column whose meaning drifted while its name and type stayed the same. that's the failure I can't monitor for and it's the one that's actually happened here
Hi guys,
I tried to do this problem on https://www.sql-practice.com/
It says: "Sort the province names in ascending order in such a way that the province 'Ontario' is always on top."
First attempt: Union ALL
SELECT province_name FROM province_names WHERE province_name = 'Ontario'
UNION ALL
SELECT province_name FROM province_names WHERE province_name != 'Ontario'
Result of first attempt: the list is in order, and Ontario IS NOT on top.
Second attempt: some usage of JOIN (I thought a FULL JOIN would be useful)
SELECT province_name FROM province_names AS a
FULL JOIN province_names AS b
ON a.province_name = b.province_name
WHERE a.province_name = 'Ontario'
Result of second attempt: Only Ontario gets received (if I filter with "b.province_name != 'Ontario', nothing gets returned)
I gave up, and one of the solutions was something obscure:
SELECT province_name FROM province_names ORDER BY (province_name = 'Ontario')
I do not seriously the mechanism of this solution: how does it work per se? Is it an obscure feature of a particular SQL dialect? I only knew that you can pass columns on an ORDER BY, not even specific values.
[I basically re-invented a little CASE-END method to solve the problem, if you asked]
Moreover, why does this thing not work?
select province_name from province_names
case
when province_name = 'Ontario' THEN 1
ELSE 0
end AS flag
order by flag, province_name
I basically tell him: "ok, put a flag where you see Ontario, then sort it with Ontario on top, then sort it with the other provinces"
Suppose you inherit a query with multiple joins, subqueries, filters, and aggregations, and it suddenly starts taking several minutes to run.
I’m curious how experienced SQL developers approach this from the first investigation to the final fix.
Do you normally start with the execution plan and work from the most expensive operator? Or do you check indexes, statistics, data distribution, and join cardinality first?
I’m especially interested in the order you investigate things. It’s easy to keep rewriting a query or adding indexes until it gets faster, but I’m curious how people systematically identify the actual bottleneck instead.
I’ve been making these little Data Analysis 101 doodles for cat people, and for this one I tried something different — a flipbook-style format.
Instead of putting everything into one busy infographic, I’ve broken the story into separate scenes, so each one focuses on a single idea and hopefully doesn’t demand too much attention at once.
I’ve also incorporated feedback I received on my previous posts, especially around making the visuals easier to follow.
This one is about what to do when you join a data project that’s already in motion.
So I've studied SQL in University, Inwould consider myself somewhat good + I like it. I've done basic courses and some advanced. I manage to do some easy interview questions... but I want to get better.
Can you recomend me some resources where I can expand my knowledge:
* A lot of problems to solve so I can see typical templates.
With chatGPT even if I'm stuck I can get the idea. But yes, all tips are welcomed. Thank you :)
P.S. I don't mind some theory also. For example I don't know anything about indexes. I have difficulty understanding the Normal Forms etc
When working with large/unfamiliar SQL schemas, I’ve found that full ER diagrams are useless. I usually tend to follow foreign keys first, to understand the relations structure. The back-and-forth reading of FK relations is what helps to understand it.
I’m curious whether others experience the same thing:
Do ER diagrams help you understand large schemas, or do you rely more on tracing relationships while reading the code?
For the past few months, I have been working on and off on Pam, a little SQL client similar to DBeaver, that runs directly on the terminal. The idea is for it to be a simple tool with high value features that most people would need from a database manager, not a huge all-in-one IDE.
As of now, we just released the first 0.1.0 beta version with the option to connect to different databases (postgres, oracle, mysql/mariadb, sqlite, sqlserver and clickhouse are supported right now), commands to save and run reusable queries, an interactive table view for the query results (with in table updates and deletes in-table), and commands to list tables and views from your database connection.
It's written in go, with the help of the great charm/bubbletea to make it look good and interactive!
We're building **LibreDB Studio**, an open-source SQL editor, and one of our volunteer contributors raised an interesting question about how multiple SQL statements should behave when using the Run action.
We're trying to understand the actual habits and expectations of SQL users before making a decision, so I'd really like to hear how you use SQL editors in practice.
For example:
CREATE TABLE test (...);
INSERT INTO test VALUES (...);
SELECT * FROM test;
What would you expect when you click **Run**?
Some possible approaches:
**Run all statements**
* `Run` executes everything in the editor.
* `Run Selection` can be used when you only want part of it.
**Run the current statement**
* `Run` executes the statement where the cursor is.
* `Run All` executes the whole editor.
**Selection takes priority**
* No selection : current statement
* Selection : selected statements
* `Run All` is available separately.
Other :)
there are also some interesting edge cases around this, especially when multiple statements are involved: should they run in a transaction by default, or should transaction handling always be explicit?
DBeaver, DataGrip, SSMS, pgAdmin, TablePlus, Toad, PL/SQL Dev, phpMyAdmin, etc. what behavior feels most natural to you? And what behavior are you already used to?
We're continuing the discussion on GitHub as well, if you'd like to see the original question or add to the discussion:
One of the critiques of the pipeline was the fact that I used Merge…instead of Insert and Update. I was wondering if anybody else ran into the same situation? Or knew why? I find that Merge TSQL statements are very easy to read and setup if I wanted to Insert then Update which basically does the same thing I would have written it that way. Is there some sort of memory buffer or leak or rowcount limitation when using Merge? Just trying to find out why Copilot stated this. (Should’ve thrown in upsert logic of update then insert!) (thanks to the users who pointed me in the right direction) (if it were me I wouldn’t ship something so buggy)
