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

51–60 of 588 posts

Re: "We ran out of columns"

#51

Post by nolist_policy »

marcosdumay wrote: post #34
surfingdino wrote: post #27

I had dubious pleasure of working with similar codebases and devs. I'll remember one of those guys forever, because whenever he wanted to work on a new branch he would clone the repo, make changes to the master branch, and push code to a new repo numbered repo0001, repo002, ... He refused to change his ways, because "I have a PhD so you are wrong". Another WTF moment was realisation that MS SQL Server does not suppor…

> Another WTF moment was realisation that MS SQL Server does not support BOOLEAN type. The standard does not have a boolean type. It's a postgres extension that the other open source databases adopted (because, yeah, it's obvious). But the proprietary ones insist on not having. The official recommendation is using byte on MS SQL and char(1) on Oracle. Both are ridiculous.

C programmer joins the chat.

Re: "We ran out of columns"

#52

Post by airstrike »

collinvandyck76 wrote: post #18
mnahkies wrote: post #13

Earlier quoted context omitted.

I think the intriguing part was purposefully using the same sequence value for rows in multiple tables. I've worked with globally unique (to our application) integer keys, and per table integer sequences (which obviously aren't globally unique), but I don't recall seeing anyone use a global sequence but purposefully reuse elements of the sequence before.

I've seen this fairly recently and I was surprised to also see it in this article because I think that makes it twice that I've seen it in ~25 years.

They may even be the same codebase!

Re: "We ran out of columns"

#54

Post by zo1 »

layer8 wrote: post #30
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…

> remodeling data types and schemas (which you often do as you build an application, whether or not you thought of a great schema beforehand) This is not my experience, it only happens rarely. I’d like to see an analysis of what causes schema changes that require nontrivial migrations.

Same here. If your entities are modelled mostly correctly you really don't have to worry about migrations that much. It's a bit of a red herring and convenient "problem" pushed by the NoSQL camp.

On a relatively neat and well modelled DB, large migrations are usually when relationships change. E.g. One to many becomes a many to many.

Really the biggest hurdle is managing the change control to ensure it aligns with you application. But that's a big problem with NoSQL DB deployments too.

At this point I don't even want to hear what kind of crazy magic and "weird default and fallback" behavior the schema less NoSQL crowd employs. My pessimistic take is they just expose the DB onto GraphQL and make it front ends problem.

Re: "We ran out of columns"

#55

Post by jvans »

PreInternet01 wrote: post #40
jsonis wrote: post #16

Earlier quoted context omitted.

> These days, my go-to solution is SQLite with two fields (well, three, if you count the implicit ROWID, which is invaluable for paging!): ID and Data, the latter being a JSONB blob. Really!? Are you building applications by chance or something else? Are you doing raw sql mostly or an ORM/ORM-like library? This surprises me because my experience dabbling in json fields for CRUD apps has been mostly trouble stemming f…

> my experience dabbling in json fields for CRUD apps has been mostly trouble stemming from the lack of typechecks Well, you move the type checks from the database to the app, effectively, which is not a new idea by any means (and a bad idea in many cases), but with JSON, it can actually work out nicely-ish, as long as there are no significant relationships between tables. Practical example: I recently wrote my own S…

why is a migration such a burden in that scenario

Re: "We ran out of columns"

#56

Post by mikeocool »

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 recall something similar from my first job, except the shared file locking was a full on feature in Macromedia dreamweaver.

CSS was just starting to get adopted and every project we worked on just had one “gobal.css” file. When someone else had global.css locked, you’d call dibs if you needed it next. Inevitably, everyday someone would leave the office and forget to unlock global.css and no one else could get anything done.

Re: "We ran out of columns"

#57

Post by Vampiero »

PreInternet01 wrote: post #40
jsonis wrote: post #16

Earlier quoted context omitted.

> These days, my go-to solution is SQLite with two fields (well, three, if you count the implicit ROWID, which is invaluable for paging!): ID and Data, the latter being a JSONB blob. Really!? Are you building applications by chance or something else? Are you doing raw sql mostly or an ORM/ORM-like library? This surprises me because my experience dabbling in json fields for CRUD apps has been mostly trouble stemming f…

> my experience dabbling in json fields for CRUD apps has been mostly trouble stemming from the lack of typechecks Well, you move the type checks from the database to the app, effectively, which is not a new idea by any means (and a bad idea in many cases), but with JSON, it can actually work out nicely-ish, as long as there are no significant relationships between tables. Practical example: I recently wrote my own S…

> Well, you move the type checks from the database to the app, effectively, which is not a new idea by any means (and a bad idea in many cases), but with JSON, it can actually work out nicely-ish, as long as there are no significant relationships between tables.

That way you're throwing away 50% of the reason you use a relational database in the first place. Has it occurred to you that MongoDB exists?

Also I don't understand why you're afraid of migrations, especially since you're the only developer on your own SMTP server.

Re: "We ran out of columns"

#58

Post by cjbgkagh »

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…

So they had a problem, got 2 years of approved development effort of a small team to solve it property which they did successfully, and then you resigned? After they fixed the problem?

Of course where they started was just awful but a place that recognized it's problems, commits to fixing it, and has sufficient competency to actually fix it sounds rather nice to me. Many orgs get stuck at step 1.

I presume there were other reasons for resigning, or you just like massive refactoring projects.

Re: "We ran out of columns"

#59

Post by dvdkon »

JadeNB wrote: post #29
dvdkon wrote: post #26

Earlier quoted context omitted.

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…

> Not 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. Is that "not" at the front supposed to be there?

Thanks, edited.

Re: "We ran out of columns"

#60

Post by werdnapk »

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.
Post reply on HN