number of columns in a table field

Kay C Lan lan.kc.macmail at gmail.com
Thu Jun 1 04:28:47 EDT 2006


On 6/1/06, Bill Marriott <wjm at wjm.org> wrote:
>
> Can you imagine the outcry if..... But the "real"
> limit is even lower when you consider the performance realities.


Hmmm.. That's exactly why I left Word and Excel behind in 91, bloatware...
but that is another issue.


> You could say, "Well, don't structure it that way. Use only the fields
> necessary for on-screen display." Unfortunately, once you are in the
> business of going into fields and setting them, Rev bogs down as well.


How many fields are you dealing with when you start to see Rev bogging down?
How much data is in those fields? With the 'on-screen' only approach, this
could only ever be a factor if you delete entire rows. For single cell
edits, I just UPDATE that single cell and just SELECT the data back in the
same cell. I get an instant update of how MySQL server sees the data - which
can be different to how it appears in REV cells (ie it may go in as Bold,
,Hoefler, coloured, non-ASCII) but comes back plain black. To get the same
from CocoaMySQL I have to reload the entire table, and that takes a lot of
time.


> What I arrived at was using a single field for each column, but it still
> is
> not as fast as deleting a line from a single field.


Actually that's very good. I can see I could use that approach for certain
types of data and especially for small datasets, more spreadsheets than dbs.
I'd have to do some experimenting, because every db is different, but for
the smallest I imagine I could go with the entire data set and load to allow
'normal' scrolling. For bigger dbs, I'd probably still stick with LIMITing
to 50 rows and going with 'stepped' scrolling. I can't imagine roughly 10
fields of 50 lines of text would take any more that the blink of the eye to
update - unless of course each line contains 65K char of text.

Thanks for the 'alternate method', now, do I have enough time to whip up a
quick test stack:-)



More information about the use-livecode mailing list