> It surprises me that no one has pointed out that having complex tables > assembled/compiled into a program is generally a Bad Idea. Almost always > such tables have to be updated and that tends to require a programmer, > rather than anyone with a text editor, if the tables are read into storage at > program start, which generally is not going to be a significant overhead. Then > one is also not limited by whatever restrictions are in the > compiler/assembler.
I completely agree but we make a difference between tables with 'functional' data and 'technical' data. Functional data is stuff like country codes, currency codes, holidays etc. Technical data is stuff like program parameters, system configuration and the like. Maintaining this technical data requires a dev engineer anyway. My =literal problem does not occur in a *table* but a (technical) data *structure* that cannot easily/efficiently be represented by a table... Fred! ----------------------------------------------------------------- ATTENTION: The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately. -----------------------------------------------------------------
