pete at mollysrevenge.com
Tue Dec 20 20:25:50 CST 2011
That's the way I took it, I probably should have been more specific in the
I guess my comment was made in the mode of my other response that the
decision as to whether to use a database or not goes way deeper than memory
and performance issues and depends on the application's requirements.
Internal storage is great for a simple, one-dimensional dataset and will
beat a database hands down on the performance front, no argument there.
But as soon as you get into multiple datasets with links between them or
multiple ways to access one dataset or multiple users accessing the same
data, there's a strong justification to use a database unless the
performance/memory issues are so bad that you can't deal with them (which I
find difficult to believe).
On Tue, Dec 20, 2011 at 5:57 PM, Mark Wieder <mwieder at ahsoftware.net> wrote:
> Tuesday, December 20, 2011, 4:10:22 PM, you wrote:
> > ... and that's a bad thing?
> Possibly. Bernard was making the point that, no it's not, it's part of
> why arrays are faster than databases. But the other side of that coin
> is that arrays don't have machinery (null checking, referential integrity,
> etc.) and therefore you have to add all the validation yourself. So
> the lack of the database validation things won't slow you down until
> you get to the point where you do the things that are built into the
> database machinery anyway, and probably in a faster implementation
> than anything you could do by scripting.
> -Mark Wieder
> mwieder at ahsoftware.net
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
Molly's Revenge <http://www.mollysrevenge.com>
More information about the use-livecode