What do vegetarian SQL users have for lunch?

VegeTABLES

3 SQL Databases went into a NoSQL Bar.
After a while, they walked out because
.
.
They couldn't find tables there.

TL;DR :

"when i die i want my group project members to lower me into my grave so they can let me down one last time"

STORY TIME

Last year in College, I had two simultaneous projects. Both were semester long projects. One was for a database class an another was for a software engineering class.

As you can guess, the focus of the projects was very different. Databases we made some desktop networked chat application with a user login system and what not in Java. SE we made an app store with an approval system and admin panels and ratings and reviews and all that jazz in Meteor.js.

The DB project we had 4 total people and one of them was someone we'll call Frank. Frank was also in my SE project group. Frank disappeared for several weeks. Not in class, didn't contact us, and at one point the professors didn't know much either. As soon as we noticed it would be an issue, we talked to the professors. Just keeping them in the loop will save you a lot of trouble down the road. I'm assuming there was some medical or family emergency because the professors were very understanding with him once he started coming back to class and they had a chance to talk.

Lesson 1: If you have that guy that doesn't show up or communicate, don't be a jerk to them and communicate with your professor. Also, don't stop trying to contact the rogue partner. Maybe they'll come around sometime.

It sucked to lose 25% of our team for a project, but Frank appreciated that we didn't totally ignore him and throw him under the bus to the point that the last day of class he came up to me and said, "hey, open your book bag and bring it next to mine." He then threw a LARGE bottle of booze in there as a thank you.

Lesson 2: Treat humans as humans. Things go wrong and understanding that will get you a lot farther with people than trying to make them feel terrible about something that may have been out of their control.

Our DB project went really well. We got an A, we demoed, it worked, it was cool. The biggest problem is I was the only person that had taken a networking class so I ended up doing a large portion of the work. I wish I had taken other people's skills into account when we were deciding on a project. Especially because the only requirement was that it needed to have a minimum of 5 tables and we had to use some SQL language (aka, we couldn't use no-SQL).

The SE project had Frank and a music major who wanted to minor in CS (and then 3 other regular CS students aside from me). This assignment was make an app store using any technology you want. But, you had to use agile sprints. So we had weekly meetings with the "customer" (the TA), who would change requirements on us to keep us on our toes and tell us what they wanted done as a priority for the next meeting. Seriously, just like real life. It was so much fun trying to stay ahead of that.

So we met up and tried to decided what to use. One kid said Java because we all had it for school. The big issue is trying to make a Java web app is a pain in the ass. Seriously, there are so many better things to use. Other teams decided to use Django because they all wanted to learn Python. I suggested why not use something with a nice package system to minimize duplicating work that had already been done and tested by someone. Kid 1 didn't like that because he said in the real world you have to make your own software and not use packages. Little did he know that I had worked in SE for a few years already and knew damn well that every good project has code from somewhere else that has already solved a problem you're facing. We went with Java the first week. It failed miserably. Nobody could get the server set up on their computers. Using VCS with it required you to keep the repo outside of the where you wrote code and copy and paste changes in there. It was just a huge flop so everyone else voted to change.

Lesson 3: Be flexible. Be open to learning new things. Don't be afraid to try something new. It'll make you a better developer in the long run.

So we ended up using Meteor. Why? We all figured we could pick up javascript super easy.Two of us already knew it. And the real time thing would make for some cool effects when an app got a approved or a comment was made. We got to work and the one kid was still pissed. I just checked the repo and the only thing he committed was fixing the spelling of on word in the readme.

We sat down one day and worked for 4 straight hours. We finished the whole project in that time. While other teams were figuring out how to layout their homepage, we had a working user system and admin page and everything. Our TA was trying to throw us for loops by asking for crazy things and we still came through. We had tests that ran along side the application as you used it. It was friggin cool.

Lesson 4: If possible, pick the right tool for the job. Not the tool you know. Everything in CS has a purpose. If you use it for its purpose, you will save days off of a project.

PM emails me a zip file with the message "Can you give the attached a look and get it to work. See email below that there are some items missing to make it run."

Items missing : 3 custom libraries, 2 sql databases, 3 custom sql tables, and oh yeah the license to the program it runs on.

Got a job as a database manager, they wanted me to update their sql server and some of their .net apps. Turns out their sql server had no databases and all their data was stored in an ms access 2003 applications that was using windows for workgroups security!!! It also had no interface, hundreds of tables and queries and there were multiple access db it was connected to. To make things worse the person who built all this stuff used acronyms for everything he did, table names, variables, queries and even bloody window folders!!! It was hard as hell to figure out what anything ment. Oh and the .net apps were asp sites that heavily used dll for storing his code and no one knows where the original source code for them are. Did I also mention there were no comments for any of the code, no database dictionary, no notes or anything.

So apparently I'll be rebuilding everything from scratch and transferring over the data to sql server. AND NO MORE F**KING ACRONYMS!!!!!!!

Getting real tired of having to reteach the basics of relational databases to the same 2 people. You were brought in as the expert in databases and SQL Server, I shouldn’t have to teach you about effing primary keys, secondary keys, many-to-many relationships, and how to join the damn tables in a basic query. Your 5 years of experience are obviously a waste if all you did was select * from bullshit. This is the 2nd week and 22nd you’ve asked the same damn questions. Get your crap together and study your ass off if you don’t know. Google the error messages if you don’t remember how to solve it before coming to me with the same question a 23rd and 24th time. I’m not going to get any work done if all you do is ninja up behind me with your laptop in tow and just spout off the question that could be done over IM or a quick duckduckgo/google search. Headphones in = do not disturb ya rude mother duckers 🦆.

someone: Why you still have no relationship ?
Me: My DB has one table.

Rant about IT teacher

(This happened a few months ago)

I go to highschool and in ninth grade you learn about Excel and databases in general. In the first half of the year we learned how to use excel and in the second part of the year we learned about SQL databases.
So we learned SQL and how to set up a database using LibreOffice Base. At the end of the year we had to do one final project which was setting up a database and writing some queries.
We had to do it in groups of two and we had to choose for what we wanted to make a database.
We had like 5 minutes time to discuss it in the groups and me and my friend decided to do something like GitHub, so a database with tables for all the users, repositories, etc.
Then we had to tell our teacher what we wanted to do. Others made databases for hospitals, shops, netflix, app stores. The teacher asked the other groups, they told him what they wanted to do and he wrote it down. Here is how it went down with my group:
Teacher: So what do you want to do?
Me: A database for something like GitHub
Teacher: For what?
Me: GitHub
Teacher: what?
Me (very slowly): G I T H U B
Teacher: what is github?
Me: ...
(I was very surprised that he didn't know GitHub)
Me: well, you can upload files and work on them together with other people. There are also things like branches...
Teacher: Ah ok, so a cloud service
(I was done and wanted to end the conversation)
Me: Yes... it's a cloud service...
(Me in my mind: why do i have to be here)

We named our project 'GitGud', a little bit passiv aggresive.

Yeah so apparently my IT teacher doesn't know GitHub, however he installed Ubuntu on some of the school computers so I guess that's nice

We got an A so that's good.

More and more, I am getting frustrated/depressed from the attitude of our customers who complain, moan and get angry about issues in their infrastructure, while at the same time, refusing to pay more so the issues could be mitigated.

Like, a client's angry with us today for having one of their non-production-critical databases inaccessible for... Hmm... About 8 hours now (So a whole workday).

Like... I get it, some of your employees couldn't work with it offline, but like... What the hell do we do? You keep data from as far back as several years ago in there, without partitioning, without exports, in a mix of innodb and myisam, so when the DB crashes, and its replication has to be reset from zero, reimporting all the data takes hours upon hours, and importing .sql files just takes time.

Or another client who got angry when their app fell out of the internet, cuz one of their myisam-based log tables crashed, and had to be repaired, with data spanning several years back, meaning it took hours to fix...

The more I work with these "basic" and "simple" infrastructure designs that is *not* redundant, or HA, the more I wonder -- How do the big names out there do it? How do you design systems with fault tolerance so a single DB table crash doesn't lead to the whole app getting inaccessible?

We have... One, exactly one, client, who uses MariaDB with Gallera, and that cluster is *amazing*, it just keeps chugging along, without a care in the world. But it cost them quite a lot, as they had to buy 3 DB servers, instead of 1...

So i have been thinking..
SQL is a lang that runs on a specific software on the server, and helps creating data stores(databases and tables) that can be queried & manipulated.

is there a way to run sql like queries on the client side with no interaction from backend at all?

Say i have 5 inter related data models. in a backend world, they will form nice little tables of a db with all their joins and composite keys. from the server, i shall be querying them like "SELECT name from x where y=z & ..."

but what if i could store them like tables in browser memory and run the same query filters via a query language... is this possible?

i know this poses a certain security risk, but we already use cookies, local storage and a lot of json based shitty client side storages. surely it might be possible to have a lesser optimised sql tables on the frontend with extremely good querying capabilities?

or am i talking something far fetched here?

We had a course on GUI and Databases as part of my bachelor's degree. It was a basic introductory course (I am a mechanical engineer) where we were expected to design some tables and build a simple front end in VB6.

But the instructor was so bad that he hardly taught any VB code at all. And as far as theory on databases was concerned, about 80 percent of the lectures involved some generic introductory statements followed by an explanation of the terms DDL, DML and DCL. I do not remember him writing even a single SQL query to explain to us how it's done.

I like the people I work with although they are very shit, I get paid a lot and I mostly enjoy the company but..

Our scrum implementation is incredibly fucked so much so that it is not even close to scrum but our scrum master doesn't know scrum and no one else cares so we do everything fucked.

Our prs are roughly 60 file hangers at a time, we only complete 50% of our work each sprint because the stories are so fucked up, we have no testers at all, team lead insists on creating sql table designs but doesn't understand normalisation so our tables often hold 3 or 4 sets of data types just jammed in.

Our software sits broken for months on end until someone notices (pre release), our architecture is garbage or practically non existent. Our front end apps that only I know the technology have approaches dictated by team lead that has no clue of the language or framework.

Our front end app is now about 50% tech debt because project management is so ineffectual and approaches are constantly changing. For instance we used to use view models for domain transfer objects... Now we use database entities, so there is no commonality between models but the system used to have shared features relying on that..sour roles and permissions are fucked since a role is a page regardless of the pages functionality so there is no ability to toggle features, but even though I know the design is fucked I still had to implement after hours of trying to convince team lead of it. Fast forward a few months and it's a huge cluster fuck to enforce.

We have no automated testing of any sort or manual testing in place.

I know of a few security vulnerabilities I can nuke our databases with but it got ignored.

Pr reviews are obviously a nightmare since they're so big.

I just tried to talk to scrum master again about story creation since any story involving front end ui as an aspect of it is crammed in under one pointed story as sub tasks, essentially throwing away any ability to calculate velocity. Been here a year now and the scrum master doesn't know what I mean by velocity... Her entire job is scrum master.

So anyway I am thinking about leaving because I like being a developer and it is slowly making me give up on doing things to a high standard and I have no chance of improving things, but at the same time the pay is great and I like the people.

I took over an application that consisted of 4 MSSQL (2005 at the time) databases, hundreds of tables, thousands of stored procedures, maybe a 1/4 of them actual still being used, external links to more than 20 other databases (MSSQL, Oracle and DB2) which all ran from a single "master" stored proc that was kicked off nightly by scheduled job.

The existing documentation consisted of a single word document, about three pages long, describing how to set up the application... on the Sql Server 6 server it had been originally created on two generations ago.

We ended up finding ourselves with a bunch of tables that have mostly the same columns, but differ by a few. Every time we consume a REST API, we store the `access_token`s and expiration dates and the other OAuth data. However, each provider has slightly different requirements. For example, we store email addresses for email api's, other providers require us to store some additional information, etc. etc.. I'm tempted by the flexibility and lack of schema brought by document databases, but not enough to use one since they're generally slower and we already have everything in SQL. So I got the idea of using JSON columns to alleviate this issue: have a single table for all REST integrations (be it outlook or facebook), and then store the unique integration data inside of this JSON column for "additional data". This data is mostly just read, not filtered by (but ocasionally so). Has anyone had experience with this? How's the performance of JSON fields? Is this a good practice or will it get harder with more integrations?

So, this backend dev, thinks because I am doing frontend work I have no knowledge on backend stuff.

I ask him for a backend feature to match my front end feature. He says that that will take about 4 weeks and therefore cannot be included in this scope. I ask why because its something really easy. He says he'd have explained but I cannot get it.

So I ask him why they have their tables structured that way (I went in and checked ). I then went ahead and schooled the guy on SQL, normalizing databases and other stuff.

Put some respect on frontend devs. some of us are fullstack

(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