Now I have something that I have not seen it before: the database is really generic. For example: instead of a concrete type we have a generic one: device, and it relates to a custom properties table.
Unfortunatelly, the model over its entities represents those tables, so the model does not talk about the business at all.
At the end programming is quite confusing: noone has designed or defined that custom properties that should be in the generic table, so is difficult to know where to put what. And you need lot of code for just retrieve one attribute.
Do you think generic database with generic model is somekind of antipattern? Any pro?
I worked with a pretty much generic database in the past. It was a sensible way of managing a huge system with very frequently changing requirements and unexpected interconnections popping up.
The execution though was 3 kinds of tables: the main “generic” ones which stored certain data types, a table of links (table from, link from, table to, link to, record type) and a table of tables, defining what types of data are stored, and how.
Of course this created some overhead, but this was offset by engine customizations that really sped generic requests up and kept complex ones reasonable (and rare).
So, while I agree in general situation this is an antipattern, there are scenarios when this is the right thing to do. One specific scenario is when the system is a generic platform where the non-tech people create new services by combining generic blocks together. Blocks are connected to “data type” tables, but how these tables will be used (and what will the blocks be filled with) is left to the users.