Entity with custom fields

Question

I am developing an application that gives the user the ability to configure a gateway (like PayPal, Authorize.net, etc) to process specific campaigns, however, each gateway has specific fields, which differ from one to another.

The values of the fields are the only thing that can be changed by the user, during the creation of a custom GatewayConfiguration, which is used with a specific Campaign.

I've read about it, and found that a good way of doing this is to have a table for the fields, and another for the values of these fields. Something like this:

------------
-- Gateway Table
------------
id
1

--------
-- GatewayField Table
--------
id, gatewayId, name,        label
1,  1,         'username',  'Gateway Username'
2,  1,         'password',  'Gateway Password'
3,  1,         'apiurl',    'Gateway Api URL'

-----------
-- GatewayConfiguration Table
----------
id, gatewayId
1,  1

-------
-- GatewayFieldValue Table
-------
gatewayConfigurationId,  fieldId, value
1,                       1,       'someUser'
1,                       2,       'somePass'
1,                       3,       'someUrl'

There are not too many gateways and it's not going to change too much, since the user can not add new gateways, just use the existing ones, and because of this, the GatewayField is not going to change too.

I'm not complicating things by doing this? Would not it be better to put all the gateways on a single table and use, for example, a JSON field to define which custom fields this gateway accepts, and on the GatewayConfiguration just use another JSON encoded field to set the values of the custom fields? There are better solutions?

The EAV construct that you describe above introduces a fair amount of complexity to the problem without offering any real benefit over encoding the data in a standard serialization format. I would json_encode that SOB and call it a day. — Orangepill, May 20 '13 at 18:00

score 0 · Accepted Answer · answered Feb 14 '14 at 19:26

I've ended up using the EVA-like structure mentioned in the question, it was not that complex, in reality it was really easy to implement with an ORM like Doctrine.

Because the amount of data is not going to grow at hight rate, I don't see any performance implications, and if it appears any issues, I will just move it to something like MongoDB.

For now it's working, and that is what really matter at the beginning.

Entity with custom fields

1 Answers1