[plug] SQL Servers

[John Summerfield]

> John Summerfield wrote:

> > 
> > 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
I know. I read its documentation, asked a few questions & binned it. I 
didn't even install it; no matter how fast it does what it does, it's not 
relational.

> 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

If the relationship isn't declared, it's either a DBA error or a design 
decision. MySQL and Postgres don't offer the choice.

The problem's easily fixed too; just define the tables correctly. Much 
simpler than reviewing goodness-knows-how-much source code looking for the 
error.


> 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.

Mr Bracegirdle might not. Most of us, thouhg, trust our software to do 
what we expect it to do, at least until it fails.

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

"sort of?" Essential!!

> 
> 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.

Don't bother; it's not worth the trouble.


Don't misunderstand me; Postgres has its place. Safe-guarding corporate 
data is not it. And the original question was about Safe-guarding 
corporate data.


-- 
Cheers
John Summerfield
http://os2.ami.com.au/os2/ for OS/2 support.
Configuration, networking, combined IBM ftpsites index.