I have to let it out. It's been brewing for years now.

Why does MySQL still exist?

Really, WHY?!
It was lousy as hell 8 years ago, and since then it hasn't changed one bit. Why do people use it?

First off, it doesn't conform to standards, allowing you to aggregate without explicitly grouping, in which case you get god knows what type of shit in there, and then everybody asks why the numbers are so weird.

Second... it's $(CURRENT_YEAR) for fucks sake! This is the time of large data sets and complex requirements from those data sets. Just an hour through SO will show you dozens of poor people trying to do with MySQL what MySQL just can't do because it's stupid.

Recursion? 4 lines in any other large RDBMS, and tough luck in MySQL. So what next? Are you supposed to use Lemograph alongside MySQL just because you don't know that PostgreSQL is free and super fast?

Window functions to mix rows and do neat stuff? Naaah, who the hell needs that, right? Who needs to find the products ordered by the customer with the biggest order anyway? Oh you need that actually? Well you should write 3-4 queries, nest them in an incredibly fucked up way, summon a demon and feed it the first menstrual blood of your virgin daughter.

There used to be some excuses in the past "but but but, shared hosting only has MySQL". Which was wrong by the way. This was true only for big hosting names, and for people who didn't bother searching for alternatives. And now it's even better, since VPS and PaaS solutions are now available at prices lower than shared hosting, which give you better speed, performance and stability than shared hosting ever did.

"But but but Wordpress uses MySQL" - well then kill it! There are other platforms out there, that aren't just outrageously horrible on the inside and outside. Wordpress is crap, and work on it pays crap. Learn Laravel, Symfony, Zend, or even Drupal. You'll be able to create much more value than those shitty Wordpress sites that nobody ever visits or pay money on.

"But but but my client wants some static pages presented beside their online shop" - so why use Wordpress then? Static pages are static pages. Whip up a basic MVC set-up in literally any framework out there, avoid MySQL, include a basic ACL package for that framework, create a controller where you add a CKEditor to edit page content, and stick a nice template from themeforest for that page and be done with that shit! Save the mock-up for later use if you do that stuff often. Or if you're lazy to even do that, then take up Drupal.

But sure, this is going a bit over the scope. I actually don't care where you insert content for your few pages. It can be a JSON file for all I care. But if I catch you doing an e-commerce solution, or anything else than just text storage, on MySQL, I'll literally start re-assessing your ability to think rationally.

Not exactly a security bug, but there was a company that made a Django app for some internal work and later open sourced it. I was browsing through the code and I saw that the config file had an IP address and a hashed password for the database credentials

When I tried to use them, I was able to login directly to their read replica RDBMS, I had access to all their customer data (including phones & home addresses)
Being the saint I am, I informed them of the ignorance made by their developer and was presented with some cool swag.

Some companies be like-

.. In job posting - We are the next big thing. We are going to change the industry. We are like Google / Facebook etc...

..in Introduction - We are the next big thing. We are going to change the industry. We are like Google / Facebook etc...

.. in Interviews - We are the next big thing. We are already changing the industry. Think of us like Google / Facebook etc...

.. during Interviews - Our interview process is rigorous because we are the next big thing. We are going to change the industry. We are like Google / Facebook etc...

.. questions in interviews - Since we are Google / Facebook, please answer questions on Java, C/C++, JS, react, angular, data structure, html, css, C#, algorithms, rdbms, nosql, python, golang, pascal, shell, perl...
.. english, french, japanese, arabic, farsi, Sinhalese..
.. analytics, BigData, Hadoop, Spark,
.. HTTP(s), tcp, smpp, networking,.

..

..

..

.. starwars, dark-knight, scarface, someShitMovie..

You must be willing to work anytime. You must have 'no-excuses' attitude

.........................................

Now in Salary - Oh... well... yeah... see.... that actually depends on your previous package. Stocks will be given after 24 re-births. Joining bonus will be given once you lease your kidneys.

But hey, look... We got free food.

Well, SHOVE THAT FOOD UPTO YOUR ASS.

FUCK YOU...
FUCK YOUR 'COOL aka STUPID PIZZA BEER - CULTURE'.
FUCK YOUR 'FLAT- HIERARCHY'.
FUCK YOUR REVOLUTIONARY-PRODUCT.

FUCK YOU!

All databases are document databases if your varchars are big enough.

Him: Relation databases are stupid; SQL injections, complex relationships, redundant syntax and so much more!

Me: so what should we use instead? Mongo, redis, some other fancy new db?

Him: no, I have this class in Java, it loads all the data into memory and handles transfers with http.

Me: ...... Bye!

I just had the most surreal email discussion I think I've ever had...

I spent over two hours going back-and-forth over email with an enterprise DBA, trying to convince them I needed a primary key for a table. They created the table without a primary key (or any unique constraints... or indexes... but that's another discussion). I asked them to add one. Then had to justify why.

If you ever find yourself justifying why you need a primary key on a table in an RDBMS, that's the day you find yourself asking "is this real life?"

I want the last two hours of my life back. And a handful of Advil.

SQL Rule 1. Always assume there are external processes that might affect your data. (for instance, triggers).
SQL Rule 2. In Denormalised data, never execute logic on dependant table values, always copy from the parent.
SQL Rule 3. When Denormalised data schemas are created the DBA knows what they are doing.
SQL Rule 3.1. If DBA knows what they is doing then according to Rule 1 there is no problem with adding in some triggers to maintain data clones as they are created.
SQL Rule 4. If you don't like or agree with triggers, deal with it. They are a first class tool in a first class RDBMS. In a multi-app or service environment there may be many other external processes massaging your data
SQL Rule 5. If all previous rules are not broken and the system has been running efficiently for many years DO NOT complain that there are triggers in the database that are doing and have been doing the same process that you just butchered (by violating Rule 1 and 2) in your makeshift "hello world, look what I can do from my phone" angular BS when the rest of the users are still relying on the existing runtime app.
SQL Rule 6. If you turn my triggers off, you sure as hell better turn them back on!

A friend of mine asked me yesterday for help for his bachelor thesis.

He wants to write about MySQL internals in regards to BLOB storage / usage.

We had a veeeerrrry long discussion....

And found a loooot of scary internet pages.

It's so .... Insane....

What some people with doctor titles or higher education generate...

Isn't content. More poo...

Most "blogs" / "articles" or whatever the author named it were missing all kinds of relevant data (version, configuration, anything relevant) but full of opinionated / biased bullshit.

Highlights were:
- we store lot of BLOB data, Backups take long and require more space
(you store additional data in an database, whaddya expect???!!!!)

- interesting guesswork about locking without any reference (interesting since it was sometimes so far away from reality that it looked more like quantum physics)

- storing blobs means that _each_ blob entry will be stored in a separate file (without any reference, but if an RDBMs did that... It would end in an amazing fireball I guess)

- BLOB's bad since it can represent only the file content, the database cannot distinguish wether it's an MP3 / MPG or anything like that...

(Ehm. Yeah. And an database cannot distinguish if you store under "Name" an Name or gibberish?!)

I somehow think that some people made an doctor and post this gibberish nonsense so people stay dumb to give them a job...

Like the TV repair men who steals the batteries from the remote.

Even conspiracy theories were more convincing

I feel so stupid right now!!!

RDBMS class: I have to fucking attend every class even though our lecturer just reads slides from Oracle to us.

In order to pass that module, we have to take the exams on their shitty website full of stupid questions, I.e. "Oracle academy is beautiful? a) true b) false" (I put false and they obviously marked it as wrong, ffs).

Multi-user operative systems: I was the one teaching our lecturer stuff on Linux.

WHY THE FUCK I CANNOT STAY AT HOME AND BE FUCKIN PRODUCTIVE INSTEAD?!

The only fucking interesting class is Data Structures & Algorithms and they pretend that we also attend every other useless class. FUCK YOU!

PS: I know the 90% of the stuff they are trying to teach us because I actually want to learn something and I know how to use Google, but no, I have to waste 2 hours on the bus every single day I have lessons.

What is the purpose of using MongoDB and then adding mongoose?
If you want schemas, relations and all the jazz mongoose offers, have you considered using a RDBMS instead of a datapile system? Most (probably all) SQL databases support schemas, relations and all the jazz you seem to need.

So, ask yourself: Do you really need the functionality of a NoSQL database or do you just want it because it's shiny and new and "everybody uses it (tm)"?

Old old organization makes me feel like I'm stuck in my career. I'm hanging out with boomer programmers when I'm not even 30.

I wouldn't call myself an exceptional programmer. But the way the organization does it's software development makes me cringe sometimes.

1. They use a ready made solution for the main system, which was coded in PL/SQL. The system isn't mobile friendly, looks like crap and cannot be updated via vendor (that you need to pay for anyway) because of so many code customizations being done to it over the years. The only way to update it is to code it yourself, making the paid solutions useless
2. Adding CloudFlare in the middle of everything without knowing how to use it. Resulting in some countries/networks not being able to access systems that are otherwise fine
3. When devs are asked to separate frontend and backend for in house systems, they have no clue about what are those and why should we do it (most are used to PHP spaghetti where everything is in php&html)
4. Too dependent on RDBMS that slows down development time due to having to design ERD and relationships that are often changed when users ask for process revisions anyway
5. Users directly contact programmers, including their personal whatsapp to ask for help/report errors that aren't even errors. They didn't read user guides
6. I have to become programmer-sysadm-helpdesk-product owner kind of thing. And blamed directly when theres one thing wrong (excuse me for getting one thing wrong, I have to do 4 kind of works at one time)
7. Overtime is sort of expected. It is in the culture

If you asked me if these were normal 4 years ago I would say no. But I'm so used to it to the point where this becomes kinda normal. Jack of all trades, master of none, just a young programmer acting like I was born in the era of PASCAL and COBOL

Just succesfully setup database cluster , now I need balancer!

I was reading a few interesting postgreSQL solutions to constrain polymorphic tables (anti-pattern, I know) when something caught my eye.
Some solutions were looked down upon (or looked favorably upon) based on their portability to other rdbms like MySQL.
Is that really so important? I get it, if somehow you decide to change from one to the other for some god-forsaken reason it will make the switch easier. But really, how often will that happen?
I feel there is a tendency to just avoid using SQL beyond the basics.

In the past, apps I've written have used a flat file backend. It's very fast, but obviously clunky to have a big structure of flat files for an app. It ran circles around framework-based RDBMS backends, as performance is concerned, but again, it was clunky. Managing backups and permissions on tens or hundreds of thousands of small files was no fun. Optimizing code for scaling was fun- generating indexes, making shortcuts -but something was still missing. Early in 2017 I discovered redis. A nosql backend that just stores variables and lives almost entirely in memory. Excellent modules and frameworks for every language. It was EXACTLY what I'd needed, even though I didn't know I did. I spent a good deal of time in 2017 converting apps from flat files to redis, and cackled with glee as they became the apps I wanted them to be. Earlier this week, I started building my first app that started with redis, instead of flat files, and I can't stop gushing to anyone who will listen. Redis for president!

Q: What do you get when you create a homebrew query language that uses both the stream oriented principles of Unix data pipes and the relational ideas underlying an RDBMS and use incomplete documentation to support it?

A: A frustrated borderline homicidal engineer.

If you ever need a good example for bad API design, just use IndexedDB. While it might still be far above absolute zero, it should definitely be low enough for any practical purpose.

And as a bonus, it wouldn't actually have been needed if the SQLite status quo would just have been adopted as the standard back then. We could have a complete RDBMS with almost full SQL support in the browser...

Maybe noob question here, but what's the added value of using graph db like neo4js compared to regular RDBMS like PostgreSQL ? I see our beloved devrant uses neo4js so I am wondering if it's worth spending some time digging into this, just that (ok, actually it would be too cool to also have dfox and trogus appear in comments notifications)

Quick and dirty job to get some data into a DB wasted my entire evening.

Created table with few columns, tried writing to it from NodeJS app and it kept complaining I wasn't providing values for columns that didn't even exist. After ages pissing about decided that the DB gods had cursed this particular table so created a second one with same DDL. Now it worked first fucking time. Then it finally dawned on me, I'd managed to pick a reserved table name and the RDBMS didn't think to give me a warning when I created it. Not only did it not warn me but it kept going as it nothing was the matter and didn't report the extra columns on a SELECT *.

I had a discussion with my colleagues about my bachelor thesis.

Together we created within the last 18 month a REST-API where we use LDAP/LMDB as database (tree structured storage). Of course our data is relational and of course we have a high redundancy there. It's a 170 call API and I highly doubt that it's actually conforming REST.
Ensuring DB integrity is done in the backend and coding style there is "If we change it at one place, let's make sure to also change it everywhere else", so you get a good impression how much of spaghetti code we have there.

Now I proposed to code a solution in my bachelor thesis where we use a relational database (we even have an administrated Oracle DB with high availability) and have a write-only layer to also store the data in LDAP but my colleagues said that "it would add too much complexity to the system".
Instead I should write the relational layer myself and fetch the data somehow from the existing LDAP tree.

What the actual fuck, spaghetti code is what makes the system really unnecessarily complex so that no one will understand that code in 2 years.

Congratulations, you just created legacy code that went into production in 2018 while not accepting the opportunity to let that legacy code get eliminated.
Now good luck with running and maintaining that system and it's inconsistencies.

Should i do hadoop big data course ? I am thinking of this summer to do on simplilearn. I am third year student undergraduate in IT. I am java guy and good in RDBMS.. Should i learn then?

Using DB triggers is something bad? I have started using NoSLQ databases (CouchDB and MongoDB) and I can't find anything intuitive or native to the BD.

The worse is that I have googled it and I rarely find people asking for triggers in NoSQL databases.

What am I missing? My concepts about RDBMS blind me about NoSQL?

Time for an unpopular opinion, I've been working with MySQL spot this week and I've actually quite liked it. The documentation is well layed out, innodb seems pretty peformant after some initial soak tests. Yeh I like this.

ORM feels like, I can do better than that, with more predictability (like naming, table creation, and stuff).

The only pro, is hopes for inter-dialects interop (SQLite-Postgres-MySQL-MariaDB).

OK, I also want SQLite-MongoDB interop, because of the cheap price; but this is difficult.

For a project we have a choice between:

Storing documents, images, videos and textual data in a database. Provide relations for searching and a GUI for uploads. Web and mobile (I only have experience with RDBMS)

Solution for digitally signing documents with asymmetric cryptography. Provide web and mobile GUI. Also something about ad hoc signing (possibly insert usb stick to sign?)(know a good bit of cryptography already)

Which one should we pick? (5 man group)

When I normalize a database, it always feels like I cannot predict Cascading, leaving broken relationships and trash queries.

I thought I had to VARCHAR in non-SQLite RDBMS. I was wrong. There is TEXT.

1. PostGres seems to work better with TEXT.
2. There is an ORM that forces VARCHAR (255) by default.
3. But you can go over the limit without throwing errors.