[AccessD] The future of Access, .NET and SQL

Arthur Fuller artful at rogers.com
Sat Oct 1 13:11:56 CDT 2005


As I see it, there are two issues here. 
A. The db engine itself:
1. the actual physical storage mechanisms must be hidden from the user.
2. A single language must enable you to query the system tables as well as
the user tables.
3. There must be a mechanism to uniquely identify every row in every table.
Absolute duplicates are forbidden.
4. There must be a way to implement constraints such as Foreign Keys, unique
values and range constraints.
B. The particular database that is implemented:
1. Values must be atomic (i.e. don't have a column called NamesOfChildren
that contains a string such as "Jim, Arthur, Charlotte, Shamil").
2. Don't nest tables (i.e. the give-away is columns with parallel names,
such as SalesRep_1, SalesRep_2, SalesRep_3 -- this is a sure-fire indication
that you need to add another table called SalesOrderSalesReps or somesuch).
Of course there are more rules than these; I cite these just to indicate the
turf and the division. The former set of rules is for the database vendor to
develop. The latter set is for the developer to implement. If you break the
rules in the latter set, it is not because the particular database product
is flawed, but rather the user's understanding.
Arthur

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil
Salakhetdinov
Sent: September 30, 2005 1:07 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] The future of Access, .NET and SQL

Jim,

But I think MS SQL 2000 and MS SQL 2005 perfectly fit all the twelve
Dr.E.F. Codd rules.

http://www.frick-cpa.com/ss7/Theory_RelationalDB.asp

Maybe there are some small exceptions for the rules:

#4. Database is Self-Describing
#12. Data Integrity Cannot be Subverted

but they are not significant I think.

Shamil

----- Original Message ----- 
From: "Jim Lawrence" <accessd at shaw.ca>
To: "'Access Developers discussion and problem solving'"
<accessd at databaseadvisors.com>
Sent: Friday, September 30, 2005 8:40 PM
Subject: Re: [AccessD] The future of Access, .NET and SQL


Hi Alan:

If all ten law/rules/guidelines were ever fully implemented on a database
the application it would grind to a halt. It has been attempted, to various
degrees, in data designs within Government Ministries for years and in ever
cases it has failed. The basic guidelines of relational databases as I see
them are as follows:
1. The data must be easy to retrieve...therefore the data should be grouped.

2. The database must be kept as small as reasonable...therefore as little
duplication as possible.
3. A high level of performance must be maintained.

With those three guidelines much of Codd's/Date's rules can be implemented
but the whole concept starts to fall apart when enforcing the rules start to
impact performance.

My two cents worth
Jim

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Lawhon, Alan C
Contractor/Morgan Research
Sent: Friday, September 30, 2005 7:44 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] The future of Access, .NET and SQL

Arthur, Charlotte:

Several years ago I recall buying (and trying to comprehend) relational
database guru Chris Date's "classic" book (it's more like a tome ...)
"An Introduction to Database Systems".  (Chris Date's main claim to
fame is as a protégé of the late Dr. E.F. "Ted" Codd - the "father" of
the relational database model.)  Date worked with Dr. Codd in the early
1970's at IBM.  He is now a full time consultant and writer - mostly of
articles dealing with various topics related to database design.

Chris Date is a relational "purist" (some might say a zealot) in arguing
that a database system (or a vendor implementation of a database system)
cannot be considered truly "relational" if it violates any of Codd's "Ten
Rules" of relational database design.  (Without "naming names," Chris Date
excoriates various vendor implementations of the relational model in his
book.  He accuses these vendors of committing various "unforgivable sins"
against the relational model.  Chris Date implies (or in some cases flat
out states) that these "sins" [of implementation] will lead to nothing
but trouble when commercial systems are designed and built using these
"flawed" implementations.  (I'm doing a lot of paraphrasing of Chris Date's
words and writing here, but I think I have the "general drift" of Date's
criticisms just about right.)

I think part of the "problem" (from the vendors perspective) may be that
creating a [truly] "relational" database system that passes muster with
Chris Date is probably very difficult - not to mention very costly.  (After
investing literally BILLIONS of dollars in research and development, a
vendor may come up with an implementation that meets the requirements of
six or seven of the ten rules - and ignores (or "violates") the other three
rules.  Chris Date focuses in on the three (or four) rules that have been
violated - and declares the whole implementation "fatally flawed".

I would have to go back and re-read "An Introduction to Database Systems,"
but I have a feeling that the introduction of "Multi-choice combos" is
the kind of thing that will drive Chris Date up the wall.

Alan C. Lawhon


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Friday, September 30, 2005 8:40 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] The future of Access, .NET and SQL

You can add MySQL to your list of offending databases. MySQL offends in two
ways, actually, but I will leave that as an exercise for the interested
reader.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust
Sent: September 29, 2005 11:05 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] The future of Access, .NET and SQL

I haven't *seen* it.  The stated concept gives me shivers because of
"databases" like Approach and FileMaker that have allowed multiple
choices stored in a single field.

Charlotte

-----Original Message-----
From: Arthur Fuller [mailto:artful at rogers.com]
Sent: Wednesday, September 28, 2005 8:05 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] The future of Access, .NET and SQL


Multi-choice combos <> relational constraints!
Case in point: I want to add N children to a parent, whose DetailType is
selected from a multi-choice combo.... i.e. add a Hotel, a CarRental, a
ConcertTicket, an AirportShuttle. The UI lets me do this as quickly as
possible, and background code takes care of the Parent-Child
relationships. I see no problem here. What are you seeing?


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte
Foust
Sent: September 28, 2005 11:22 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] The future of Access, .NET and SQL

>> Multi-choice combo box (M-M joins)

That's the one I find scary.  Does that mean they're abandoning
relational design?

Charlotte


-----Original Message-----
From: Gustav Brock [mailto:Gustav at cactus.dk]
Sent: Wednesday, September 28, 2005 6:32 AM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] The future of Access, .NET and SQL


Hi all

OK, found something in the slides at the links from Jim.
Does anyone know if "Append only" is fixed or optional?

<snip>

ACE - Access Data Engine

- Engine based on Jet code-base and installed with Office, 100%
backwards compatible with Jet
- Connects to external data sources
- Foundation for richer support of complex data
- Multi-choice combo box (M-M joins)
- Attachments
- Append only
- Read and write Excel "12" file formats
- SharePoint ISAM enhancements
- OM changes to DAO and ACE OLEDB provider (ADO)

</snip>

I guess OM here means Object Model.
Further:

<snip>

New ACCDB file format

- Can be emailed and stored in SharePoint document libraries
- Default for all new database
- Supports complex data features
- Multiple value lookups
- Attachments
- Append only
- SharePoint list offline
- Office file encryption not Jet encoding

</snip>

Also this summary:

<snip>

- Microsoft is committed to Access as a developer platform
- SharePoint Services integration allows developers to build new types
of collaborative applications
- Developers can build and deploy tracking templates

</snip>

Note that an Outlook code example in the presentation uses DAO, so this
seems not to be "dead" at all.

/gustav

>>> Gustav at cactus.dk 27-09-2005 21:03 >>>
Hi Susan and Martin

Thanks!
Just wondering what this new engine should be about ...


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list