Well, actually, yes our work is based on an EAV model. And it has been successful so far. However, the point I was discussing is not really dependent on the EAV model. It is rather dependent on the fact that we are employing an object-oriented design implemented on top of an RDBMS.
Regarding, the fully-typed system point. In fact, if you allow types to be automatically defined and constrained by priorly defined rules of suitability for what should define a type and how a type may behave when input to typing functions (type-test functions), an EAV may be fully-typed. This doesn't apply only to EAV model. A further step would be making the suitability rules automatically inferred from existing types if possibles.
Regarding the cast thing I was asking about, I guess we can get away with a constraint on the field's type (which was supposed to be polymorphic) and handle polymorphic issues in the dynamic parts of the systems rather than in static structures, such as, tables.
Thank you very much, Merlin and Tom. I appreciate you suggestions and help.
Kind Regards,
Kareem Sedki
On 10/23/2009 05:24 PM, Tom Lane wrote:
Kareem Sedki <isiscreation@gmail.com> writes:
The problem I faced is that the type 'any' is not permitted in
procedural languages. If it were permitted, then we could have a
function like is_castable( value ANY, target_type TEXT) and then we
would catch exceptions if they are thrown.
ANYELEMENT maybe?
Here is what we have, there is a field in which we should store
different data types and another field in the same row to store the
identifier of the original data type of the first field. The first field
should be polymorphic.
Although actually I think you should stop right here and rethink what
you are doing. It sounds a whole lot to me like you are trying to build
an EAV store, and that seldom leads to anything good. It is much better
to spend the necessary effort up-front to work out a concrete
fully-typed schema for your database.
regards, tom lane