Poll of the Day > SQL users: My boss

(+) Yeah! (+)

wants me to extract all data from one table into several child tables.

A user table currently exists. It contains all identifying 1:1 relationship data. About 20 columns.

The new tables he wants (even though everything works perfectly fine in its current state) contain so many duplicate fields it is ridiculous. It's like a D- student who barely passed their SQL class designed it. The UserData table will have a first_name middle_name last_name column, so will the address table, as will the bitcoin address table. He also wants all parent tables to contain references to the IDs of all child tables, which is just flat out bad design. Pointless. Unheard of. I understand branching tables out, but ffs do it right.

I am going to lose my mind. This is what I get for trying to explain to him how these things are working. The worst part is I have no feedback or input for him aside from "the suggested changes are total trash", which I don't think I can say.

Fucking crypto bros. It was so simple and sensible, now he's ruining it. I do so much to try to keep this guy at bay from destroying everything he touches. Everything we do I need to come up with a (completely insufficient) visual for him to understand it, but I end up regretting it because he then wants to change how everything works, causing it to work worse and take twice as long to develop.

Dude literally has brain damage or something and man am I a babysitter. I know a crypto startup is an exercise in burning money, I am the dumb one for trying to correct course. I don't know if I can keep my calm on this one. He pretty much jots down a half baked idea without consulting me at all and demands it's all reworked. I'm only human, I only have so much patience here.

Oh, BTW, all of these tables rely on an existing ASP.Net framework that is ALREADY IMPLEMENTED. I am going to rip out the guts of the entire thing for a week, breaking all this default behavior, just to make it worse! I don't know if I can take this.

Every fucking table will have a first_name middle_name last_name field for the user.

If you're wondering why bitcoin destroys everything it touches, it's because crypto-bros are the worst engineers who only masturbate to the idea of understanding how something vaguely complicated works instead of thinking about their own work as a tool that needs to do something.

have you asked why? if you're his employee then it's part of your responsibility to advise him. when people ask me to do stupid things I always explain "I will happily do this for you as long as you first tell me that you understand that I think it's a stupid thing to do and why, or else convince me that it's not actually stupid".

sometimes people know something you don't; and sometimes they are doing things for reasons that they don't want to or can't tell you.

I came off as pretty aggressive but he really is a nice and smart guy. Pretty sure we've both talked each other out of doing dumb things. Not a good topic from me here, not much to comment on, just a wall of mean rant, but I don't think I really meant it. A little embarrassed about it now.

But you're right, I should at least converse about it, and yeah part of my job is to advise and the other part is to keep my mind open to someone else knowing a better way.

Yeah, I was going to suggest maybe offering to streamline it to reduce/remove all duplicate unnecessary data that would lead to slowing down the queries from redundancies. And to see if you could understand what his intention was.

Though some bosses just dont know what theyre doing and didnt become bosses from promotion.

in some cases it can be the right approach to "denormalize" a database for performance reasons. data will become redundant but it will be more easily queried for.

this is rare though, and most of the time should not be done.

it can also be ok to have redundant data when some of the data should reflect the state of things at the time something occurred, and not change later when something is updated.

from your description it's likely neither of these, and he may just not understand how queries work, and/or thinks that joins have a large performance hit and should be avoided. you should explain/demonstrate that given appropriate primary keys and indexes, joins are by far the lesser of two evils, and the problems that emerge from extremely redundant data are not at all worth it, particularly if you will have to spend effort making it that way.

that said, I would still wonder if he knew something I didn't.

recently I was given a query by a company (in past I'm used to dealing with a company that does not know how to program, whereas lately we've been dealing with a significantly more professional and competent company), and the query was extremely redundant. I thought I would be super-smart and refactor it down to remove the duplicated logic.

but this was SQL, and it's not always the same as "normal" programming. it was basically the same query duplicated 12+ times, each with a different set of arguments in the WHERE clauses. I hated the duplication, but then wondered about the WHERE clauses.

normally I would write something like this, for example:

WHERE (@somethingID IS NULL OR somethings.ID = @somethingID)
AND (@somethingElseID IS NULL OR somethingelses.ID = @somethingelseID)
-- etc

you can then pass NULL to get all of something, or an ID to filter to that particular category, department, whatever.

their query was like this (syntax might be slightly off):

IF @somethingID IS NULL AND @somethingElseID IS NULL THEN
BEGIN
SELECT ...
-- all
END

ELSE IF @somethingID IS NOT NULL AND @somethingElseID IS NULL THEN
BEGIN
SELECT ...
WHERE somethings.ID = @somethingID
END

ELSE IF ... --etc

that is horrendously redundant code (there were more like 4+ parameters to check and 12 or more blocks, and there were bugs in it specifically caused by the duplication (they hadn't updated all of the parameter names the right way)

but running some tests, this IS actually (unfortunately) faster than the much more complex WHERE clause. the WHERE clause is iterative, while the IF is not, so moving repeated logic from the WHERE to the IF makes it a lot more efficient. (I would have expected the DB engine (SQL Server) to take care of things like that and not recalculate @somethingID IS NULL more than once, but apparently it does not do that and does repeatedly recalculate it (or I guess at least still compares the key even though TRUE AND ... should short-circuit to true, removing the need to compare each row).)