Hacker News Reader

Comment by hamburglar1 | Hacker News Reader

This looks like B.S. to me. - Who would store date of birth as a string? - If we are stringifying dob why is address still seperated? - Why are the credit report reasource Ids in the thousands not 1M +? - Why is the file size null but the file is listed with it's mimeType?

I know equifuckingsucks at security but this is a setup that would actually just be difficult to interact with from a data stand point

View on HN

"Who would store date of birth as a string?"

Enterprise.

"If we are stringifying dob why is address still seperated?"

Enterprise.

"Why are the credit report reasource Ids in the thousands not 1M +?"

Enterprise.

"Why is the file size null but the file is listed with it's mimeType?"

Enterprise.

Be grateful you are in a position to be horrified. I'm currently fighting my way through a system that is not currently "Enterprise" yet, but was certainly headed full bore in that direction.

Exactly. The data model, and particular data typing, being terrible is more indicative of it being legit. Not less.

Anyone who has to work with the clowns in the credit reporting biz knows that this data is probably sitting on some COBOL-backed shimmed-out VAX talking to drum memory storage.

sad truth

Indeed. This is one of those cases where reality is worse than the fabrication.

Yeah, but it'd be easy to repackage from a million other sources.

That's exactly what I thought.

I consulted on an enterprise project once with EVERY column in EVERY table set to string because the engineers didn't want to think about datatypes.

All the queries used wild cards or just pulled back a ton of data and did the filtering and sorting in the application code.

That job sucked.

I consulted on a large healthcare data project with similar problems. Even "primary" keys were strings. Most tables had no indexes. (The developers routinely argued that they needed new servers with more RAM because they couldn't run multiple database queries at the same time. They already had 64 GB RAM.)

Yes! It had a lot of index-less tables. The you put an index on something and everyone treats you like a magician after you convince them the additional write is worth it.

Or one of the developers deletes the index you've just added... because it uses too much disk space.

No, no, no! They get religion and put an index on every column.

Most days I worry I'm an imposter, but when I hear that there are groups of people running databases with no idea that indexes are a thing, I think maybe I should ask for a raise.

So a different question: why would enterprise store it in a JSON? :)

Some new interface so that they can claim they're "Fintech" to others while the core still runs on a mainframe. At least that's how banks manage to create nice apps while using a core system from the 70s.

This is a JSON representation. Probably not even the storage format. But even if it were, in javascript, new Date("MM/DD/YYYY") parses correctly.

I don't think it's as difficult as you are imagining.

It also doesn't need any formatting in order to be displayed, which is likely it's only real use.

the server password was admin/admin , do you really think your best practices apply here?

Reply on news.ycombinator.com