Hacker News Reader

Comment by fleetfox | Hacker News Reader

This seems to solve all my EAV use cases.

It is essentially EAV isn't it? Well integrated into Django so it works with the admin and migrations.

No it's not EAV. EAV is an sql (anti) pattern where you have a table with varchar fields such as name, type and value. So you'll have tuples like (id, int, 99), (name, string, sera) or (enable, boolean, true). This makes it very difficult to do aggregates and you can't do any consistency checks from the db.

What the article proposes is much better than this: A way to create models (ie tables in the database) dynamically. To make it more clear if you are not familiar with django, it'd be the same as if the CREATE TABLE sql was generated dynamically depending on the user selections.

So in this case each model will be in its own table and the fields will have proper types. You may even be able to have referential consistency using a ForeignKey field!

> You may even be able to have referential consistency using a ForeignKey field

Since you say "you may" ... , do you happen to see any problem that may arise with this implementation ?

Well, the original article doesn't actually mention ForeignKeys that's why I written may (it only has TextField and IntegerField). Of course nothing stops you from extending them; you'll need to of course add the model where you'll want to create an FK to.

So the MakeField model will have an optional field to denote the class to which you want to create the FK; probably an FK to ContentType would suffice for this field (https://docs.djangoproject.com/en/2.1/ref/contrib/contenttyp...).

I know I've written field and FK too many times, I hope it makes sense; if it doesn't tell me and I'll provide a more thorough example.

I know it's possible to take the ModelModel approach a bit further and add ForeignKeys to it. JSONField is like a better EAV, but it doesn't do dynamic relationships.

You are right, I had only quickly skimmed the article on my phone earlier. Its kind of similar, but moving it from the SQL layer to the Django layer in my opinion, but it does actually create database tables. The models are dynamic and in memory, (rather than in a file) which is at least as bad an idea as EAV in my opinion. But cool as a blog post.

I've used EAV before after putting some time into thinking of a solution and I'd be curious if there was a better way. Basically, we were building a restricted stock database depending on either a client preference or a customizable list.

For instance, a religious institution may not want to invest in a company that derives revenue from tobacco. So, we might have:

1. Is the company in an industry or sector we have flagged as tobacco?

2. Upon review, did one of our analyst create an exception list for companies partially involved in selling tobacco i.e. CVS, LVMH with duty-free, etc.?

3. Did the religious foundation also provide its own list of companies associated with tobacco usually through a consultant or several.

Therefore, we used a schema like:

table: exclusion_lists columns: company_id, exclusion_list_id, source_id

An account would register a restriction, which would group the baseline restricted companies from say sector to along with any customized lists that the account subscribed to, and a view would output all the restricted stocks and reasons why.

It didn't seem like an anti-pattern at the time. The benefit seemed to be if a restriction code was changed, it would all happen in one place versus updated in a bunch of JSON objects. Adding a column for a client for some special restriction with three companies would create a very sparse table so that didn't seem like an elegant solution either.

Reply on news.ycombinator.com