Re: PG rules! (RULES being the word ;->)

Поиск
Список
Период
Сортировка
От Janning Vygen
Тема Re: PG rules! (RULES being the word ;->)
Дата
Msg-id 01071910340400.18488@janning
обсуждение исходный текст
Ответ на Re: PG rules! (RULES being the word ;->)  (Jason Earl <jdearl@yahoo.com>)
Список pgsql-general
Am Mittwoch, 18. Juli 2001 21:02 schrieb Jason Earl:
> At the very least you should use the SQL 92 features
> that PostgreSQL has.  [...]

ok, i can agree to this.

> Besides, eventually your users are going to want to
> circumvent your middleware for one reason or another.
> PostgreSQL's constraints and referential integrity
> makes this sort of access safe.

but it is only safe if you put ALL businnes logic inside postgresql.
if you dont you should never access your databse via pgaccess or psql.

> Because of this once PostgreSQL gains the ability to return
> result sets from functions I will probably move *more*
> of my applications functionality directly into
> PostgreSQL.  That way I could use this logic not only
> from my primary application, but also from psql,
> one-off Python scripts, MS Access front-ends, etc.

So you split your business logic. I cant believe that this is easy to
achieve. I guess the main reason for putting businnes logic into the
database is performance!? Like if you have 1.000.000 persons and you
want to calculate the persons average age, you can instanciate all
person objects and calculate it OR just ask postgresql which will do
it much faster i guess.

So my conclusion to this topic is to put business logic into
postgresql when you benefit from it because of performance or because
of data integrity. On the other hand it is very difficult or mostly
impossible to put all businnes logic inside postgresql.

janning

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

Предыдущее
От: Ben-Nes Michael
Дата:
Сообщение: two constrains for one column
Следующее
От: "Dr. Evil"
Дата:
Сообщение: Re: two constrains for one column