On 10/25/06, Christian Smith <[EMAIL PROTECTED]> wrote:
A better solution would be to transfer the contents of the table being updated to a temporary table, then recreate the original tables sans the surplus columnn: <snip> It may not be quick for large tables, but how often are you going to be updating the table definition? If often, then you probably have a more fundamental problem on your hands.
I considered this kind of solution briefly, but I'm afraid that users might have too much data for this to be effecient at all. It wouldn't happen a lot, but that rebuilding will have to happen between user interactions. The user is basically allowed to create a form template attached to an object. This template has an ID and a table devoted to that type (user_data_nn). A row in a user_tables: ID name fields 01 "Person" "name,email,site" Then user_data_01 is created with 3 generic columns. If the total field count ever drops below 3, it's simply ignored. So what's really <name=Isaac, [EMAIL PROTECTED], Site=blueapples.org> looks like: user_data_01 ID f1 f2 f3 1 Isaac [EMAIL PROTECTED] blueapples.org I guess I'm not actually seeing a downside. The application can keep track of the name of the fields as shown to the user.
If your data format is by definition user defined, then you might be best off with an <instance,name,value> table instead, and use views to map instances into a virtual table.
Well some of it is, some of it isn't. This is sort of a side feature of a larger program. Granted, with this kind of flexibility it almost sort of becomes the major feature of the application. If the <intance,name,value> thing is really, really efficient I might consider it, but the views thing sort of gives me pause. Sounds like that might become unstable... Isaac ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
