We are getting things ready for our booth at the M2M Expo. If you have done trade shows and have some tips, I would be thankful for the advice!
Update: We are no longer going to the M2M Expo in favor of going to Sensors Expo. Look for details soon!
Tuesday, April 14, 2009
Trying to Make EAV Work
I heart PostgreSQL. I heart data. I heart challenges. So when my friend David Fetter challenged me recently on a db design that stored data using the EAV model, I felt a bit cornered and not sure how to tackle the downsides of EAV.
There seems to be a lot of interesting discussions out there for and against EAV. The project I am currently working on requires flexibility as we, the developers, don't know what we need to add to the system. We have a fairly rigid set of requirements about the data and have metadata tables to help in the process.
Our application will be responsible for making sure that the data is stored properly. Secondly, all data is stored as NUMERIC, not as VARCHAR/TEXT as what most EAV systems seem to use. Thirdly, we assign what kind of data is being stored and use a lookup table for finite textual data.
So, now the question is, are we setting ourselves up for disaster going with EAV? I hope not.
There seems to be a lot of interesting discussions out there for and against EAV. The project I am currently working on requires flexibility as we, the developers, don't know what we need to add to the system. We have a fairly rigid set of requirements about the data and have metadata tables to help in the process.
Our application will be responsible for making sure that the data is stored properly. Secondly, all data is stored as NUMERIC, not as VARCHAR/TEXT as what most EAV systems seem to use. Thirdly, we assign what kind of data is being stored and use a lookup table for finite textual data.
So, now the question is, are we setting ourselves up for disaster going with EAV? I hope not.
Subscribe to:
Posts (Atom)