Mary
If you're interested, these days you'll get the livliest discussions
on relational design in the microsoft.public.sqlserver.programming
newsgroup, where Joe Celko livens up many a thread.
In the past I have had my differences with Joe as he comes from the SQL side
rather than the Relational side. Some may not be aware that SQL is not
(wholly) relational. One shudders to think what CLR could do it could even
allow Joe and I to agree on something. (vbg) On the 10 year old thread I
mentioned earlier Joe and I came to blows on the problems associated with
not defining a Primary Key. Our disagreement was based on him coming from
the SQL side and me from the Relational side, we were both right in our own
terms. I think Joe now agrees more with the relational side. Having had a
look at his recent contributions on the above newsgroup I find little to
disagree with. Mind you, give me time. (vbg)
Regarding little ol' Access, whilst the architecture may be 10 years old it
is (roughly) based on Relational Theory which is over 30 years old and is
still relevant.
Your Access FE should work fine with SQLS 2005 as long as you're
running in 2000 compatibility mode.
What's the problem with 2002/2003 in this respect?
It's unclear at this point if Access will ever have full support for new
features like CLR assemblies and UDTs. There's only so much you
can tack on to what is essentially an ancient architecture.
However a tool like Access is required to allow users and database
developers to be able to harness the power of the new database engines. We
certainly do not want to have to rely on programmers with little
understanding of set theory and their love of record numbers and "so-called"
surrogates.
Note: A true surrogate (from say a hashing algorithm) is hidden to the user
and that includes the developer, it is system generated and internal. It
allows the database developer to pick the real natural Primary Key even if
that is fairly complex and the system hashes this to some internal value
that is then used to refer to this value in all relationships.
How much has really changed in the last 10 years?
Very little on the theory side. If anything the theory is becoming better
implemented, I may have to leave SQL Server 2005 out of that generalisation
though. I am not sure if SQL Server 2005 has blown it or not, anyway I am
also playing with the latest version of DB2 (UDB 8.2 aka Stinger due for
general release on 17 September) which seems to be streets ahead. DB2 is
where I came in to this field nearly 20 ago, a homecoming may be in the
offing.
Most of the folks from the old Compuserve Access MVP crowd has moved
on to either .NET or SQL Server or both, except Viescas, who I believe
is still active in the Access ng's. My last book was several years ago
now, but the basic concepts of how to build an efficient Access-SQL
app haven't changed since then, so it's still useful info for many
people. >
Well I thought that SQL Server 2000 was a promising start but SQL Server
2005 looks rather disappointing after a whole 5 years in the works. DB2
still looks like the only serious contender (if you forget about Oracle and
I am still trying to. (g))
Access is a wonderful front end development tool for database developers
maybe we could let all the programmers go and use whatever the latest
flavour of the month is while we remain using a tool that started out pretty
good from the start and has improved ever since but less and less with each
"good" release as it was pretty strong by Access 97. There was hope for
the ADP in 2002 which I had hoped would make access to SQL Server 2000 more
like using the next version of Jet. We sort of referred to SQL Server 2000
as Jet 5.
P.S. My brother is a programmer who started out at IBM developing OS/2 and
is now up to his neck in .NET and all that and we do get on, honest.
I
like programmers, some of my best friends are programmers but if they touch
my database design they are dead! (vbg) And if they trawl through a
recordset when they could have used SQL they are taken out back and beaten
to within an inch of their life. (vbg) Relational Theory Hard but Fair.
DAO or ADO I try not to use either as much as possible, SQL will do just
fine for me most of the time. RQL would be better!
I probably won't write another one any time soon. It's a lot
of work to do a good one with original research that isn't just a
rehash of the help files. Even though our book is still selling, the
hourly rate for the time we expended compares unfavorably with the
hourly rate for flipping burgers
The problem with perfectionists is that they damage their hourly rate by
being unprepared to a slap dash job.
All the best.
--
Beatha agus Slainte
Craig Alexander Morrison
comments inline above.
