Subject RE: [IB-Architect] proc directory type information tables
Author Lee Rodgers
--- Jim Starkey <jas@...> wrote:
>However,
>the purpose of the SQL standard in the database
>industry is a barrier
>to entry, not promotion of interoperability.

Heck, it's sometimes just a barrier...

Like the difference between the UPDATE and INSERT
grammars.
That we have a good simple UPDATE command:
UPDATE <table> SET <name=value pairs>
and a prone-to-error INSERT command:
INSERT (name1 name2 name3) (value1 value2 value3)
is stupid and pointless. The INSERT syntax should look
like UPDATE's so you avoid common placement mistakes
with INSERT like:
INSERT (name1 name2 name3) (value2 value1 value3)

The INSERT cmd should have as an arg "SET" that
interprets name=val arg lists:

INSERT <table> SET <name=value pairs>

If FireBird could implement that syntax, y'all'd get a
chorus of approval from around the world.

Another idea I heard recently from a proj lead who
wondered why DBMS's don't check the row's values (via
a checksum or some such) to see if the UPDATE would
actually modify any data or not. If the UPDATE stream
was indentical to the current data, or wouldn't change
the row, to not perform the update so to save I/O.. I
agreed, esp. from a DBA's perspective, it'd be great
for UPDATE to have a "CHECK DISTINCT" clause to
prevent unnecessary logged operations.. in a busy OLTP
DB more than half the I/O and most of the bottleneck
is sitting on the hotspot at the end of the tran. log.


I guess it'd go like this: Before the write, the
record still needs to put into some working space's
page in memory, regardless. To me, it'd be simple,
match checksums & check *before* writing to the log,
and the page isn't marked as dirty, and checkpoint has
one less row to write to the table. It'd be better
suited to systems with lots of RAM so the buffer/cache
page would be checked before having to move/steal
cache pages to double-check the record.

Best regards,


=====
+--------------------------+
/leebert
+--------------------------+
This concludes our broadcast day.

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/