jan wrote:
Storing data is an enticing idea, but flawed: stacks are not a multi-user data
storage infrastructure.
You are of course right for multi-user scenarios.
but I beg to differ in cases where
a) the data is read only for web delivery or for the majority of users
b) the "editors" are few to one; possibly even "just for me, my brother
and one hired hand"
c) you need to be able to massage that information easily independent of
a web connection.
d) You need to be able to ship the "corpus" of data to someone else to
edit it.
Think of the stack as, as a document with 3000 pages (cards), a
"manuscript" if you will and you want someone to work on it, pass it
around, put it on a thumb drive, build cool widgets to massage or
process the data. That's a miniscule amount of data from one point of view.
Recently Andre is helping us build a new web site and we are using MySQL
for the data on the back end. We don't have much choice because
rev-server does not support stacks, and RevIgniter has great dBase support.
That said... if RevServer/RevIgniter actually supported "start using" I
would, now after watching our development process, seriously think about
doing what we are doing now with stacks.
When I look at the overhead that comes with an SQL framework, I have to
shake my head, and, at least in house I will always revert to shared
stacks on our LAN server here, setting up a semaphore to lock stacks in
use is trivial...even though I could open up MySQL data base on our OSX
server, the "software at the speed of light" paradigm suddenly becomes
"Mucking along with SQL...one foot cut off and one arm tied behind your
back."
if all you know is LiveCode and you are spoiled by the speed with which
you can handle and process data with stacks. SQL Yoga and the Data Grid
are great, but so complex and vulnerable to breakage ) and so hard to
debug....We even reverted here to table fields for some desktop clients
that talk to the new MySQL dbase... How easy is it to drop a blob of tab
delimited txt into a fld and talk to that? Now if I were getting that
data from a stack on the web server, how easy would that be?
So I would heartily endorse use of stacks for small data sets. At the
very least you will be proto-typing at "light speed" and when your need
to move up to a SQL database reaches critical mass, you will have ironed
out your use cases with some precision well in advance of building your
table structures, vs build the SQLBase from the get go, based on a
"functional specifcation" and then face multiple iterations because, no
matter how well you think you have your spec nailed down... things
change... if you were using a stack based scenario, the implementation
of design change would be trivial compared to what you have to go
through with a database on the back end and the API to talk to it. then
later, porting that to MySQL or PostGreSQL would be a "Piece of Cake"
because you would know exactly where you were going.
Just my two avocados from Hawaii (coming in bushels this time of year)
Sivakatirswami
On 8/7/11 4:26 AM, Jan Schenkel wrote:
I couldn't help but wonder why you wanted to save stacks from LiveCode Server.
The important part of this support is the ability to share business logic
between desktop, mobile and server applications.
Storing data is an enticing idea, but flawed: stacks are not a multi-user data
storage infrastructure.
Invocations of your .lc script from multiple clients may come in any order, and
some processing may take longer.
And what if a user is impatient, hits the back button in his browser and pushes
the same data again?
Stick with databases for storage, especially in multi-user scenarios - it's
what the things were built for :-)
Jan Schenkel.
=====
Quartam Reports& PDF Library for LiveCode
www.quartam.com
--
Om Shanti
Sivakatirswami
Kauai Aadheenam
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
