I am surprised this thread has drawn so much discussion. It's good discussion but scanning back over it a key point is that all of these contortions and workarounds to preserve a number sequence are based on the single design decision to use an invoice (in this case) number as a key field. I'm not criticizing of course - I used to do this as well and still have a few cases where that sort of design exists though nothing involving number series where gaps are an issue. Not to mention I've been doing 4D long enough to recall the first discussions about data normalization the community had and the, erm, hesitant embrace of it by many.
This thread illustrates a way structural decisions manifest over time. It jumps out at me particularly now because I'm finding this especially true working with v17 and ORDA - the coding flows so easily if the structure supports it and can become extremely complicated when it doesn't. Something I like about working with ORDA (which I'm misusing as a collective noun for all the 'new' language features) is how easy it is to abstract the key value of a record without having to work with the actual value. This makes using UUIDs for key values much easier. I like UUIDs for key values precisely because it eliminates any lazy kludge to use it as part of the data - it's always part of the structure. True, looking at a column of UUIDs is not as useful as looking at column of longints. If I need or want a serial record count I add it as a separate field as I do something like invoice, order, check or inventory transaction numbers. Years ago it could matter if a couple of extra fields were in a table (though you wouldn't guess looking at a lot of mature 4D structures) but not so much now. If I want a number series to remain pristine I assign the value as the very last action prior to saving and validating the transaction. From that point on a missing number is a management issue for users and not a programming issue for me. Another technique I'm using more and more for things like identifiers is encoding longints in a base 26 alpha string (a=0, b=1, ...). I got the idea from airline tickets. I noticed all my reservations and such have been identified by an alpha code of a few letters. For instance, 10546789 encodes to XCBTT. Well that's a lot easier to recognize and recall and it sorts. -- Kirk Brooks San Francisco, CA ======================= *We go vote - they go home* ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
