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

81–90 of 588 posts

Re: "We ran out of columns"

#81

Post by bdcravens »

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.

Pedantic, but the type is bit in MSSQL.

Re: "We ran out of columns"

#82

Post by ssdspoimdsjvv »

_elf wrote: post #12
cowsandmilk wrote: post #4

He acts like sequence key is odd, but that’s quite normal in database world. https://www.postgresql.org/docs/current/sql-createsequence.h...

Databases have built-in features for this now. What the author is talking about is a regular table. In reality, that wasn't too unusual to see because frameworks would use that technique because it's a lowest common denominator across RDMS.

Does SQLite have sequences yet?

Re: "We ran out of columns"

#83

Post by lemme_tell_ya »

My first day at my first full-time programming gig, I was asked to look at some reporting job that had been failing to run for months. I logged in, found the error logs, found that it needed a bit more memory assigned to the script (just a tweak in the php.ini) and let the team lead know it should run fine that night. He was shocked, "Dude, if you just fixed that report you probably just got a promotion, no one has been able to figure that out for months." He was joking about the promotion, but my boss was just as shocked. I'd realize later that most the other people on the dev team didn't like linux and wanted to rewrite everything in .NET and move everything to Windows so no one even tried with anything related to any of the linux machines.

Re: "We ran out of columns"

#85

Post by qxmat »

Jira's now discontinued server version had a sequence table to stop you sharding it. It also made disaster recovery from a hard shutdown awful. I have nothing good to say about Atlassian.

Re: "We ran out of columns"

#86

Post by mrighele »

> Now the story I heard at the time was that once upon a time SQL Server didn't support auto-incrementing ids. This was the accepted, correct answer.

At a company that I used to work, they heard the same rumor, so instead of using identity columns or sequences, they kept a table with a number of ids "available" (one row per id). Whenever unique id was needed, the table would be locked, an id selected and marked as used. If there were no ids available, more ids would be added and then one used. A scheduled job would remove ids marked as used from time to time. Note that there was a single "sequence table", that was shared among all of the entities.

That was not even the weirdest part. That id was unique, but NOT the primary key of the entity, only part of it.

The structure of the database was fairly hierarchical, so you had for example a table CUSTOMER in 1-to-many relation with a USER table, with a 1-to-many relation with an ADDRESS table.

while the primary key of the CUSTOMER table was a single CUSTOMER_ID column, the primary key of the USER table was (CUSTOMER_ID,USER_ID), and the primary key of the ADDRESS table was (CUSTOMER_ID,USER_ID,ADDRESS_ID). There were tables with 5 or 6 columns as a primary key.

Re: "We ran out of columns"

#87

Post by bdcravens »

A couple of weeks ago I had a flat on the way to the airport. It was a total blowout, and my car doesn't include a spare. We were already over budget on our trip, so I had the car towed to the closest tire shop and had them put on the cheapest tire that could get me to the airport. I know I'll need to replace other tires, as it's an AWD, and I know it's not a tire I really want. I made a calculated choice to make that a problem for future me due to the time crunch I was under.

Programming is a lot like this.

Re: "We ran out of columns"

#88

Post by itsameputin »

dezsiszabi wrote: post #79
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…

That's a very impressive achievement, reducing that to around 200 lines. Congrats :)

Well the lines could very well be 1000s of bytes long. Perl oneliners used to be a thing in a company that I used to work for.

Re: "We ran out of columns"

#89

Post by RaftPeople »

teaearlgraycold wrote: post #20
PreInternet01 wrote: post #3

> I miss that direct connection. The fast feedback. The lack of making grand plans. There's no date on this article, but it feels "prior to the MongoDB-is-webscale memes" and thus slightly outdated? But, hey, I get where they're coming from. Personally, I used to be very much schema-first, make sure the data makes sense before even thinking about coding. Carefully deciding whether to use an INT data type where a BYTE…

Byte vs. Int is premature optimization. But indexing, primary keys, join tables, normalization vs. denormalization, etc. are all important.

> Byte vs. Int is premature optimization

I think you can only judge that by knowing the context, like the domain and the experience of the designer/dev within that domain.

I looked at a DB once and thought "why are you spending effort to create these datatypes that use less storage, I'm used to just using an int and moving on."

Then I looked at the volumes of transactions they were dealing with and I understood why.

Re: "We ran out of columns"

#90

Post by rendall »

I'm glad OP was able to maintain a good sense of humor about it. Such discoveries as the nested classes of empty methods have sent me into teeth-gnashing fury followed by darkness and despair. One such experience is why I would rather change careers if my only option were to build on the Salesforce platform, for instance.
Post reply on HN