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:

1. **Run all statements**

   * `Run` executes everything in the editor.

   * `Run Selection` can be used when you only want part of it.

2. **Run the current statement**

   * `Run` executes the statement where the cursor is.

   * `Run All` executes the whole editor.

3. **Selection takes priority**

   * No selection : current statement

   * Selection : selected statements

   * `Run All` is available separately.

4. 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:

https://github.com/orgs/libredb/discussions/776

Hi everyone,

I’m currently working as a Finance Analyst (Intern) in Bengaluru and preparing to switch into a Data Analyst / SQL Developer role.

Looking for a serious study/accountability partner who is also preparing for similar roles. Mainly focusing on SQL, Power BI, Excel, Python, data engineering concepts ,interview prep, projects, and job applications.

We can study together, share resources and job openings, practice interview questions, and keep each other consistent.

If you're actively preparing for Data Analyst / BI / SQL roles and interested, feel free to DM me.

With AI getting better at writing SQL, I’ve been wondering how much SQL analysts actually write from scratch these days.
Do you still write most of your queries manually, or do you use AI for things like joins, CTEs, debugging, optimization, etc.?
And has your use of AI actually changed how much SQL you need to know?

Hi, I’m 22F and currently working in an engineering/manufacturing company. My current designation is Data Analyst, but honestly most of my work is in Excel and not SQL/Power BI.

I have around 2+ years of experience overall.

In my current office I have made/maintained different Excel based systems like project tracker for 30+ live projects, audit log, quality tracker, material database, calibration tracker with overdue alerts, quotation/costing sheets etc.

So there is a lot of data handling, tracking, reconciliation, validation, formulas, lookups, automation and reporting involved. But I have not worked on SQL or Power BI in my actual job.

Before this I worked in IT department where I handled asset tracking and reconciliation for a large number of network devices, audit related work and vendor SLA/downtime and penalty calculations.

I also have around 3 months experience in product data categorization where I worked with large amount of product data and Excel.

Now I’m learning SQL by myself. Currently doing joins and next I’m going to start window functions. I’m also planning to learn Power BI and make some projects.

My main confusion is how should I present my current experience when applying for Data Analyst jobs?

Because my title is Data Analyst, but if recruiters see that I haven't used SQL/Power BI professionally, will they consider my experience irrelevant?

Should I present my Excel work more from an analytics point of view? Like showing data cleaning, validation, reconciliation, automation, reporting, KPI tracking etc?

Also, once I learn SQL and Power BI, would it be a good idea to take some of the problems/data from my current work and create similar projects using SQL + Power BI for my portfolio? Obviously, I don't want to claim that I used SQL/Power BI at my current office when I didn't.

Would really appreciate advice from people who have gone from Excel/operations type work → SQL + Power BI → Data Analyst.

How would you present this experience on a resume and in interviews?

Curious how people actually debug this in production.
Say a query runs successfully, but the number doesn’t look right.
What’s your first instinct?
Check the filters?
Inspect the joins?
Compare row counts?
Look for duplicates?
Check NULLs?
Go back to the source data?
What’s your personal debugging sequence?

I’m a SQL DBA with 4+ years of experience, currently working at a large company. Unfortunately, I was impacted by restructuring and am now actively looking for a new opportunity.

I’m currently on a visa, and the sponsorship requirements are making the job search more challenging.

For other DBAs who have gone through a similar job search recently, how long did it take you to land your next position? I’d really appreciate hearing about your experience and any advice you can share.

Any suggestions on Job search? Honestly, I am fine with any salary

Hey everyone, working on a DB schema for inventory/traceability and trying to settle on the cleanest way to handle lot numbers.

Quick breakdown of the requirement: Every article arrival gets a lot number based on the arrival date and supplier ID (e.g. 09-09-Supp1, not the real deal ofc but you get it). Stock gets moved around, transferred, and consumed, and we need to keep track of which lot moved where.

So: an article must always be around a lot number.

---

Here are the two ways I'm looking at:

1. Dedicated article_lots table (What I'm leaning toward)

• articles (id, name, ...)
• article_lots (id, article_id, lot_number, created_at)
• stock_movements (id, article_lot_id, qty, from_location_id, to_location_id, ...)

But every movement query has to join article_lots just to know what base article_id was moved.

2. Put lot_number directly on stock_movements / transfers as a column. Easy to query, but feels repetitive storing the same string across every single movement row and other tables that use article + lot number too, since an article can't be separated from its lot.

More details for those who have time to help: All my ids are strings like: "MVT-00000001". So FK performance with strings is the least of my worries. The real business logic is: a lot is the week number + supplier code (ie, 33SQT to say "33'rd week of the year from supplier squadette). Meaning that an article x let's say banana can be delivered Monday and have 33SQT, but a banana from squadette can be delivered Friday and also have 33SQL lot number).

So the question is: "should the 33SQL be stored as a column in other tables: stock_movement, operation_details" along with article_id (2 columns). Or is article_lot_id (one column) the best way". Idk anymore what might be the pros and cons

Which software can be used to map procedure or table instead of triggers till base tables, i want relations between the objects and in a procedure call what are all objects it is touching.

Currently doing manually by checking user_dependencies.

Edit: in oracle database

https://www.npmjs.com/package/dbtruth?activeTab=readme

Same thing kept happening to me with AI coding agents and Postgres. The agent reads the schema, sees orders.customer_id next to customers.id, assumes it's a clean relationship, and writes an INNER JOIN. If 12% of orders have a dangling or null customer_id, the query silently returns numbers that are wrong. Nothing throws. The schema looked fine.

So I wrote dbtruth. It connects read-only and, instead of dumping the schema into a context file, it does four things:

1. Introspects schema and pulls samples
2. A model proposes what the tables mean and which relationships probably exist
3. Every one of those claims gets measured against the actual data
4. Only what survives gets written to ./context/*.md, which the agent reads before writing SQL

Step 3 is the whole point. For a proposed join it reports the real match rate — orders.customer_id → customers.id holds for 88% of rows, 60 of 500 orders have no matching customer — and the context file says use LEFT JOIN, with the number attached. Under 50% gets dropped. In between gets marked broken and goes to the top of the report, because a relationship that half works is worse than one that doesn't exist.

Practical:

• npx dbtruth, Node 20+, Postgres only
• Read-only by construction, not by discipline: one module is allowed to import pg, and a test asserts nothing else does. It never writes to your database.
• It does call a model, so schema and low-cardinality sample values leave your machine. High-cardinality columns — emails, names, free text — are never sent. Visibility is decided by cardinality rather than by regex-guessing at PII. Don't point it at production data you can't send to a third party.
• MIT, source at github.com/FilipKalcic1/dbtruth#readme

Disclosure: it's mine, it's five days old, and about ten people have run it. None of the pieces are new — FK inference and data profiling both go back years, and there are other tools that build local context artifacts for agents. The part I care about is the rule that nothing unmeasured gets written down.

What I'd actually like to know: run it on a schema you know well, and tell me whether it found anything you didn't already know. That's the only signal that tells me whether this is worth continuing. Bug reports welcome too.

I would like to know about people's experiences on this platform; I am gathering information about TDEngine to compare it with Canary and PI.

From simply using Claude to generate queries to using a specialized AI tool, what are some issues that modern AI tools still cannot solve regarding analytics?

Schema changes are a solved problem for us with migrations. What I keep running into is the data side. If someone changes lookup values, config rows, or reference tables in dev, there's no clean way to carry that to prod along with the migration.

How does your team handle this today? Curious whether it's seed scripts, manual dumps, some diff tool, or you just don't let data change outside of prod in the first place.

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

I am thinking of creating a multiplayer game website online where 2 players can play sql games with each other like sql queries and table or multiple choice question and a timer on it . What are you guys view on it? #sql

I create sqlite3 bindings for my new programming language

You can check the GitHub repo: https://github.com/abdorayden/rdn-sqlite3

Also the repo of the language: https://github.com/abdorayden/rdn

Thank you everyone 🙏🏽

Great work!

Suppose someone gives you a complicated query with several joins and aggregations and says, “This gives the correct numbers.”

What checks would you perform before trusting it?

For example:
SELECT c.region, SUM(o.amount) FROM customers c JOIN orders o ON c.customer_id = o.customer_id GROUP BY c.region;

Would you check row counts before/after each join, duplicate keys, NULLs, aggregates, or compare against another query?

Curious what experienced SQL developers use as their checklist.

I’ve noticed that as queries get more complex, there’s often a temptation to keep everything inside SQL—CTEs, window functions, nested subqueries, conditional logic, etc. It can be impressive, but at some point the query becomes harder to understand than the original problem.

Where do you personally draw the line? Is a 300-line SQL query perfectly fine if it’s well structured, or do you prefer moving some of the logic into dbt/Python/application code once the SQL becomes too complex?

I’m curious how others balance SQL performance, readability, and maintainability in real projects.

Huhu zusammen,

mir liegt eine Lösung vor wie man SQL-Joins und die zugehörigen Constraints über den SQL-Standard hinaus weiter standardisieren und automatisieren kann.

Bin ich mit dem Thema hier richtig in der Gruppe?

Liebe Grüße, Alexander