Astro Hacker News - The Inner-Platform Effect (2006)

stevage |next [-]

Reminds me a lot of a final year group software project at uni. Instead of building a solution for our client we built a kind of meta solution, then ran out of time to actually solve his problem in it.

Artoooooor |next |previous [-]

From time to time I send this article at my job. Just as a distress call about our system.

Normal_gaussian |root |parent [-]

There is something to reading something from 20 or 40 years ago and having a professional existential crisis.

zephen |next |previous [-]

Perhaps a corollary to Greenspun's Tenth rule?

"Any sufficiently complicated database program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of COBOL."

kristianp |next |previous [-]

I've seen these custom fields tables in a number of database schemas I've worked with in the past. It adds dynamism to a fixed table structure. I wonder how CRMs do it these days without having poor performance at scale?

Normal_gaussian |root |parent [-]

Being able to partial index into JSON has made this much more straight forwards now than ever before, but historically pre-creating empty indexed custom columns was somewhat common (leading to hard limits like max 20 custom tags), as was EAV (which arguably is inner-platform).

There are more solutions than these, but until you're at truly custom DB scale with a specific problem here, these will solve it for you.

jiggawatts |root |parent [-]

I've also seen a system that instanced the database per customer and simply extended the schema with additional columns.

That worked great... until the thousands of instances had to be merged into a single unified schema.

Normal_gaussian |root |parent [-]

yeah, generally instancing a table per customer is an old smell indicating they have either a permissions issue (no RLS) or you're using a db which doesn't support partial indexes (which basically everything does now).

bob1029 |next |previous [-]

I've made the mistake of creating this kind of problem many moons ago. The dream was to have non-technical domain experts implement the product. I did not know at the time that this was a cursed problem. Probably one of the most cursed, in fact.

Putting it my sql based scripting engine took 2 weeks. Backing it out is going on 4 years now. Perhaps the biggest technical misstep I've ever made. It's kind of like Pandora's box because once the non technical people feel the speed/control, they'll never let it go. You could place a literal money printer on their desk as an alternative and they'd reject it if you took their new power away.

paulddraper |root |parent [-]

That seems successful.

bob1029 |root |parent [-]

If you are into constructing fiefdoms in places they were definitely not intended to be constructed, then certainly.

dvh |previous [-]

It's 2025 why are you gluing SQL strings? Don't even use it as an example!

zahlman |root |parent |next [-]

The post is clearly marked as being from 2006.

JadeNB |root |parent [-]

Also it's from TheDailyWTF, not an endorsement of the practices there even in 2006.

recursive |root |parent |previous [-]

Perhaps to facilitate a dynamically generated schema.