Hacker News new | past | comments | ask | show | jobs | submit login

Wow these are shockingly bad rules. This is how we end up with DBs with hundreds of tables and duplicate columns like `name` and `name2`.

My number one rule of growing schemas is to design your schemas and applications with a good custom field system. Some kind of flexible way of being able to add fields to items as data.




Ahhh the entity-attribute-value pattern.

When your sql database needs another sql engine to translate to actual EAV queries.

But they are fun schemas!

The old joke that there are two actually hard problems in CS: caching and naming things. The older I get, naming things IMO is far more difficult.


When you start looking at SQL tables that are just id,key,val then you know you've teleported into this forbidden realm.

There are 2 hard problems in computer science: caching, naming things, and off-by-one errors.


It’s even better when you find out that key is a text field, and stores ints, uuids, custom key formats…


And there are a different 'value' column for every possibly data type.


The thing about naming is that it is so closely related to how the problem domain (not business domain, though they are of course related) is understood, and how well it is conceptualized.


I've seen some horror stories at companies with that sort of custom column schema. Today I think just adding a new column is a lot better in the long term. Custom fields systems will quickly contain several different "versions" of the records, but there is no easy way to see which is what. At some point it feels like re-inventing a datalog or key-value database, but those have query systems better-suited to the task.


Custom fields system is generally a bad idea imo. Just do JSON if you want that




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: