Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"We ran out of columns"

jimmyhmiller.github.io

Post reply on HN
Print view View original

291–300 of 588 posts

Re: "We ran out of columns"

#291

Post by magicalhippo »

zo1 wrote: post #74
magicalhippo wrote: post #61

Earlier quoted context omitted.

Why is that worse than a couple of dozen joins?

Because that means your data is highly denormalized and has plenty of duplicates. But in all likelihood it means no one knows wtf this table actually represents and you should be firing people. I've seen this play out. Usually the many columns is because everyone misuses the table and eventually their special little business scenario or "filter" needs to be a column. Bonus points is whoever has to reference this tabl…

> But in all likelihood it means no one knows wtf this table actually represents and you should be firing people.

That's almost exactly the opposite of my experience, but then I've worked on smaller teams with long-term team members, so perhaps that's why.

Our tables are wide because law require we store the data for 10 years, and it's easier and faster to store things in a single row, rather than spread out over several dozen detail tables.

We don't denormalize in the sense of storing only invoice items, repeating the head data on each item. We do denormalize in the sense of storing full name and address for each party rather than storing that in a detail table. So minimal, if any, duplication of data. If we duplicate it's almost always due to the law, ie data might change in one table but shouldn't be changed in the other to preserve history.

For child tables we always have a unique ID, sequence or autoinc, and the FK to the parent, but we include the root-level ID as well. This way we can select all the child rows in a single select regardless of level, again without tons of joins.

This way our core data is just a handful of tables, and there's not much doubt about what goes where.

Re: "We ran out of columns"

#292

Post by Aloha »

blacklight wrote: post #205
fouronnes3 wrote: post #130

Earlier quoted context omitted.

This is amazing. I can so well imagine a bright young hire joining that team, helpfully offering to "setup this thing called git" only to be laughed out of the meeting by all the "senior" staff.

Been there. There was this old fashioned developer in one of the companies I worked for a decade ago who never understood nor embraced version control (we were talking of SVN at the time, not even git). Luckily that wasn't the case for all the others developers in the company. But when it came to the projects he owned, I witnessed several scenes along the lines of "hey, customer X has an issue with your component Y,…

He was in essence doing manual version and release control - just.. like you would in 1990 with floppy disks.

Re: "We ran out of columns"

#293

Post by gouggoug »

I worked many years with an open source eCommerce platform called Magento[0] which, at the time, used something called the "Entity Attribute Value" (or EAV) system[1].

One particularity of the EAV system is that you end up having tables with hundreds (and growing) of columns. It made Magento itself extremely hard to work with and optimize. I hope they moved away from this model since.

To be fair, this was before nosql databases were a thing.

[0]: https://en.wikipedia.org/wiki/Magento

[1]: https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80...

Re: "We ran out of columns"

#295

Post by jaggederest »

scythmic_waves wrote: post #44
ibejoeb wrote: post #28

Earlier quoted context omitted.

Yeah, a good database is pretty damn handy. Have you had the pleasure of blowing young minds by revealing that production-grade databases come with fully fledged authnz systems that you can just...use right out of the box?

Can you say more? I’m interested.

Here's a vendor, but the underlying functionality is shipped with Postgresql server

https://supabase.com/docs/guides/database/postgres/row-level...

Re: "We ran out of columns"

#296

Post by MBCook »

rblatz wrote: post #249
llmblockchain wrote: post #160

Earlier quoted context omitted.

I've been that person a few times. 1. The only developer on the team with Github and put forward the idea of the company not hosting their own source code with TFS. 2. The only developer using branches with git when the co-founder asked (demanded) everyone to only use master. The list goes on!

There are advantages to trunk based development, not exactly only using master, but close enough that you could probably spin it to comply.

A friend’s company was still doing it (in SVN) as of late last year. Quite possibly still are. It’s “what they’ve always done”.

Re: "We ran out of columns"

#298

Post by teractiveodular »

kwhitefoot wrote: post #207
fouronnes3 wrote: post #130

Earlier quoted context omitted.

This is amazing. I can so well imagine a bright young hire joining that team, helpfully offering to "setup this thing called git" only to be laughed out of the meeting by all the "senior" staff.

Some of these stories sound a bit far fetched, especially those that involve Unix systems. RCS was released in 1982 and CVS in 1990 so Unix systems have had version control available for over forty years.

In the late 2000s, I worked at $MAJOR_TELCO where management steadfastly refused to implement version control. Upgrades in production were executed by individually SSHing into each physical machine in the prod cluster and typing in commands by hand.

My attempt to introduce a "multissh" tool that automatically executed the same commands in each node at once was regarded with the highest suspicion and shot down. Shortly after I left, they had a multi-week outage caused by somebody fat-fingering the permissions on a network interface.

Re: "We ran out of columns"

#299

Post by celrod »

jimbokun wrote: post #241
gumby wrote: post #211

Earlier quoted context omitted.

Astonishingly, It took a long time for revision control to become widespread. Around 1991 when Cygnus had 6-7 employees and was based in the apartment complex where I lived, none of the GNU codebase was hosted in any sort of revision control. Everything was FTPed around as obscurely named tarballs. We had gathered something like 27 different forks of gdb floating around the net, for example. This was back when forkin…

> Pixley agreed to all of that and then ignored all of it completely. Hahaha that's brilliant, and an important lesson for junior developers. Sometimes this is the best way forward. High risk of course. But the reward can be great.

I don't think you'd even necessarily need to ignore. Roll it out in phases. You aren't going to have to deliver the final finished solution all at once.

Some elements are inevitably going to end up being de-prioritized, and pushed further into the future. Features that do end up having a lot of demand could remain a priority.

I don't think this is even a case of "ask for forgiveness, not permission" (assuming you do intend to actually work on w/e particular demands if they end up actually continuing to demand it), but a natural product of triage.

Re: "We ran out of columns"

#300

Post by geysersam »

hinkley wrote: post #96
dmd wrote: post #77

Probably some of the worst code I ever worked on was a 12k+ line single file Perl script for dealing with Human Genome Project data, at Bristol-Myers Squibb, in the late 1990s. The primary author of it didn't know about arrays. I'm not sure if he didn't know about them being something that had already been invented, or whether he just didn't know Perl supported them, but either way, he reimplemented them himself on t…

We should use the Antarctic highlands as a prison colony for people found guilty of writing Stringly Typed Code. Siberia isn’t awful enough for them. I thought people who stuffed multiple independent values into a single database column were the worst and then I saw what people can accomplish without even touching a database.

No we should reserve the antarctic highlands for type system fetischists who write abstract protocol adaptor factory repositories for every damn simple piece of functionality.
Post reply on HN