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

71–80 of 588 posts

Re: "We ran out of columns"

#71

Post by throwup238 »

Vampiero wrote: post #57
PreInternet01 wrote: post #40

Earlier quoted context omitted.

> 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 un…

> 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?

Did you miss that he’s using sqlite? The dev experience with a sqlitedb is way better than running yet another service, especially for personal projects.

Sqlite is used just as much as an application file format as it is a relational database.

Re: "We ran out of columns"

#72

Post by PreInternet01 »

Vampiero wrote: post #57
PreInternet01 wrote: post #40

Earlier quoted context omitted.

> 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 un…

> Has it occurred to you that MongoDB exists?

My original comment started with "but it feels "prior to the MongoDB-is-webscale memes""

So, care to take another guess? And, while we're here, does MongoDB run fully in-process these days? And/or allow easy pagination by ROWID?

Re: "We ran out of columns"

#73

Post by mnahkies »

mikeocool wrote: post #56
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 anyth…

Macromedia flash / .fla files weren't particularly ideal for collaboration either, though I still feel a bit nostalgic for working with flash in general

Re: "We ran out of columns"

#74

Post by zo1 »

magicalhippo wrote: post #61
zo1 wrote: post #42

Earlier quoted context omitted.

The problem is maybe not so much the splitting and putting extra columns in a separate table. It's that you even have a table that large that it necessitates such a thing. Worst case you have a main table and a detail table that has a one to one correlation to the main entity table.

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 table, they have to copy over whatever the hell your PK seems to be, and the cycle repeats, this time a bit worse.

Last place I did a brief project in had this. Queue 1000 tables spread across 25 schemas, each table having wide PKs, 20 redundant indexes on each table, and despite all this the database performs poorly. No one can tell you what each table represents, the table names are meaningless and the same data is everywhere. In order to get anything done you have to ask a small cabal of priests that knows the processes that write between these tables. After about 10 years, a partial rewrite happens and you now have 1/3rd of the data on each side with plenty of duplicate and overlap because hey.

I feel torn, I really wanna name&shame this company as a warning to all developers thinking about working there.

Re: "We ran out of columns"

#75

Post by chatmasta »

__MatrixMan__ wrote: post #15
lexicality wrote: post #11

Earlier quoted context omitted.

created 14 hours ago https://github.com/jimmyhmiller/jimmyhmiller.github.io/commi...

But clearly in retrospect. It sounds like some of the things I was doing in 2009.

It includes a reference to Backbone and Knockout JS, which were released in 2010, so presumably it was around that era. The database, though, was probably much older...

Re: "We ran out of columns"

#76

Post by korhojoa »

dakiol wrote: post #24

Honestly, I like to work on such systems because: - there is so much stuff to improve. There’s nothing better than the feeling of improving things with code (or by removing it) - it’s back to school again and everything goes. You can implement features in any way you want because the constraints the system imposes. Granted, sometimes it’s painful to add functionality - there’s usually no room to subjective topics lik…

I mean, it is kind of nice to notice that something isn't going to work because you have the linters and tests. When your developer count goes up, chances that erroneous behavior is included also goes up.

I've created proof-of-concepts that worked perfectly but would make you cry if you looked at how they worked. Eventually they became that mess. Everything is a self-contained unit so it doesn't mess anything else up. Of course, there is always time to keep adding new stuff but never to refactor it into what it should be.

I prefer the way with linters and tests, it at least lessens the chances of whatever is put in being broken (or breaking something else). (Then again, somebody putting "return true" in a test _will_ surprise you sooner or later)

Re: "We ran out of columns"

#77

Post by dmd »

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 top of scalars (strings), using $foo and $foo_offsets. For example, $foo might be "romemcintoshgranny smithdelicious" and $foo_offsets = "000004012024", where he assumes the offsets are 3 digits each. And then he loops through slices (how does he know about slices, but not arrays?) of $foo_offsets to get the locations for $foo.

By the time I was done refactoring that 12k+ was down to about 200 ... and it still passed all the tests and ran analyses identically.

Re: "We ran out of columns"

#78

Post by rokkamokka »

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…

Goes to show that solutions don't need to be good to be impressive. Because damn, I'm impressed he did that

Re: "We ran out of columns"

#79

Post by dezsiszabi »

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