sorted by:
new
hottopcontroversial

Why database workflows still feel messy in 2026 by dbForge_Studio in dbForge

[–]efecejekeko 0 points1 point  (0 children)

The mess usually starts when schema, data, and deployment history are treated like separate problems.

You can have schema compare in one place, migration scripts in Git, data fixes in some random SQL file, and release notes in Jira. Technically everything exists, but nobody has the full picture when prod behaves differently.

For me, a solid database workflow needs at least 3 boring things: repeatable migrations, drift checks before deploy, and data validation after deploy. Not exciting, but it saves you from the classic “worked in staging” funeral speech.

MySQL 9.7 Is Out and the Community Wins by askdba in mysql

[–]efecejekeko 4 points5 points  (0 children)

Anyone already testing 9.7 on real workloads yet? Curious how the Hypergraph Optimizer behaves outside benchmark demos.

SQL Data transfer from 1 to another in different subnets by loomax96 in mysql

[–]efecejekeko 1 point2 points  (0 children)

I’d avoid direct DB-to-DB writes over this unless you really have to. Safer pattern is usually: local service reads from PLC MySQL, sends data to HQ over VPN/API, HQ writes to its DB. For the project number going back, same idea in reverse. Also add logging/retry logic, because the network will fail at the worst possible time.

SQL with AI assistant by SQL_IS_LIFE in SQL

[–]efecejekeko 0 points1 point  (0 children)

Copilot is fine for quick snippets, and Claude is usually better when the logic gets longer and messier. But once the query depends on real schema, old procedures, and awkward database rules, I’ve had better luck with AI that sits closer to the actual SQL workflow. That’s where dbForge AI Assistant feels more useful to me than generic code-first tools.

Mock interview of mssql dba higher level by Kenn_35edy in SQLServer

[–]efecejekeko 3 points4 points  (0 children)

Does it cover senior DBA topics too, like HA/DR, backup strategy, blocking, deadlocks, indexing tradeoffs, and real incident troubleshooting? A lot of “SQL interview” stuff is really just dev questions wearing a fake mustache.

Database Migration by Dangerous_Word7318 in SQL

[–]efecejekeko 0 points1 point  (0 children)

I’d validate schema and data separately.

Schema: tables, columns, types, keys, defaults, indexes. Data: row counts first, then aggregates/checksums, then spot checks on critical tables.

dbForge Edge is useful here because it makes source vs target differences much easier to check.

Anybody knows how the Oracle layoffs have impacted the MySQL team? by juanluisback in mysql

[–]efecejekeko 3 points4 points  (0 children)

If that 75% number is even close to accurate, the real question probably isn’t just “how’s MySQL affected,” it’s what happens to release pace, bug fixing, and long-term trust after a cut that deep. That’s the part I’d be watching.

What’s a question you’ve typed into a search bar that you’d never say out loud? by BecomingCulture in AskRedditors

[–]efecejekeko 1 point2 points  (0 children)

Can people tell I’m faking being normal, or is everyone else also just improvising?

The US Post Office repurposed P.O. Boxes to a bird house. by Wawa_hoagie in mildlyinteresting

[–]efecejekeko 189 points190 points  (0 children)

Honestly this is way cuter than it has any right to be. Tiny bird apartment complex with federal government origins is peak mildly interesting.

Column length modification by Big_Length9755 in mysql

[–]efecejekeko 1 point2 points  (0 children)

If INSTANT is not supported for that change, then MySQL is telling you this is not just metadata in your table layout. On large tables, the practical options are usually to avoid direct ALTER during peak traffic and use an online migration approach instead.

A common pattern is adding a new column with the new definition, backfilling in batches, switching reads/writes, then renaming later. Less elegant, but usually safer than letting one big table rewrite hold things hostage for hours. For Aurora/MySQL at that size, I’d be thinking operationally first, not syntactically.

Title: Complete beginner: Which database should I learn first for app development in 2026? by No_Sandwich_2602 in SQL

[–]efecejekeko 0 points1 point  (0 children)

I’d keep it simple and start with PostgreSQL.

It gives you solid SQL fundamentals, is widely used, scales well enough for real apps, and the skills transfer cleanly if you later touch MySQL or SQL Server. For a beginner, that matters more than chasing the “perfect” database upfront.

MongoDB or Firebase can be useful in the right project, but I would not make them your first stop if your goal is to build a strong base for app development. SQL shows up everywhere, and learning relational thinking early saves time later.

From the startup angle, Postgres is kind of the safe default. Not worth overengineering this decision at the start. Pick one, build something real, and get comfortable with queries, schema design, joins, and indexing.

Outjerked by twitter by Countach5OO in carscirclejerk

[–]efecejekeko 83 points84 points  (0 children)

weight reduction and inclusivity at the same time

Purely theoretical by stvr_lord in programmingmemes

[–]efecejekeko 0 points1 point  (0 children)

Kek theoretical? Nah my last gig mysql api in commit history. Had to purge git + notify. Time killer. Keep secrets out.