Bob Calco wrote: >> It is great for *single user* applications running locally on the same >> machine as the app. I wouldn't consider it for multi-user, ever. >> > > I disagree with the "ever" part. > > Certainly, I agree it's not appropriate for multiple clients connecting to > the same db file from different machines. In that sense only, I agree with > your statement completely. > > But I think SQLite works GREAT for massively *multi-user* rich internet apps > as a local cache so clients can work in disconnected mode.
Oh, absolutely. In fact, this is something I'm planning for in my own app, and one of the reasons I chose SQLite. My app is a fat desktop app that is single-user and saves its data to a local SQLite database. However, there's a web service in place to sync up the local data with the server, merging data smartly, etc. The server db is MySQL for other reasons, but that doesn't really matter. So everyone (1 user to 1000's of users) can use the app locally, disconnected if they wish, and the data changes eventually (immediately if connected) make it to the server db. I can't think of a better db to use on the client machine than SQLite. > In fact I usually > have the rich clients work over an abstraction layer with their local SQLite > database, and have a background process that keeps the local SQLite copy > "current" with a master database exposed over a RESTful API when there is an > internet connection that makes it reachable, and if not, does replication > with the DB of record when it comes back online. Sounds similar. I haven't delved into RESTful apps yet, but I've been meaning to. > This approach also forces you to keep your business objects/domain model > logically separated from the code that fetches data into them and out of > them. My apps only work with lists of business objects--they have no idea > whether they're being fetched over the internet or via a local SQLite DB. My app knows about the sqlite db, but the ui doesn't. IOW, the UI gets/sets the data in the bizobj, the bizobj gets/sets with the db abstraction layer in my app, and that layer actually does the SQLite DML and transaction commits. > Another equally valid multi-user approach leveraging SQLite is to write a > "server" in your favorite language (yea, even Python, if you're into that) > that uses SQLite under the hood on the server side. Now any number of > clients can connect to it over whatever protocol you wish to fetch data. > RESTful web services are all the rage right now, so I've been into that > strategy. I think that once you get to the level of needing a db server, you should just use one of the excellent ones already available (PostgreSQL, MySQL...) But I agree this would be possible and even fun to do. > I just happen at the moment to prefer Erlang for the RESTful data service > implementation, because it kicks butt when it comes to writing scalable, > highly-available, robust services generally. The magic of its lightweight > threading, pattern matching capabilities, and built-in framework for > arbitrarily complex supervision trees, not to mention language-integrated > DBMS, have me completely sold on Erlang as a solid platform for all things > client-server, including web services. I've heard that, too. Erlang is another technology I've been meaning to take a look at. Although, I must say Python has served me well as my general programming language of choice. > But that's another subject, definitely drifting well off into NF > land...hence I've taken the liberty to prepend this subject with [NF]. I'm enjoying this discussion, but it is indeed [NF]. Paul _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
