Extension and keys...

I hadn't really given it much thought, but it turns out to be pretty important that a relational DBMS be able to property track keys that are sometimes added during an extension. A trivial example:

select TableA;
ID
---
1
2
3
4

create view V
TableA add { ID + 1 OtherID };

select V;
ID OtherID
--- --------
1 2
2 3
3 4
4 5

ID is of course the key for TableA, but what are the inferred key(s) for view V? A not so mighty DBMS might say just { ID }. Thanks to a recent enhancement, Dataphor will now detect (yes even in the presence of n operators as long as they are order preserving) the additional key { OrderID }.
Why does such a thing matter? Keys turn out to be critical in a system like Dataphor where we are automatically deriving user interfaces and updating through even the most complex views. This is something that might not be appreciated until you have built a large application in Dataphor.
Another nifty Dataphor picked up recently is the ability to update key columns in ways that would violate the key at the sub-statement level. For example:
update TableA set { ID := ID + 1 };
This may seem trivial, but isn't so simple to implement even in this simple case. The naive approach is to open a cursor on the table and update row at a time. In this case, such an approach may or may not work depending on the order chosen. In general, this naive approach will fail. Now, thanks to an enhancement, Dataphor will detect that a key is involved in the update... perform a doopty doo dance maneuver and... well... do the update!

Comments

Popular posts from this blog

Don't Repeat Yourself... Really!

Virtual Appliances... poodoo

Enough software patent madness!