Live data from Hacker News

A terrible schema from a clueless programmer

rachelbythebay.com

411–420 of 493 posts

Re: A terrible schema from a clueless programmer

#411
post #337
post #268

Earlier quoted context omitted.

As I said already: "mysql could index strings" and "using a compound index over four varchar columns would've worked out well" are significantly different propositions. To be more verbose about it - there is an important difference between "can be created" and "will perform sufficiently well on whatever (likely scavenged) hardware was assigned to the internal IT system in question." I wouldn't be surprised if the "se…

you know for performance the new table would've needed a string index aswell?

A single-column string index is a different beast to implement compared to a multi-column varchar index.

Re: A terrible schema from a clueless programmer

#412
https://invincivlepvt.com/google-my-business-jalandhar/" rel="nofollow">Google My Business https://invincivlepvt.com/google-my-business-jalandhar/" rel="nofollow">Google My Business Jalandhar https://invincivlepvt.com/google-my-business-jalandhar/" rel="nofollow">Digital Marketing https://invincivlepvt.com/google-my-business-jalandhar/" rel="nofollow">Online Business Listing https://invincivlepvt.com/google-my-business-jalandhar/" rel="nofollow">Google My Business Service https://invincivlepvt.com/google-my-business-jalandhar/" rel="nofollow">Google My Business Service In Jalandhar https://invincivlepvt.com/google-my-business-jalandhar/" rel="nofollow">Google My Business Agency https://invincivlepvt.com/google-my-business-jalandhar/" rel="nofollow">Google My Business Agency Jalandhar https://invincivlepvt.com/google-my-business-jalandhar/" rel="nofollow">Digital Marketing Jalandhar

Re: A terrible schema from a clueless programmer

#413

Earlier quoted context omitted.

I feel like that phrase has been there forever, and I'm exactly 35. Will this happen more often as I grow older? Ugh. Feels weird. Maybe also a bit depressing.

It was weird seeing all the spongebob squarepants memes take over the internet when I was too old to ever grow up with that. I turned 28 in 1999 when that first aired. That was my "holy shit I'm so old" moment when that finally trickled up into my awareness as someone nearly turning 40 or so.

As a 48 year old who has no idea who an awful lot of modern celebrities are, I'm constantly wondering if it is because I'm just old now or if its because there are just way more celebrities these days due to the large parasocial celebrity class that didn't really exist when I was younger.

Maybe a bit of both.

Re: A terrible schema from a clueless programmer

#414

One of the most useful lessons I ever learned about designing database schemas was the utter uselessness of indexing and searching on datetime fields. Since virtually every value is going to be different, indexing and searching on that field is (almost) no better than having no index on the datetime field at all. It was a revelation to me when I decided to experiment with having a indexed date-ONLY field and using th…

If you were doing something like this then your story makes sense

`WHERE state_date > x AND end_date You can't index two ranges at once in a b tree!

Re: A terrible schema from a clueless programmer

#415

I'd really love to be snarky here but I'll try to be polite: all those comments about the example situation are missing the whole point of the post. And it really worries me that there is a good chunk of the tech workers that just ignores the real meaning of something and just nitpick about stupid implementation details. The post is about managing rookie errors, being empathetic and also warn the ageism that pervades…

As a 48 year old who lives in San Diego (so not Silicon Valley but geographically much closer than Europe) and still works as a programmer and who still enjoys coding and continually fights any attempt to put me into any sort of management role...

I think ageism is a valid concern but its also not a black and white issue because while I know quite a few older folks like me that are still constantly keeping up to date I've also known some people my age or just a little bit older who basically stagnated into irrelevance as experts in now discarded technology who never really moved on, so the line between what is ageism and what is people just not bringing value to the table anymore can be a bit blurry.

I'm by no means trying to suggest ageism isn't an issue in tech, I do see echoes of it when I look around and if I suddenly lost the network of people I work with, have worked with in the past, etc, who understand I'm still very technically 'flexible' for an older person I'm pretty sure it would make it difficult to find a job in the practical sense of getting pre-filtered out often just based on the age thing. So my heart really goes out to people who do find themselves in situations where they are capable but can't find work due to age primarily.

But, uh, the issue is somewhat complicated and very case by case, I think.

Re: A terrible schema from a clueless programmer

#416

> The rub is that instead of just being slow, it also cost a fair amount of money because this crazy vendor system charged by the row or somesuch. So, by scanning the whole table, they touched all of those rows, and oh hey, massive amounts of money just set ablaze! Why _the hell_ is nobody mentioning that using a database that charges per row touched is absolute insanity? When has it become so normal that nobody ment…

You'll probably enjoy reading this article that was on the front page yesterday: https://briananglin.me/posts/spending-5k-to-learn-how-databa...

Thank you. I cannot say I enjoyed it, I am distressed now. Using a “planet scale” “serverless” database to store just 750k download records per day, and paying per DB row touched, and “thank you for letting us off the hook this time”. This reads like satire.

Re: A terrible schema from a clueless programmer

#417

Earlier quoted context omitted.

The one that always got us is much more mundane. Deleting a row requiring an index in every table with a FK to avoid tables scans. Near as I can tell, we assume there is some bit of magic built into the foreign key concept that handles this for us, but that is not the case.

Yeah I’ve run into this a few times. In Postgres, you can’t add a foreign key referencing columns that aren’t indexed. I assume this is for performance reasons so inserts/updates are efficient, but there is no such check that the source columns are also indexed, so updates/deletes on the referenced table can be terribly slow.

Isn’t the source almost always an indexed primary key?

Re: A terrible schema from a clueless programmer

#418
I'm probably going to get smacked a bit for this but a lot of the comments here focus on a better fix for the 20 year old problem the author relates only in order to illustrate a point and that's a very HN kind of response. And I get it.

Years ago someone ask one of my grandkids what I did for a living and he told them "He's a fix it guy". That's because when he'd come over I'd be working on something and he'd ask what I was doing and I'd tell him "I'm fixing" this or that.

There are a lot of "fix it" people here. It's what we do.

Re: A terrible schema from a clueless programmer

#419

I'd really love to be snarky here but I'll try to be polite: all those comments about the example situation are missing the whole point of the post. And it really worries me that there is a good chunk of the tech workers that just ignores the real meaning of something and just nitpick about stupid implementation details. The post is about managing rookie errors, being empathetic and also warn the ageism that pervades…

There's probably also some sense of people trying to paint the lesson of "sometimes rookie errors aren't actually errors, and your seniors will tell you you're doing something wrong, when in actuality their solution is worse than what you came up with."

Which I guess is saying the article's setup story makes the exact opposite point that it's trying to?

Post reply on HN