Classes are classist.

Objects are objectifying.

Race conditions are racist.

Foreign keys are xenophobic.

Functions are ableist.

Thin clients are weightist.

Bitmasks perpetuate heteronormativity.

Code beautifiers promote unrealistic beauty expectations.

Test-driven development is victim blaming.

Forced commit pushes are rape.

Motherboards perpetuate gender roles.

And don't get me started on white space.

I worked on a greenfield project a couple of years ago. The company had an old solution written in Omnis (heard of it? Yeah, me neither) with an SQL database. My team was to create a completely new web based system... on top of the old database, so the customers could keep their existing stuff.

The dba was an intelligent man, one of the nicest people I've met, and over the course of fifteen years he had made a remarkably terrifying monstrosity of a database. Some years before me they wanted to "future proof" the system and make it "easier to switch to new technologies". So they moved the entire business logic into the database...

I used a tool to create a visualization of said database when we started. It had no views, only tables and sprocs. Look at it! Tables and sprocs are rectangles (well, dots) and any connections are drawn in grey lines. There were no foreign keys, so a tables only visualization only yielded a collection of independent rectangles without a single line.

Now, the stored procedures were bloody MASSIVE. A single procedure that only registered a new interested party and attached them to a property had 2500+ lines and over 150 parameters.

Also, this dba added features and fixed bugs by logging into the respective customers production server and writing SQL.

That database is the stupidest thing I've ever seen a developer do.

"Well I don't know what foreign keys are so we won't be using them."

Sigh...

Root gets ignored.

I've been working on this monster ticket for a week and a half now (five days plus other tickets). It involves removing all foreign keys from mass assignment (create, update, save, ...), which breaks 1780 specs.

For those of you who don't know, this is part of how rails works. If you create a Page object, you specify the book_id of its parent Book so they're linked. (If you don't, they're orphans.) Example: `Page.create(text: params[:text], book_id: params[:book_id], ...)` or more simply: `Page.create(params)`

Obviously removing the ability to do this is problematic. The "solution" is to create the object without the book_id, save it, then set the book_id and save it again. Two roundtrips. bad.

I came up with a solution early last week that, while it doesn't resolve the security warnings, it does fix the actual security issue: whitelisting what params users are allowed to send, and validating them. (StrongParams + validation). I had a 1:1 with my boss today about this ticket, and I told him about that solution. He sort of hand-waved it away and said it wouldn't work because <lots of unrelated things>. huh.

He worked through a failed spec to see what the ticket was about, and eventually (20 minutes later) ran into the same issues Idid, and said "there's no way around this" (meaning what security wants won't actually help).

I remembered that Ruby has a `taint` state tracking, and realized I could use that to write a super elegant drop-in solution: some Rack middleware or a StrongParams monkeypatch to mark all foreign keys from user-input as tainted (so devs can validate and un-taint them), and also monkeypatch ACtiveRecord's create/save/update/etc. to raise an exception when seeing tainted data. I brought this up, and he searched for it. we discovered someone had already build this (not surprising), but also that Ruby2.7 deprecates the `taint` mechanism literally "because nobody uses it." joy. Boss also somehow thought I came up with it because I saw the other person's implementation, despite us searching for it because I brought it up? 🤨

Foregoing that, we looked up more possibilities, and he saw the whitelist+validation pattern quite a few more times, which he quickly dimissed as bad, and eventually decided that we "need to noodle on it for awhile" and come up with something else.

Shortly (seriously 3-5 minutes) after the call, he said that the StrongParams (whitelist) plus validation makes the most sense and is the approach we should use.

ffs.
I came up with that last week and he said no.
I brought it up multiple times during our call and he said it was bad or simply talked over me. He saw lots of examples in the wild and said it was bad. I came up with a better, more elegant solution, and he credited someone else. then he decided after the call that the StrongParams idea he came up with (?!) was better.

jfc i'm getting pissy again.

SQL gives me a hard on right now.

Two tables, 954 rows and 9414, connected via foreign keys and shit.

SELECT a_id,name,shit FROM table1 a JOIN table2 b ON a.id = b.a_id WHERE ((lower(name) LIKE '%lorem%') OR MATCH(name) AGAINST('lorem' WITH QUERY EXPANSION) OR name SOUNDS LIKE 'lorem')

and you got fuzzy search with resolved keys to another table in 0.047 sec, fuck me dude.

The use of git and understanding/working with foreign keys and performing (including the understanding) JOIN queries.

Also, it took me years and to understand OOP.

When think back to my code from before that, my brain spontaneously starts bleeding.

There's this junior I've been training. We gave him a bigger task than we usually do

"How do I link an object in table X with the corresponding object in table Y?"

"How are objects in two tables usually linked? How did you link Y with Z in the first place?"

"Em... Foreign Keys?"

"Yup"

"But there's not foreign key from X to Y."

"Well, create one. You've got full creative freedom over this task."

I sometimes feel like Juniors are either completely careless about past code or overly carefuly with not editing any past code. Frustrating but adorable

Oh boy. Gotta love having a team member (For a School project) be in charge of the Database functionality/design, who has almost no communication skills and basically no clue about how to store data in a data base.
Im talking dates stored as varchar(5), column sizes being way way to small, overall table design being rather terrible, no primary/foreign keys, pretty much... Actually no, everything was being stored as a varchar.
Not only that, but there was a hell lot of data that needed to be stored that wasn't even accounted for in the DB design. He made some code that could be used by our team members for queries, creating tables, inserting data (etc), almost 2,000 lines of it.... And basically nothing was fucking documented at all. I'm talking comments like "Insert data into cities table" and nothing else. More complicated functions had as much, or less documentation. Complete mess.

Cannot believe I am paying for a course with a lecturer that doesn't even teach the students what a foreign key is, or the concept of a join table to breakdown many-to-many relationships in a database. Literally telling me "If thats how you interpreted it, it's ok to add that in, but you dont have to." In relation to adding a new entity into the ER Diagram as a join table.

It isn't up for interpretation, you are literally joining tables based on foreign keys that will create duplication and make no sense. I mean, you are teaching people who have likely never worked with DB's before... you cannot teach them this. 🤦‍♀️

I really think there should be a subject in every CS course to teach us how to handle/work-under Grade-A assholes and dumbfucks. Not that it would help, but atleast warn us on what we are getting into.

In my opinion, development is not *that* hard or frustrating but is made so by these shitty people. But again, what do I know.

I was scolded by my boss for using for-loop to iterate through an array recently. Apparently for-loop is not used in real world projects and this iteration should be done "in-memory". My colleagues and I are still trying to understand and process that.

I was asked to add fitbit integration to a project within 2 hours just because I had "already done it a week ago" in *another* project. Luckily, it was then given to a "senior" developer who took 4 days for it and essentially copy-pasted my work without much changes, ofcourse it stopped working every now and then.

I am given unreal deadlines on my tasks, on technologies I haven't worked on before, and then expected to churn out production ready code with no bugs in them.

My boss literally just sends me the links of 1st three google results on the problems I encounter and report, after humiliating me ofcourse. Yes, I did google it and yes I went through all I could find from Google forums to GitHub issues. When the library/plugin author himself says that this feature is not yet available, don't expect me to develop it in 2 hours you dumbfuck.

And for the love of God, please stop changing the data model every single day and justify it with agile development. Think before making any changes to it. Ever heard of Join queries? Foreign keys? Or any other basic database concepts.
We reached a point where each branch in the repo had different data model. Not kidding. And we were a team of just 4 developers. Atleast inform us when you change models after discussing it with your shit for knowledge "senior" developer, so we don't have to redo it all over again. The channels on slack are not for sharing random articles only.

I am just waiting to complete my year here.

I should have known what I got myself into the day he asked me to remove the comments I had added to explain what my code does. Why you ask? Because "we don't write comments".

My boss's SQL schema has no foreign keys and he said he left them out intentionally because they should be handled in the application layer and they're a large performance impact.

This is a fresh greenfield project and he's already pre-optimizing for problems we don't have yet, on things that may or not be bottlenecks using ideas (e.g. foreign keys have huge performance costs on mariadb/auora) with no hard data or facts to back them up.

Let's start a new project with some technical debt!

Ok now I'm gonna tell you about my "Databases 2" exam. This is gonna be long.

I'd like to know if DB designers actually have this workflow. I'm gonna "challenge" the reader, but I'm not playing smartass. The mistakes I point out here are MY mistakes.

So, in my uni there's this course, "Databases 2" ("Databases 1" is relational algebra and theoretical stuff), which consist in one exercise: design a SQL database.

We get the description of a system. Almost a two pages pdf. Of course it could be anything. Here I'm going to pretend the project is a YouTube clone (it's one of the practice exercises).

We start designing a ER diagram that describes the system. It must be fucking accurate: e.g. if we describe a "view" as a relationship between the entities User and Video, it MUST have at least another attribute, e.g. the datetime, even if the description doesn't say it. The official reason?

"The ER relationship describes a set of couples. You can not have two elements equal, thus if you don't put any attribute, it means that any user could watch a video only once. So you must put at least something else."

Do you get my point? In this phase we're not even talking about a "database", this is an analysis phase.

Then we describe the type dictionary. So far so good, we just have to specify the type of any attribute.

And now... Constraints.
Oh my god the constraints. We have to describe every fucking constraint of our system. In FIRST ORDER LOGIC. Every entity is a set, and Entity(e) means that an element e belongs to the set Entity. "A user must leave a feedback after he saw a video" becomes like

For all u,v,dv,df,f ( User(u) and Video(v) and View(u, v, dv) and feedback(u, v, f) ) ---> dv < df

provided that dv and df are the datetimes of the view and the feedback creation (it is clear in the exercise, here seems kinda cryptic)

Of course only some of the constraints are explicitly described. This one, for example, was not in the text. If you fail to mention any "hidden" constraint, you lose a lot of points. Same thing if you not describe it correctly.

Now it's time for use cases.
You start with the usual stickman diagram. So far so good.
Then you have to describe their main functions.

In first order logic. Yes.

So, if you got the point, you may think that the following is correct to get "the average amount of feedback values on a single video" (1 to 5, like the old YT).
(let's say that feedback is a relationship with attribute between User and Video

getAv(Video v): int
Let be F = { va | feedback(v, u, va) } for any User u
Let av = (sum forall f in F) / | F |
return av

But nope, there's an error here. Can you spot it (I didn't)?

F is a set. Sets do not have duplicates! So, the F set will lose some feedback values! I can not define that as a simple set!

It has to be a set of couples, like (v, u), where v is the value and u the user; this way we can have duplicate feedback values in our set.

This concludes the analysis phase. Now, the design.

Well we just refactor everything we have done until now. Is-a relations become relationships, many-to-many relationships get an "association entity" between them, nothing new.
We write down on paper every SQL statement to build any table, entity or not. We write down every possible primary key or foreign key. The constraint that are not natively satisfied by SQL and/or foreign keys become triggers, and so on.

This exam is considered the true nightmare at our department. I just love it.

Now my question is, do actually DB designers follow this workflow? Or is this just a bloody hard training in Pai Mei style?

foreign keys, please

kthxbye

IT'S CAPS RANT TIME!
MYSQL ERRORS ARE SO USELESS! AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHH

I JUST WANT TO ADD A FOREIGN KEY BUT 'Cannot add foreign key constraint' KEEPS COMING UP, AND THE STACK OVERFLOW ANSWERS INDICATE THAT IT COULD BE -LITERALLY- ANYTHING!

THIS IS OF COURSE, AFTER PHPMYADMIN GIVES ITS OWN ERRORS FOR TRYING TO USE THE DESIGNER TO ADD THE RELATION. IT ONLY WANTS UNIQUE FOREIGN KEYS, DESPITE ONE OF THE MAIN USES OF FOREIGN KEYS BEING MANY-TO-MANY AND ONE-TO-MANY RELATIONS!

!rant
the most popular ecommerce solution in php is a massive (cosmological scale) pile of corporate crap (magento) and the next most popular is an abomination (opencart)
after fucking around with both for a month (the client asked for the project to be using only one of the two) I'm still barely reaching any results, and most of my time is wasted with the stupid bloated spaghetti that is opencart FUCK THIS,
like seriously. who the fuck writes a single line three left joins sql querry with four or five aliases a couple concacts and a bunch sorting fuckeries just to query the categories list, then just query the details of the specific category from a different function,
also why the fuck map each language string manually. or the fucking hardcoded seo urls, or the use of myisam for all tables, and no fucking foreign keys, let that settle for a minute, no foreign keys, the delete method in the model has at least a twenty lines, and then he came with the genius idea of duplicating models, in the front and the backend, accessing the same data, as the same user, but different naming conventions

I'm going to convince him to use something sane like codeigniter/laravel/fuelphp or I'll deny the project

<insert obligatory "long time lurker" statement here>

Started a role about 6 months ago. I'm the sole IT programmer. A bit of the mess I inherited...

- 100+ stand-alone applications/tools (luckily most of them aren't too big).
- No documentation.
- Some applications' only copy of the code exists in production.
- We only have production.
- A single file consisting of 30K+ lines of VB. Little to no comments. The one comment at the top says to keep old code by commenting it out and state what you changed.
- Previous devs didn't like foreign keys.
- No. Fucking. Version. Control. At. All.
- And so much more...

Luckily I was hired due to my experience so I could fix all these problems. Its actually a really great job.

Client: I need you to clean up the database and remove all rows [with children] with a timestamp older than 5 years

Team: OK

Team [internally]: we definitely need a dba for this
Me: dba? Why? A junior dev can do that
Team: yyeeaahh, but still.. A DBA would do it better. You know, foreign keys and everything

Me: ....

Him: i get this error when i insert into table, ForeignKey_contraint failed, what can i do?

Me: you have to obey the constraint, make sure it exists in the other table first

Him: ok i did that but i still get ForeignKey constraint error

Me: yeah that table has a couple foreign keys

Him: could you give me a very specific example how to insert into this table

Me: ........ here is a command to remove constraints on the table

Him: thanks, that fixed it!

I am helping a programmer who works with Costco integrate to software my company sells. I don't have source code, just an understanding of the database and what the software does. If he is getting paid more than me, then I should get a job there and ask for double, I could easily work 10 times faster than this buffoon.

A prototype being used as production code written in procedural PHP with the code drawn using echo and MySQL (not MySQLi) all mixed together and the configuration with world readable database stored as config.inc.
All backed by a database with no foreign keys or data integrity of any kind.

FUCK YOU PHP, FUCK YOU SYMFONY AND DEFINITELY FUCK YOU SHOPWARE.

Don't get me wrong, PHP has evolved a lot, but the stuff people are building with it is just the biggest load of fucking shit I have ever seen: Shopware. Shopware is the most ass-sucking abomination to extend. It's nearly impossible to develop anything beyond "use the standard features and shut the fuck up" that is more sophisticated than a fucking calculator.

The architecture of this pile of crap is the worst bullshit ever. A mix of OOP, randomly making use of non OOP concepts and features together with the unnecessarily HUGE amount of useless interfaces and classes. Sometimes I feel like it's 90% fucking shitty boilerplate shit.

And don't get me started with TWIG. It's a nice thought, but WHY THE BLOODY FUCK WOULD YOU NOT USE VUE IF YOU ARE ALREADY USING IT FOR A DIFFERENT PART OF SHOPWARE. This makes no fucking sense whatsoever and makes development of new features a huge pain in the ass. I can't comprehend how people actually like using this shit.

OH AND THE DATABASE. OH MY FUCKING GOD. This one is bad. Ever tried to figure anything out in a database where random strings (yes MySQL "relational" - you might think) that are stored as text in a JSON format make up some object or relations during runtime?? Why the fuck do you have foreign and primary keys if you don't use them properly??

Seriously you can't even figure out which data belongs to what because the architecture just sucks fucking ass. FUCK YOU Shopware wankers, you suck, your product sucks, your support sucks, your architecture sucks and you keep releasing new versions that regularly break shit even in minor versions.

I used to like PHP, but not in projects like these.

The only relationships that exist in my life, are the ones in my projects' ER diagrams. And they too are infected with foreign keys..!

!Worst, being put on the project a day before release

!Best, finding and fixing all the data model issues before release, so that the next time I have to pull stats about the system, everything actually makes sense, as all foreign keys and indexes would be explicitly defined for once.

Need to write a query to find all scheduled reports, sounds easy, right?

Not in a system with over 1k tables all with obscure names and absolutely no foreign keys at all.

i need advice, is this a good database structure? this is a comments table with foreign keys to users and posts table. the post_id and user_id can be repeated a lot of times so i wondered if i missed something here. i kinda forgot the 1/2/3 normalized form rules, so can someone give me a quick refresh? is this current structure good or should i change it?

Sigh Im getting depressed from going to work whilst a few weeks ago it gave me a bunch of happines.

I think its due that management is approaching a triple deadline (?!?!?!) project in an agile/scrum way (?!?!??!)..

We can not change our data model completely when we have to be in acceptance in 3 weeks and do a demo in a few days..

Yes we can work around that but fuck database design theory and lets ignore all primary keys and foreign keys, great idea

We have to create and prioritise user stories on our own? We have two product owners and a scrum master.

Scrum master offers to deal with organising and creating tickets to organise Infrastructure without having a laptop of the client, so no Service Now access or any other system..

Guess who has to do it in the end..

Many question marks about this project

My phone was stolen so that's why I wasn't getting here to rant about this, but today I had to make a back up and remembered.
adminer's export function doesn't export the tables in the correct order for import. Doesn't take foreign keys into account.
Dude, that's the whole point of a relational database, relations between tables; if you don't take that into account then what's the point?
Is this the same for the rest of database managers or is it just adminer? Please tell me this isn't normal.

Nothing much to ready today, keep scrolling..

I just asked you to keep scrolling, I am using this space to think out loud...

Damn you bloody rebel.. whatever..

Finally after a rough week, festivals, interviews, work stress, and pending tasks, I got a free weekend for myself to be with myself.

I managed to do bare minimum at work. My new line manager isn't quite pleased with how team and I am functioning but whatever.

On Fridays, I usually end the day early and start with personal tasks. I managed to finish some long pending activities.

Today, I was able to do a deep cleaning of digital housekeeping. Sorted some clashes with parents. manage to de-stress and relax my stiff neck muscles.

Apart from that I guess, I am all prepared to interview and get hired for a company on foreign land. I am confident that I can relocate to EU.

And for now, I am actively pursuing two of my hobbies, Music and Finances. I love managing my finances and learning more about technical aspects of audio and listening to more and more music.

I feel happier, relaxed, and calm. Having things under control is such a wonderful feeling.

And I am slowly building a framework to earn, manage, invest, and grow my finances. It's turning out really well. I have setup the base infrastructure.

For music, I have figured the fundamentals and now I will go out buy myself an DAC/AMP to build a portable rig.

This shit is so awesome and makes me happy. I am able to socialise at the end of each day so that keeps me going during the lock-down phase.

I have figured the top key and important things to do at work for my profile and I actually enjoy those.

1. Product discovery - talking to users/customers and finding their pain areas and opportunities to build the solution

2. Product vision/strategy - Dreaming on how the product would evolve and laying out a solid plan to materialise those dreams.

3. Roadmap and prioritisation - this should be self explanatory

4. Success metrics - I really want to get into data and I am getting opportunities to do so. This is super fun. This will help me analyse and show the impact of the what we are building and measuring it while making sure that LT recognises my and my teams' efforts.

I want to and I will excel these 4 keys skills of my profile and be more efficient at my job.

This will give me more time to pursue my hobbies (which will change over time and want to enjoy them the most while I am at them).

Guys, after a rough 2021, the end of the year seems promising with a lot of leaves and short vacation coming up.

Apart from all this, what is more important here is that I got the career and life clarity that I was struggling with for past few months.

For whoever has read till here, YOU ARE BLOODY AWESOME and thank you from the bottom of my heart for being there for me always.

I am grateful to be a part of this community and have awesome friends like you all who have been with me though my ups and downs since 2016.

LOVE YOU ALL :)

I never set foreign keys in development in case I need to wipe or truncate stuff. Fuck you sql

I've been freelancing lately with an agency to develop an android app for their client and at the same time another person is developing the website .

The story begins when I first contacted the web dev to give me access to the database (because he started before me ).It turns out that this guy purchased an almost ready cms template with a shitty data structure that has no relations between object .This database has no primary keys , no foreign keys , no indexes ... no nothing . Adding to that the web dev refused that I rewrite a new data structure claiming that he has done a good progress on the website .
Forward couple of weeks , I managed to create the api and develop an alpha for the app and sent it to the agency manager .
This bastard told me that the website and design have changed and the app shouldn't be like that .He told me to contact the other bastard the web dev to seen what the changes are . I'm waiting for the response about the new updates and I'm praying that they'll be just minor colors updates or something not a whole concept update .

My problem here is I'm stuck with this fucking agency cuz they paid half of the payment when I started .

Damn I must learn to say no to people .

The bugs that make you think are the best/worst.

Had a ghost foreign key constraint from a dropped table. Cant drop it from a non existant table.

Turns out the dev copied a file for the new table and since you can technically name those foreign keys anything you want, there were no errors when he ran it.

Also sloppy/overworked dev teammates are the worst...

Also I'm pretty sure rule 2 of programming is "Never Copy and Paste"

When you work on a project for months, the newly appointed tech lead says "we all (him, the boss and other colleagues not involved in this project) looked at your code and decided that it should be dropped and we are starting from scratch again....now I'm not against code review (which we never did) so I welcome the input but allow me to vent my frustrations about how this is being done. Also to have a review & verdict without me being present?

So I ask what was so wrong:
* You changed the database structure. Valid, I tried to make your db an actual db with relationships, so I added some foreign keys, delete fields that were never used, all because they told me to use an ORM.
* You used to much logic in setters, validation etc, valid again but this would be something we could look at and fix imho.
* You are passing classes in your constructor, valid I wanted to use DI to make unit testing possible. Ohh but I don't like unit testing so I don't see the point and it makes it to complicated was the response.

So not only was the project cancelled, the new iteration is being developed without me, I'm shunned from all meetings. Ohh and from what I see they are now using 5 tables instead of 25 and completely started the db model from scratch...

FUCKING SHIT, I HATE THIS

Does anyone have problems with axios?

I've been trying to make this work for at least 1 hour. If I use Postman, it works alright, but using axios messes it up.

Practically what happens it's that Django does not picks the foreign keys, it loads all the fields except those two.

I've been like fucking crazy trying to understand what's going on but to no avail... I want to die, it's friday and this stupid thing is delaying me more than it should

(tldr: are foriegn keys good/bad? Can you give a simple example of a situation where foriegn keys were the only and/or best solution?)

i have been recently trying to make some apps and their databases , so i decided to give a deeper look to sql and its queries.

I am a little confused and wanted to know more about foreign keys , joins and this particular db designing technique i use.

Can anyone explain me about them in a simpler way?
Firstly i wanted to show you this not much unheard tecnique of making relations that i find very useful( i guess its called toxi technique) :
In this , we use an extra table for joining 2 tables . For eg, if we have a table of questions and we have a table of tags then we should also have a table of relation called relation which will be mapping the the tags with questions through their primary IDs this way we can search all the questions by using tag name and we can also show multiple tags for a question just like stackoverflow does.

Now am not sure which could be a possibile situation when i need a foriegn key. In this particular example, both questions and tags are joined via what i say as "soft link" and this makes it very scalable and both easy to add both questions and new tags.

From what i learned about foriegn keys, it marks a mandatory one directional relation between 2 tables (or as i say "hard a to b" link)
Firstly i don't understand how i could use foriegn key to map multiple tags with a question. Does that mean it will always going to make a 1to1 relationship between 2 tables( i have yet to understand what 11 1mant or many many relations arr, not sure if my terminology is correct)

Secondly it poses super difficulty and differences in logics for adding either a tag or question, don't you think?
Like one table (say question) is having a foreign key of tags ID then the the questions table is completely independent of tag entries.

Its insertion/updation/deletion/creation of entries doesn't affect the tags table. but for tag table we cannot modify a particular tag or delete a tag without making without causing harm to its associated question entries.
if we have to delete a particular tag then we have to delete all its associated questions with that this means this is rather a bad thing to use for making tables isn't it?

I m just so confused regarding foriegn keys , joins and this toxi approach. Maybe my example of stack overflow tag/questions is wrong wrt to foreign key. But then i would like to know an example where it is useful