[plug] SQL Servers

[Garth Atkinson]

John Summerfield wrote:
> 
> > John Summerfield wrote:
> > >
> > > > Hi Paul
> > > >
> > > > Go with Postgres. It has commit and rollback, which MySQL doesnt have.
> > > > MySQL might be faster than Postgres but who cares! BTW MySQL is verrryy
> > > > fast at simple queries, but its SQL is pretty restricted and the
> > > > developers have 'cut a lot of corners' to boost performance. Also
> > > > Postgres is GPL I think and MySQL is not (?).
> > > >
> > > > FWIW There is a lot of energy behind Postgres, maybe more so than with
> > > > MySQL.
> > >
> > > I have used PostgresSQL. Runs like a lame dog. Couldn't see any evidence
> > > it has any understanding of a transaction: it cheerfully returns
> > > uncommitted data to an enquiry. Its not relational either.
> > >
> >
> > How do you mean 'Its not relational'
> 
> Codd & Date outlined the criteria which a DBMS had to meet to be
> relational; PG doesn't meet them and the lack of these means extra work
> for the programmers.
> 
> While it might not cost any money to BUY, increased productivity
> attainable from using a relational DBMS makes it worth paying money for it.
> 
> Unless you're a student and using it as a tool to learn sql.
> 
> In the simple case of a payroll system (one of the early uses of a
> computer), one might have a table comprising basic information about
> employees; employee number, name, address etc.
> 
> On examining the data, you will see good sense to creating a table of
> locations: suburb|town and postcode. Saves storage, simplifies application
> design.
> 
> A relational DBMS will allow you to define a relationship between
> employees and location such that you cannot create an employee row for a
> non-existent location. Neither can you delete a location for which
> employee rows exist.
> 
> The checking's done in one location; the RDBMS. If you use PG, you need to
> check this rule in your code, at the points where you insert employee
> rows, at the points where you remove locations: potentially in many places
> in the code and many opportunities to add a few bugs.
> 
> If you're paying programmers, give them decent tools. Increased
> productivity will save the cost of the hardware software.
> 
> 
Thats relational integrity. MySQL doesnt have this feature either, yet
both MySQL and Postgres are very easy to 'code' for. If the entire user
interface is coded by hand, as is often the case with the above SQL
engines then its a doddle to code the integrity rules. Also, using a
RDBMS as defined by Codd & co, if a relationship between two tables and
their keys are not declared, the relational integrity protection will
not help against unwanted deletions/updates. Its a bit like type
checking of values prior to insert/updates. The engine can do some of
it, but you wouldnt use it on its lonesome.

I agree that relational integrity is sort of a good thing, but the
programmer still will take steps to further the relational model.

I havent used postgres for a long time (2 Years) so my knowledge of its
performance is a bit dated, but the press seem to think its reasonable.
Time to download it and have another look I think.


Garth