--- In firebird-support@yahoogroups.com, "Adam" <s3057043@...> wrote:

>
>
> > the trouble is some of our clients add up to 300 defined fields
> > sometimes. so i created an addional post for this. i was thinking
> > about creating a single table with 300 columns to hold this data in
> > flat format.
>
> The day after you do that will be the day they want 301 custom fields.
> You are also likely to start hitting some Firebird implementation
> limit (eg. maximum size of non blob fields in a row, indices per table).
>
> > i dont know if u understand where i am coming from. but if you do,
> > your input would be much appreciated. :)
> >
>
> I believe I understand where you are coming from, but of course I can
> not be certain. You want to give the customer the capability of
> storing data that they want that may not be "in common" with other
> customers.
>
> Despite its drawbacks, the original approach seems preferable to me
> than a mess of hundreds of indexed fields (I can't imagine performance
> being good when several hundred indices are needing to be updated.)
>
> Maybe a variation on your original design as mentioned by Set may
> reduce your current design's drawbacks. I can't say I am entirely
> comfortable with any of the designs for this purpose, but I think the
> avenue you are pursuing with this idea is going to cause you more
> problems in the long term than it solves.
>
> Adam
>

Thanks for the advice Adam.

The EAV architecture we have employed has served us well up to this
point. So perhaps a modification is more appropriate rather than a
complete overhaul.