Two DB questions

[Bob Sneidar]

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