Data Driven programming lessons

Johan Nel has written a new article in his series about Data Driven programming that originally was posted on VOPS. We have uploaded this new article as well as the previous 8 articles and the example code to the General \ Lessions section in the Downloads menu entry on this website.

Thanks Johan !


8 comments

  • 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: