views:

117

answers:

3

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?

+1  A: 

Unless it is for some generic domain, I would say it does sound like an antipattern. Compare that to the usual object/relational/object mapped to relational model, where most tables represent some real domain entities. That's much more intuitive, simpler to understand and maintain, and does not require all the overhead (in coding and execution).

Konrad Garus
+1  A: 

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.

SF.
But the model over it managed the complexity or do you have one entity for each of your tables?
Pablo Castilla
The platform running it executed the queries per defaults specified in each block (there could be several different blocks that used one table, often in completely various contexts. Some blocks used two or more tables at a time), using specifics that were in configuration of these blocks. The platform performed the execution, but all the business logic was attached to the blocks, some permanently (SELECT what...), some coded as per-instance configuration (...WHERE what).
SF.
in a reflection: it is an antipattern when it is used instead of you doing your homework of obtaining the system specs. It is a valid pattern if you did your homework and the specs are "specs will keep changing frequently, deal with it."
SF.
+2  A: 

This reminds me of the Inner Platform Effect. Basically the database is reduced to a second database system in which your concrete types are implemented in.

Ozan