On Oct 23, 2008, at 8:33 PM, Len Morgan wrote:
Klaus,
It seems that you come from an "old fashioned" DB background (i.e.,
dBaseII, etc) where the idea of a record number meant something. If
you
read up on the history of SQL, you'll see that one of reasons for SQL
was to get rid of the concept of a record number. In fact when you
join
two or more tables, what would the "record number" represent since the
"table" that you are returning doesn't actually exist in the database
(it's created on the fly).
Well one of the great things about a record number is that it makes a
great way to mark where you are presently at, so you can go somewhere
else, do some operations and come back again. A great example is
processing an invoice, where you encounter a condition that requires
scanning the order for some condition (like a duplicate record) and
then taking up again where you left off.
What record numbers are NOT good for is using them as persistent
record identifiers, as anytime records are deleted and the database is
compacted, all the record numbers change.
As for the table not actually existing in the database, I would have
opted for a model that gave me separate cursors for each related table
in the query, and allowing me to build relations between those cursors
on the fly. If I wanted to use a master invoice record to get to all
the invoice detail records in a separate table, I cannot do that with
sequel. I have to go at it the other way.
One of my big frustrations in converting old xbase systems is that
different tables could have a field with the same name, and often did.
The customer table has a custno (customer number) field. So does the
Invoice table, and Sales Orders and so on. You referred to a field
using delimiting as in customer.custno. You cannot do that in Sequel
to my knowledge, at least not if you are going to do relational
queries on both tables, without giving custom names to the returned
cursor columns.
At any rate, there were great things about the "old fashioned" DB's.
It had it's strengths and it had it's weaknesses. You could create new
indexes on the fly, and create relations on the fly. The same holds
true for Sequel. You can manage massive datasets with sequel, and can
have many more concurrent connections with a minimal performance hit.
I think Sequel started out solving some of the problems of Dbase style
tables, and ended up replacing them entirely, which I don't think was
ever intended or even desirable.
Bob Sneidar
IT Manager
Logos Management
Calvary Chapel CM
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
