Re: generic modelling of data models; enforcing constraints dynamically...

Поиск
Список
Период
Сортировка
От InterRob
Тема Re: generic modelling of data models; enforcing constraints dynamically...
Дата
Msg-id 671e36b0909271644p3cae759y731e5f7d323cbfc3@mail.gmail.com
обсуждение исходный текст
Ответ на Re: generic modelling of data models; enforcing constraints dynamically...  (Oliver Kohll - Mailing Lists <oliver.lists@gtwm.co.uk>)
Ответы Re: generic modelling of data models; enforcing constraints dynamically...  (Scott Marlowe <scott.marlowe@gmail.com>)
Re: generic modelling of data models; enforcing constraints dynamically...  (Johan Nel <johan.nel@xsinet.co.za>)
Список pgsql-general
Oliver,

Would you say it is not valid for proposition 2 (people wanting to be able to quickly add (and remove?) attributes) because within the relational model this can be done reasonably well?

If you think so, then I we do in fact agree on that... Still, however, implementing this transparently (that is: back-end/server side; using VIEWs, is the only way I can think of) is a major challenge. Implementing the use of USER DEFINED additional fields within a certain application (front-end / client side) is much more easy...


Rob

2009/9/27 Oliver Kohll - Mailing Lists <oliver.lists@gtwm.co.uk>

On 27 Sep 2009, at 21:10, InterRob <rob.marjot@gmail.com> wrote:

Peter, may I invite you to privately share some more details on the system you are using and the design of it? Did you implement it using PostgreSQL? Looking forward to your reply.
(And with respect to your previous message: whom are you actually referring to by the acronym "OPs"?)


Or publicly? I for one would be interested hearing more. From situations I've come across, EAV seems to be proposed when either
1) attributes are very numerous and values very sparse
2) people want to be able to quickly add (and remove?) attributes
My feeling is it's probably valid for 1, at least I haven't come across anything better, but not for 2.

Regards
Oliver

В списке pgsql-general по дате отправления:

Предыдущее
От: Sam Mason
Дата:
Сообщение: Re: PostgreSQL reads each 8k block - no larger blocks are used - even on sequential scans
Следующее
От: Justin Pryzby
Дата:
Сообщение: dump time increase by 1h with new kernel