"We ran out of columns" • Hacker News Board

Re: "We ran out of columns"

#101

Post by arnorhs » Sat, Aug 03, 2024, 4:26 PM UTC

tryauuum wrote: post #47

Would be great to work in such a company as a Linux guru. There are so many entangled services and machines that you feel like an Indiana Jones. You ssh into a machine and feel century-old dust beneath your footsteps. And you never know what will you find. Maybe a service which holds the company together. Maybe a CPU eating hog which didn't do anything useful last 3 years. I don't enjoy writing new code much. But in…

Well it sounded like there are exactly 0 Linux machines running there.. it's all windows .net / c# and a bunch of native windows apps, as I understood the article.

But maybe you can replace your statement with "windows guru" and SSH with "remote desktop" and perhaps that would be fun

Re: "We ran out of columns"

#102

Post by omoikane » Sat, Aug 03, 2024, 4:30 PM UTC

This codebase sounds like a haunted graveyard[1], where everyone just fixes their local corner of things and avoid the risk of untangling the existing mess.

Not needing to conform to some company-wide standard is probably really pleasant while it lasted, but every such effort adds to the haunted graveyard, and the lack of consistency will eventually come back to bite whoever is still around.

[1] https://www.usenix.org/sites/default/files/conference/protec...

Re: "We ran out of columns"

#103

Post by pelagicAustral » Sat, Aug 03, 2024, 4:30 PM UTC

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…

I feel you... I mean "...you should be firing people", this is my day to day way of thinking.

My thoughts are that, hyper-specialization, and grind breed this type of data structure. But so many companies are forced to choose, and generally tend to sacrifice on the database side of things. Then you end up with this type of unruly structure.

Database theory and practice should be a MUST on all software development courseware.

Re: "We ran out of columns"

#104

Post by chrisldgk » Sat, Aug 03, 2024, 4:30 PM UTC

dvdkon wrote: post #26

chrisldgk wrote: post #23

Earlier quoted context omitted.

I actually love your approach and haven’t thought of that before. My problem with relational databases often stems from the fact that remodeling data types and schemas (which you often do as you build an application, whether or not you thought of a great schema beforehand) often comes with a lot of migration effort. Pairing your approach with a „version“ field where you can check which version of a schema this rows d…

Having to write and perform migrations for every small schema change is a bore, but it means your software doesn't have to worry about handling different versions of data. Going "schemaless" with version numbers means moving code from "write-and-forget" migrations to the main codebase, where it will live forever. I think not doing database migrations only makes sense when you can make do without version numbers (or i…

You’re correct there. I mostly work on CMSes with page builder functionality, which often bake the content schema into the database columns, which makes changing that schema (for new frontend features or reworking old ones) difficult and often prone to losing content, especially in dev environments. Best case is obviously that you never have to version your changes, but I‘d prefer making a new schema and writing an adapter function in the codebase depending on the schemas version to spending a lot of time migrating old content. That might just be due to me not being too comfortable with SQL and databases generally.

Re: "We ran out of columns"

#105

Post by telgareith » Sat, Aug 03, 2024, 4:31 PM UTC

werdnapk wrote: post #60

Nexialist wrote: post #31

My worst codebase story: In my first real job, I worked for a company that maintained a large legacy product programmed in a combination of COBOL and Java. In order to work on the Java side of the product, you checked out individual files from source control to work on, which 'locked' the files and prevented other developers from checking out the same files. This functionality was not part of our actual source contro…

Visual SourceSafe would show that a file was checked out hinting to maybe stay away. Good times.

Did you know, theres a GitHub repo called [you-poor-bastard](https://github.com/SirkleZero/you-poor-bastard)? It converts a vss repo to git (not very well, but well enough), ignoring the VSS "passwords."

Re: "We ran out of columns"

#106

Post by brunoarueira » Sat, Aug 03, 2024, 4:31 PM UTC

Once not long enough, I'd worked on 4 projects which was literally copied from the first made and changed parts of the customers and internal users according to each use of it. So, the main problem is bugs found in one project was found on the other 3 and I'd to fix the same bug!

Codebases like this or from the OP is cool to learn how to not do certain things.

Re: "We ran out of columns"

#107

Post by mg » Sat, Aug 03, 2024, 4:32 PM UTC

That is why people these days tend to use a single JSON blob instead of multiple columns. And because it is so popular, SQLITE and other DBs are building better and better JSON support into the DB.

I wonder if better support of EAV tables would solve this issue better.

If one could do "SELECT price,color,year FROM cars! WHERE status='sold'" and the "!" would indicate that cars is an EAV table ...

    entity attribute value
    1      price     20750
    1      color     red
    1      year      2010
    1      status    sold

... and the result of the query would be ...

    20750 red 2010

That would solve most of the use cases where I have seen people use JSON instead.

Re: "We ran out of columns"

#108

Post by telgareith » Sat, Aug 03, 2024, 4:34 PM UTC

First real job, stayed for 10yrs, 5yrs too long, put VB6 COM objects into the asp.net codebase.

Re: "We ran out of columns"

#109

Post by arnorhs » Sat, Aug 03, 2024, 4:34 PM UTC

I really love these kinds of stories. Does anybody know if there's a collection of similar stories/code bases anywhere?

I guess there is dailywtf but that's mostly bugs. Probably good enough though

Re: "We ran out of columns"

#110

Post by wredue » Sat, Aug 03, 2024, 4:35 PM UTC

Nexialist wrote: post #31

My worst codebase story: In my first real job, I worked for a company that maintained a large legacy product programmed in a combination of COBOL and Java. In order to work on the Java side of the product, you checked out individual files from source control to work on, which 'locked' the files and prevented other developers from checking out the same files. This functionality was not part of our actual source contro…

I’ve worked on “check out” code bases very similar to this. I mean. Nothing so insane as scripts patching class files in to jars Willy nilly, but it seems the “just check out a file so nobody else can work on it” thing is a “common” “solution” to this.

I am interested in how you managed it when someone had to hold code for years (as I’ve seen)? Basically, we also had a way to share control with one other person, and the person who was taking the second source were responsible for updating both versions at the same time manually (which never happened, so implementing a large project that touched hundreds of source files had to dedicate a couple weeks to manually hand comparing files, manually implementing the changes, and then manually retesting)