Data Driven programming lessons

A great pleasure, hope it stirs some action in the data-driven world.
Johan

Had only a quick look in #9 and was somewhat puzzled by your crusade against a independent primary key, especially the drive to "recno" ;)
IMHO PK's primary purpose is to present a invariant handle to one certain group of data, independent of any change in this set. Can't see why i should loose that certainty for sparing some bits... But probably i didn't understand the thing at all :cry:

Hi Karl,
Lets put it this way:
I tried to stir a bit, but even if you look at PostgreSQL and you don't specify a PK, it will try to force you to create a "AutoNumber" field, hence my "RecNo" drive. I ask the question therefor if we look at DBF and want to make it a 2020 filesystem, how about have RecNo always as a column in each table and let the RDD handle allocating it. Do a delete/pack and we have a persistent column that does not change and we can safely use it as a referential key between tables.

I just use it in principle as my PK, but will where necessary have a "Business PK" which might be a single or multiple column key.
It makes a lot less code in a typical DBF environment where my PK have to change and I have to write "unnecessary" code to update all child tables with the new PK. In a RDBMS like PG, it will save a lot of server processing due to cascaded updates which such an implementation eliminates. I don't try to force it on people, it is just a design principle I follow.
Hope it clarify some misunderstanding.
Johan

Hi Johan,
seems we have to clearify what you see als "RecNo" - if this is, as i understand it, (only) a record counter, there's NO invariant bond between it's value and a certain record.
But for me a PK is by definition invariant over the lifetime of a set of data, so this disqualifies recno as well as every (compounded other set of) values which use the actual content of this record, due to it's changeability.

Hi Karl,
Ok I understand your reasoning, my apologies for confusion. Where you see RecNo in my article, replace with "RunningNo" a persistent value over the lifetime of the Row in the table. So in RDBMS Terms AutoNumber/Sequence/Serial if we use the terms used by MS/Oracle/PG.
Johan

[quote name="Johan Nel"]where you see RecNo in my article, replace with "RunningNo" a persistent value over the lifetime of the Row in the table. So in RDBMS Terms AutoNumber/Sequence/Serial if we use the terms used by MS/Oracle/PG.
Johan[/quote]Good Morning! Ok, thought so ;) - the problem is, VO/VN has a property RecNo, hence the ambiguity... BTW, why not "ID" ? Shorter, clearly notes the reason of existance and no restriction "how" this is implementend ;)

[quote name="Karl Faller"][quote name="Johan Nel"]where you see RecNo in my article, replace with "RunningNo" a persistent value over the lifetime of the Row in the table. So in RDBMS Terms AutoNumber/Sequence/Serial if we use the terms used by MS/Oracle/PG.
Johan[/quote]Good Morning! Ok, thought so ;) - the problem is, VO/VN has a property RecNo, hence the ambiguity... BTW, why not "ID" ? Shorter, clearly notes the reason of existance and no restriction "how" this is implementend ;)[/quote]
Damn you Germans are difficult to satisfy :-)
I agree, but lets say I want to write a new RDD, and you use it on existing code, behind the scenes RecNo behave totally different, but from an end-user perspective RecNo will still behave the same, even if you "pack" between two goto operations. Remember, I use the terms from a data-driven perspective, not a hard-coded environment.
Johan
PS: Think I am closing the discussion otherwise you never get to read Article 10... :lol: