Roy Schestowitz wrote:
> EnterpriseDB Expands Asia Pacific Operations With Hong Kong Regional
> Headquarters
>
> ,----[ Quote ]
> | EnterpriseDB, maker of the world's leading enterprise-class database
> | built on open source, announced today that it has expanded its
> | Asia Pacific operations with the establishment of a regional
> | headquarters in Hong Kong.
> `----
>
> http://press-releases.techwhack.com/6859/enterprisedb-expands/
After a long break from Postgresql I recently wanted a DB to mirror another
off the UNIX for reporting, but the MySQL version onboard the target was a
bit old. So rather than take the upgrade path of MySQL with the troubles
that entails, basically forget the upgrade path altogether it will wreck
the version you have and after you have manually fixed all the bit's that
MySQL couldn't manage to do with it's own files you still get lots of
warnings, that implies unstable to me. Instead, if it Must be MySQL do a
manual install and keep the two seperate, they will fight like buggery if
you don't.
But I went with postgresql instead. What a smooth DB it has become.
For example the programming interface, you don't get a large list but don't
let that fool you, it's like an MG midget, little car with big engine.
But starting at the beginning, for anyone who like me do a lot of the work
in the commandline system of mysql
mysql -u name -p
Then there are a few bits and pieces that takes a bit of getting used to
inside psql, the use of the'/' command for example, but it isn't long
before you are flying through the commands the way you are used to working,
and anyway the help system is well written so don't be put off by those
early steps.
Creating users is easier for new people than MySQL is, and by default helps
admin people to create the right sort of users for their application. For
example you might have a 'role' which is web reporting, where your pages
report products or information to the user but doesn't need to write back.
But for a logged in user you would then up the user because there is not
orders coming in that you need to record. So in a database link you would
use a low rights (grants) user for the first and higher for the second.
In postgresql you create the role's for a web access site maybe something
like this,
createrole webreporting with option {list of NO.. rights}
createrole webreadwrite with option {better level for login users}
Once you have created the roles and set their limits, you can then use them
in your grants.
grant select on webdatabase to webreporting;
grant update on webdatabase to webreadwrite;
That is much simpler than messing around with lots of grant statements
trying to balance user rights, only to find some day that a previously
entered grant further into the table left some open door somewhere for a
user to gain too much access.
Roles are worth looking into more closely, because if you have a lot of user
levels, and on a typical database you will have at least two, on a typical
web database you will have at least three, roles allow you to work as if
with groups so that you have less maintenance work to do through the grants
system.
The transaction handling, how much simpler could it be than this,
BEGIN
savepoint - in case we make a mistake and need to 'rollback'
perform some SQL operations....
COMMIT;
But of all that postgresql gives the big one I would say is 'triggers', we
are used to these on the big databases, the unidata's and others of that
ilk. Triggers are so usefull on large databases, not only for calling
action procedures internally but also to trigger off a procedure that lets
a backup know what tables/records have changed. But you can go further with
no extra effort, if you trigger after an event then you even have access to
the items that caused the trigger, hows that for a means of instant DB
mirroring which also includes the means to know if the data was accepted
before you mirrir it (instant mirror IT'ers are always in constant fear of
a bad transaction being instantly mirrored, it gives them a head ache).
I must say I liked my look into postgresql, I still have a lot of databases
around me that are on unidata and MySQL and don't think I will be moving
those, but new databases, particularly a large user base one that I will be
doing later this year, postgresql is a really nice dbase to work with.
|
|
