From: | Jean-Michel POURE <jm(dot)poure(at)freesurf(dot)fr> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | balaji(dot)venkatesan(at)megasoft(dot)com |
Subject: | Limitations on PGSQL |
Date: | 2001-11-05 10:33:48 |
Message-ID: | 4.2.0.58.20011105102300.00d065d0@pop.freesurf.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
At 12:04 05/11/01 +0530, you wrote:
>Hi,
> Can someone plz to do specify the features and more important the
> limitations in using
>PostgreSQL. More info regarding performace etc shall be of immense help
>Regards
>Bv :-)
Hello Balaji,
There are no real limitations when using PostgreSQL smart programming
features: views, triggers, rules, types and plpgsql server-side language.
For example:
1) FAST READINGS: triggers can store display values instead of performing
several LEFT JOINS or calling PL/pgSQL functions. Similarly, you can use
triggers to perform complex initialization or maintain consistency when
adding/modifying a record. Cron jobs and functions can perform queries and
store results for instant results (ex: statistics tables).This makes your
database very fast in complex readings (ex: web environment). This concept
of storing values is the base of optimization.
2) SAFETY: postgreSQL is a real transactional system. When using a
combination of views and rules, you can control data modification very
neatly. Example: you can define a sub-select of a table and control the
scope of queries. This is very important in a commercial environment when
you data is valuable and must not be deleted or modified given a set of rules.
3) CODING: server-side coding is mainly performed in PL/pgSQL, a very easy
and powerful server-side language.
This is paradise if you are a programmer. IMHO, the only few drawbacks are:
1) TABLE DEFINITION: it is Impossible to delete a column or to
promote/demote a column type. You have to drop the table and import old
values into a new table. This makes life harder when working on large
databases. You are always afraid of loosing your data. Even with backups,
it is always 'heart breaking' to modify a table. You have to perform tests
to ensure all data is there and safe.
2) VIEWS/TRIGGERS cannot be modified. You have to drop them and create them
again. This makes programming a little bit tricky. Further more, if you
create a view, let's say "SELECT table1.*, table2.* FROM table1 a LEFT JOIN
table2 b on a.oid=b.oida", the resulting view displays all fields, hence
making it harder for a non programmer to read view content.
This is very little drawback compared to power and reliability of PostgreSQL.
Best regards,
Jean-Michel POURE
From | Date | Subject | |
---|---|---|---|
Next Message | Patrick | 2001-11-05 11:06:29 | Define update-rule on view |
Previous Message | tony | 2001-11-05 09:23:10 | Function problems redux |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrea Aime | 2001-11-05 11:03:23 | Re: Serious performance problem |
Previous Message | Zeugswetter Andreas SB SD | 2001-11-05 09:47:57 | Re: Beta going well |