This content has been marked as final. Show 11 replies
Depends on what you want,
If you have got 3 megs of static info, you might want to integrate it into your flex app. On the other hand, using a webservice has some nice advantages, it makes the information accessable dynamicly.
If you want to use a mySQL db you can also try to use php to retrieve your information.
It all depends on what the main goal of the application is.
Maybe I'm not understanding your issue - you have 14k records (about 3mb) - are you planning on loading all that into the flex app at one time? I'm not sure how that would work with performance, but I can't imagine it would be good!
There are fundamental differences between what static XML offers, and what you can do with a web service. A web service exposes, in a relatively controlled manner, your internal business logic. So, if it's likely that a user would want to see one record - or a number less than 14k - at a time, and it's unlikely that they will want to see ALL of the 14k records in one sitting - then I'd say go with a web service.
In that instance, you would indeed store your data in a SQL DB (how do you store them now, as a matter of interest?). You would use a web development language (ColdFusion is my choice, but you could use ASP, PHP, etc) to create the web service, and functions that get the data from the DB.
You flex app would call this web service when needed. As for speed, I'm not sure I can quantify this - there would be a host of factors that would impact this (the quality of your web service code, for example). Web services are not the fastest way to exchange data in Flex - ColdFusion remoting is.
I can't give you a specific answer, as I don't know most of the details. It appears to me that you want a web service, or if you can manage it, a ColdFusion component to dish up the data on an as-needed basis.
Post back if I can help more.
And don't overlook HTTPService. It is much simpler and somewhat faster that a WebService.
I think the underlying issue is the misconception that you need to load up all that data at a one-shot wham-bam-thank-you-mam big-bang theory style go.
I don't think you can present 14k records in one view, or time. You may need to get creative on this one. Present a set of records and on an event fetch the next set.
just my 2 cents about the speed of webservices.
I'm working on a flex application to manage a database with about 40 tables, with primary and foreign keys, the largest table has 70000 records at his time, i don't get it all at the same time because it would be a mistake but i've tried to get it all and with my webservice it takes me about 10 seconds and this on a windows xp with iis on it. when i've tested it on my windows 2003 server it took only 5 seconds so webservices in my opinion are fast enough. Just one more thing , i've tested it width about 20 users requesting the server.
Thx, for the replies.
Our client is now going to have another look at all the data. It's problably going to be a webservice considering that the end user doesn't have to look at all the records at once. The Flex app is a product configurator.
Is anyone experienced with FlexSQL? - http://www.flexcubed.com/component_details.php?id=FlexSQL
FlexSQL is a Flex RIA component designed to run SQL queries directly in Flex at runtime and get results back into Flex as a standard XML with bindable data.
You can now run your SELECT, UPDATE, INSERT, DELETE etc queries directly. The component can automatically load data into your components once data changes using the Bindable method.
Events triggers and error reporting are well handled in FlexSQL.
It has been designed for ASP, Colfusion and PHP servers and can work on MySQL, MS Access, MS SQL and other DSN based datasources.
I found it via Adobe Exchange. I guess this works via a HTTPService?
Yes, to add to this, in my experience, the bottleneck is not the data retrieval speed. All of three of the RPC protocols are very fast.
The real bottleneck is the rendering of the visual components in the flash player.
More troubles in paradise...
I'm now looking at about 80.000 records AND the application should also run as a stand-alone application, so without an internet connection.
This means as far as I see it, it has to be in an XML file. --> about 7-8 MB :(
Then what is critical is how you choose to display the data.
Be sure to have the app render as few visual items as possible.
Maybe look into cursors to page through your data, displaying only a few at a time.
As tracy has more experience in these matter, I'll defer to his judgement, however, not having an internet connection doesn't pre-clude you using web technologies. ASP, PHP, CF, etc can all be run on standalone servers, as can a DB like MySQL. Do you still want to load 80k records all at once? What will the user do with all of that information? Will they be updating the information? If so, you'll write back 80k records (the majority of which I assume haven't changed) to a flat file - I'd be more worried about data integrity in that case.
But, again, I'm replying to a business solution to which I understand very little about. My few cents, for what they're worth!