Board index » delphi » Re: Postgresql 8.1 released

Re: Postgresql 8.1 released


2005-11-11 02:23:16 AM
delphi125
Quote
Another big plus in my book is the fact that PG has schema(or
namepsace) support, which really helps in organizing your
tables,functions and views.
Schemas are nice ... I'd like to have those with Firebird :-)
MS SQL 2005 has them as well, pretty neat.
--
With regards,
Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
www.upscene.com
Database development questions? Check the forum!
www.databasedevelopmentforum.com
 
 

Re: Postgresql 8.1 released

xkorakidis <XXXX@XXXXX.COM>writes:
Quote
think we can find many cases of successful projects built in delphi-ms
SQL Server.
Why try to combine delphi (perfect tool for desktop apps) with postgress
(a more powerful tool than desktop applications need)?
Sql Server have many things I hate.
1-It doesnīt have generators,Those autoincrement fields are {*word*193}.
2-It doesnīt have on delete cascade or on upate cascade I canīt remember.
3-You canīt have two foreign keys for the same table.
4-It runs only in Windows.
5-It is expensive.
Iīm going in to the same path of yoy JAVA/LINUX maybe even PHP/LINUX in some cases,but until there I have to mek money for the rent.
Marcello
 

Re: Postgresql 8.1 released

Of course Iīm talking about the SQL sERVER 2000 version,
I donīt how many of these issues are still valid.
Marcello
"Marcello Dias" <XXXX@XXXXX.COM>writes:
Quote

xkorakidis <XXXX@XXXXX.COM>writes:

>think we can find many cases of successful projects built in delphi-ms
>SQL Server.
>Why try to combine delphi (perfect tool for desktop apps) with postgress
>(a more powerful tool than desktop applications need)?
Sql Server have many things I hate.
1-It doesnīt have generators,Those autoincrement fields are {*word*193}.
2-It doesnīt have on delete cascade or on upate cascade I canīt remember.
3-You canīt have two foreign keys for the same table.
4-It runs only in Windows.
5-It is expensive.

Iīm going in to the same path of yoy JAVA/LINUX maybe even PHP/LINUX in some cases,but until there I have to mek money for the rent.

Marcello

 

Re: Postgresql 8.1 released

Quote

Schemas are nice ... I'd like to have those with Firebird :-)

In fact lack of schema concept was the argument that drove my decision to
use PostgreSQL instead of Interbase/Firebird.
 

Re: Postgresql 8.1 released

Quote
The only solution(At least for those who still use Delphi 7) is vitavoom
dbexpress driver,but I couldnīt see any sucess case of this product.
Unfortunatelly Delphi programmers are sometimes too Shy,I think that if
you use a product and are satisfied with it ,You should el the "whole
world" because if the producer have money in his pocket,the product will
probably have a future.
I've ordered Vitavoom driver, so I will have some infos about it soon.
 

Re: Postgresql 8.1 released

"TProgrammer" <XXXX@XXXXX.COM>writes
Quote
>
>Schemas are nice ... I'd like to have those with Firebird :-)
>
In fact lack of schema concept was the argument that drove my decision to
use PostgreSQL instead of Interbase/Firebird.
I've been searching online for real-world examples of interesting, useful
usage of schemas, but all I can find are the same old trivial examples.
Could you point me to some or share your usage of schemas? Thanks!
--
Ray Marron
 

Re: Postgresql 8.1 released

Marcello Dias writes:
Quote
xkorakidis <XXXX@XXXXX.COM>writes:

>think we can find many cases of successful projects built in delphi-ms
>SQL Server.
>Why try to combine delphi (perfect tool for desktop apps) with postgress
>(a more powerful tool than desktop applications need)?
Sql Server have many things I hate.
1-It doesnīt have generators,Those autoincrement fields are {*word*193}.
2-It doesnīt have on delete cascade or on upate cascade I canīt remember.
3-You canīt have two foreign keys for the same table.
4-It runs only in Windows.
5-It is expensive.

Iīm going in to the same path of yoy JAVA/LINUX maybe even PHP/LINUX in some cases,but until there I have to mek money for the rent.

Marcello

I absolutely aggree with you, but a friend of mine who was in a msc in
computer science in a good Univercity of England (Endiburgh I think),
told me that his teachers had good experience from MS SQL due to its
engine, especially its engineers.
I haven't use it for my projects because IB was ok for me, but If it is
for a large project someone have many reasons to prefer it: support,
tools, esperience. If it isn't so good why many developing organizations
prefer it? Just because it is promoted well? I don't think so!
developers aren't just pc users, so maybe the reason MSQLServer is
successful commercially is deferent from the reason Windows became
successful economically.
As far as I am concerned, for large projects I'd prefer postgress but
not in combination with delphi. I think Java is a better choice for
large multitier, multiuser and many times internet applications.
P.S. I didn't needed cascade functions until now: when a lookup record
is going to be deleted user is prompted to delete related main records.
When a main record is deleted, lookup record stays as it is and becomes
deleted or transfered when the user "defrags" the database. This seems
to work well for simple projects, in large projects maybe it isn't a
good choice
 

Re: Postgresql 8.1 released

"Ray Marron" <XXXX@XXXXX.COM>ha scritto nel messaggio
Quote
"TProgrammer" <XXXX@XXXXX.COM>writes
news:4374bd34$XXXX@XXXXX.COM...
>>
>>Schemas are nice ... I'd like to have those with Firebird :-)
>>
>In fact lack of schema concept was the argument that drove my decision to
>use PostgreSQL instead of Interbase/Firebird.

I've been searching online for real-world examples of interesting, useful
usage of schemas, but all I can find are the same old trivial examples.
Could you point me to some or share your usage of schemas? Thanks!

Sure!
In a word: hierarchy of tables. Suppose you have to design an accounting
database, and one of requirements is that it has to be multi-company. You
can add a company code in primary key of every table, increasing complexity
of every primary key of your database, slowing down operations, but not
also: maybe some tables need to be "common" and some others not, and maybe
another customer of same software need different common tables, and at the
end 80% of your customers don't need multi-company at all, and, finally, 2%
of customers need also a multi-plant software! So, I create a "common"
schema (with all common tables), plus, say, companyA and companyB schemas
for specific-only tables. Company A users have schema path = companya,common
and Company B users have schema path = companyB,common.
You can add as many levels as you like, without redesigning your tables if
you have different needs in future.
 

Re: Postgresql 8.1 released

Quote
I absolutely aggree with you, but a friend of mine who was in a msc in
computer science in a good Univercity of England (Endiburgh I think),
Oops sore point to us Scots, Edinburgh is in Scotland, not England :)
 

Re: Postgresql 8.1 released

David McCallum writes:
Quote
>I absolutely aggree with you, but a friend of mine who was in a msc in
>computer science in a good Univercity of England (Endiburgh I think),

Oops sore point to us Scots, Edinburgh is in Scotland, not England :)


Yeap, sorry... I knew that but I didn't know how to express it, GB maby? :)
Especially those who doesn't live in GB (eg me), when say England mean
GB. I guess it is a little bit wrong...
To be honnest, i don't like so much tea, but I like very much scotch
wiskey and irish music :)
 

Re: Postgresql 8.1 released

Thomas Steinmaurer writes:
Quote
Hi Tony,

>>>>Two-Phase commit (ok, that is gone with PG 8.1),
>>>
>>>>but the second is a SNAPSHOT / REPEATABLE READ transaction isolation. I
>>>>can't live without that when it comes having a stable view of data
>>>>during one transaction, or did that change with 8.1? Is there now a
>>>>SNAPHOST / REPEATBLE READ transaction isolation level available as
>>>>well?
>>>
>>>
>>>Hi Thomas,
>>>Here is the docs on that for 8.1:
>>>
>>>www.postgresql.org/docs/8.1/static/transaction-iso.html
>>>
>>>Not sure if serialized is the same as repeatable.
>>
>>It isn't.
>>
>>
>I think it is, see here for more info:

I don't think so. In your other message you've quoted something from the
manual:

"...when you select Repeatable Read you really get Serializable, so the
actual isolation level may be stricter than what you select ..."

Serializable is stricter and somehwat unusable in a multi-user, loaded
database, because only one transaction can run at any time. Let's say you
would have one long running serializable transaction encapsulating a
reporting query, this will cause other transaction to wait.

There is a pretty good paper on discussing why it was a somewhat bad idea to
describe transaction isolation levels in terms of phenomena in the SQL
standard. This paper also describes transaction isolation levels for MVCC
databases. The paper is from 1995, but I can not find it right now.

SNAPSHOT in Firebird isn't a SQL standard compliant REPEATBLE READ either.
SNAPSHOT in Firebird is between REPEATABLE READ and SERIALIZABLE, but
without blocking other transactions.

Regards,
Thomas


Thomas,
I don't think that occurs in Postgresql because it is process based,
this might be true of a threaded solution, but in PG your connection
would be the only one prevented from starting another transaction, not
the whole server.
Below is a qoute from one of the PG developers.
(which we've had since 1999). Certainly REPEATABLE READ does *not*
guarantee a "stable view of data during one transaction" --- see the
discussion of phantom reads in the second link given above.
Maybe you should join the PG Hackers mailing list, they would be able to
explain this whole thing a bit better than me.