My application needs to use a database. I've read online that databases are supported in some browsers but they are now deprecated? It was very confusing. I need to use a database with HTML. Is it possible to use a database with HTML5?
UPDATE
It needs a database to store data when the user is offline. It needs to support the major browsers from IE 9 on up if possible on Mac and Win on desktop and possibly Linux. The application is a client side HTML editor. There is no server side yet. So I need to persistently store "files" on the client side. Also, when I do have a server side I still need to save the users work when they have no internet connection. Later, when they go online the application can sync up with the server side. I could make do with Local storage but it is too limited in space at 5MB. That's the maximum limit? The application allows you to use images and those will be saved to base 64 data URI resources so you will quickly use up that space with just a few projects.
A few people asked why go for a database on the client. Because it's appropriate for this situation and if browsers support it then I would like to use it.
You should not use a database in the browser, even if you could, because that probably is not standard conforming. However perhaps consider HTML5 local storage
What you can is develop some web service accessing a database; that access happens in the HTTP server (so the database is used in the server, not in the browser, which just indirectly gives access to it).
I would suggest to develop your web application in Opa but you could even use PHP for that. And you could make it a CGI or a FastCGI application.
BTW; you did not tell us which operating system you are using.
You could consider making your application some specialized HTTP server, e.g. using Wt or Ocsigen -or using some HTTP server library like libonion etc- and then it could access some database (and your application could run on e.g. localhost:8086 if you wanted to).
PS. I believe that having some web pages storing a large amount of data on the client side (in the browser) is simply not reasonable (and against the standard and the spirit of the web). You should store such large data on the server side (or have some URL to download it from the server). You could decide to make a "server" application running on localhost (of course, this is operating system specific).
PPS: If coding an HTML editor, I am not sure that standard browsers are the adequate tool. You may however use the contenteditable attribute.
Check in CanIUse website.
http://caniuse.com/#feat=sql-storage
It's not DEPRECATED, but it's not supported by all browsers so far. The reason is that it did not become a valid standard because all the approaches are based in SQLite, and this is way too limited to be considered a standard.
yes go for indexedDB. Its still in development phase but you can use it
http://www.html5rocks.com/en/tutorials/indexeddb/todo/
I've read online that databases are supported in some browsers but they are now deprecated?
You're right: The Web SQL Database spec has been abandoned. There are a few browsers that still support it, but not many, and it will likely disappear entirely in the very near future.
As an alternative, a newer spec called IndexedDB is now being promoted by the browser vendors. The down-side is that it is still relatively new, and thus you will probably have many users with have browsers that do not support it.
Depending on the size of the data you need to store, you might consider Web Storage instead. This is intended just for plain text, and can't store massive quantites of data, but it is a well-established standard, so you've got a much better chance of compatibility.
If you can get away with storing a relatively small data set (ie a few megabytes or less) then this is definitely the best option here. This would certainly be my advice; try to keep your offline data requirements as small as possible, and keep them in Web Storage.
Hope that helps.
For a detailed run-down of all available browser-side storage options, you should read this article. It gives a much more detailed description of each of the options I described above, plus a few others.
Related
I am currently studying how to make cross-platform mobile apps (with xamarin forms), and I have heard that the "correct" way to connect to a database in a non-locale server (in my case located in Azure) is by using Rest Services (or rest APIs, or however is called), instead of connecting directly to the database with the server explorer option of VS like you would do in windows forms for example(using the SQL connection, dataset, etc. Which I think they are not necessary in the first case, I am not sure).
The only answer that I have received about this is that in mobile apps "They are not permanent connections. It connects, gives you data and disconnects. They are Asynchronous connections.", and that this is done "For optimization of connection resources. The mobile is suspended or the user passes the App to the background.".
But I still don't know if this is the actual reason, and if it is I don't understand how it optimizes the connection resources. So if someone has time to explain this I would appreciate it.
Thank you for your time, I hope I have explained myself correctly, and that you all have a great day.
As Jason said,the Security issues，with proper authorization having mediator is definitely much more secure than giving a user direct access to the database, because you restrict him to the end points which run only the queries you want to.And from the platform independence and maintenance,if the apps are developed in different languages and on different platforms,it may have benefit to create a common REST interface to allow sharing of data model, caching etc.For performance and scalability，that HTTP layer of your REST API provides another valuable caching mechanism. Your servers for your REST API can put caching headers on their responses, and these responses can be cached at the network layer, which scales exceptionally well.
you could read this link Why do people do REST API's instead of DBAL's?,I think the answers are pretty good
Im developing a 'Multi-User' app and considering using the new(ish) chrome packaged app platform but I have a local database question.
As I understand it (correct me if im wrong), I can store data locally with IndexedDB, but this is exclusively run on the users browser so is only relevant to that user, any changes can only sync when the user is on-line (needing an internet connection).
My app must adhere to the 'offline first' model but as each local user is located in the same physical office on a local network, id like these users to be able to share and sync the applications data without an internet connection (in case its gone down). Meaning we don't bring the whole office down if internet fails, a sort of 'off-line multi user' model.
Is there a way for a chrome packaged app to store data on an internal local database, or am I going about this the wrong way?
You could use sockets to interact with your local network, but if I had to do it, i would use a local web server as a fallback when the internet connection is offline.
That would be a pretty neat feature. Unfortunately, there aren't any web APIs (or Chrome Apps APIs) that specifically facilitate peer-to-peer communication. As xmarcos says, the primitives are there for you to build it yourself, but it would be a pretty big undertaking.
Also one correction to your question: IndexedDB doesn't sync unless you build a syncing infrastructure on top of it yourself. You might be thinking about chrome.storage.sync. However, even in that case, the syncing is replicating only a user's own data, not doing a collaborative merge of multiple users' data into a single repository. You seem to be wanting the latter, and for that you're on your own.
You might be interested in reading more about distributed version control. Here's one concise description of a complicated topic.
I've done quite some research now on HTML5, but I am still left wondering what would be my best guess to implement local data storage that is truly cross-platform (i.e., runs on all important mobile platforms + possibly on desktop), and can easily be queried?
I want an HTML5 web application (to reach all mobile/(desktop) platforms, and for its independence of third party frameworks/libraries), but using local/offline storage to mimic performance of native applications (and do not necessarily require connectivity). It creates/alters/manages certain records for a user (up to a couple of hundred records per year). Apart from data storage, as the app doesn't need any other access to the device, I think HTML5 would be a good option.
Some requirements on the data I want to store:
the best format would be some lightweight database like SQLite (due to performance reasons, and the ability to update single records without having to write a whole file (as in the case of XML))
disadvantage: I don't see any technology available across all platforms; WebSQL is deprecated, and IndexedDB is not available in too many browsers yet
the data records shall be easily exportable/downloadable in XML format (so that the user can read/modify it on his own)
therefore, XML would be a good way to go; I assume the datasize to be reasonably low for this option; 2 concerns though:
disadvantage 1: I need a query-language that allows me to easily select/sort/alter specific records (sthg like XQuery, but available in all browsers and running locally on the client)
disadvantage 2: as far as I have seen, HTML5 FileWriterAPI support is nowhere near mature - therefore, how would I be able to alter/save the XML data locally on the client? (ok, I have seen examples where the whole XML file is saved as a single key/value pair in local storage; but disadvantage 1 would still apply...)
What options do I have? Is HTML5 mature enough to do what I am longing for?
If not, what alternatives would meet my requirements? Couple of loose thoughts: some third party libraries (JQuery(?), JSON(?) or cross-platform frameworks (a la Phonegap - which I wanted to avoid in the first place, due to their limitations), or use some server-side storage (that is synced with local storage)?
I dont know what limitations of Phonegap are you talking about,
I would suggest your application needs to be a hybrid one.
According to you requirements, you need to use native SQLite in different operating systems.
For that you need to use Phonegap, where you can write your own plugin, in which javascript act as the interface and the implementation is in native code.
Otherwise you can always check out lawnchair
http://westcoastlogic.com/lawnchair/
Thanks
Gaurav Gupta
Paxcel
For others who happened upon this post. I am currently searching for a solution as well and ran into localForage which seems a pretty good choice.
https://github.com/mozilla/localForage
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I'm creating a web site that I think must have a client side database. The other option would be to stick everything on the server at the expense of increased complexity and decreased scalability. What options do I have? Must I build a plugin? Must I wait until everybody's HTML5 compliant?
Update There's been a lot of comments about why I would actually need this. Here are my thoughts. Tell me if I'm being silly:
The clients will have a large and complex state that will require something like a database to provide the data interaction that I need. Therefore (I think) cookies are out of the picture.
This data is transient, so the client won't care if it gets erased as soon as they close a session. However they will need to keep the data if they go to a different web page and then come back. Therefore (I think) somehow storing the data in some sort of a javascript SQL implementation will not work.
I can certainly do everything that I want to do on the server, and servers can scale to manage the load (Facebook). But (I think) I'd rather build a plugin than pay for the infrastructure to support this load. This is for a bare bones startup. (The richer the startup is, the barer my bones will be.)
Indexed Database (Can I use)
Web SQL (Can I use)
localStorage
I'm about 5 years late in answering this, but given that there are errors and outdated data in some of the existing answers, and unaddressed points in the original question, I figured i'd throw in my two cents.
First, contrary to what others have implied on here, localStorage is not a database. It is (or should be perceived as) a persistent, string-based key-value store...
...which may be perfectly fine for your needs (and brings me to my second point).
Do you need explicit or implicitly relationships between your data items?
How about the ability to query over said items?
Or more than 5 MB in space?
If you answered "no" to all all of the above, go with localStorage and save yourself from the headaches that are the WebSQL and IndexedDB APIs. Well, maybe just the latter headache, since the former has been deprecated.
There are also several other client-side storage facilities (native and non-native) you may want to look in to, some of which are deprecated* but still see support from some browsers:
userData*
The rest of webStorage (sessionStorage and globalStorage*)
HTML5 File System*
Flash Locally Shared Objects
Silverlight Isolated Storage
Check out BakedGoods if you want to utilize any of these facilities, and more, without having to write low-level storage operation code. With it, placing data in one (or more) of them, for example, is as simple as:
bakedGoods.set({
data: [{key: "key1", value: "val1"}, {key: "key2", value: "val2"}],
storageTypes: ["silverlight", "fileSystem", "localStorage"],
options: optionsObj,
complete: function(byStorageTypeStoredKeysObj, byStorageTypeErrorObj){}
});
Oh, and for the sake of complete transparency, BakedGoods is maintained by this guy right here :) .
Use PouchDB.
PouchDB is an open-source JavaScript database inspired by Apache CouchDB that is designed to run well within the browser.
It helps building applications that works online as well as offline.
Basically, it stores the last fetched data in the in-browser database (uses IndexedDB, WebSQL under the hood) and then syncs again when the network gets active.
I came across a JavaScript Database http://www.taffydb.com/ still trying it out myself, hope this helps.
If you are looking for a NoSQL-style db on the client you can check out http://www.forerunnerdb.com. It supports the same query language as MongoDB and has a data-binding module if you want your DOM to reflect changes to your data automatically.
It is also open source, is constantly being updated with new features and the community around it is growing rapidly.
Disclaimer, I'm the lead developer of the project.
If you feel like you need it then use it for the clients that support it and implement a server-side fallback for clients that don't.
An alternative is you can use Flash and Local Shared Objects which can store a lot more information than a cookie, will work in all browsers with Flash (which is pretty much all browsers), and store typed data. You don't have to do the whole app in Flash, you can just write a tiny utility to read/write LSO data. This can be done using straight ActionScript projects without any framework and will give you a tiny 5-15kb swf.
There are two API's you'll primarily need. SharedObject.getLocal() to get access to a LSO and read/write it's data, and ExternalInterface.addCallback which you can use to register an AS3 method as a callback to call your read/write LSO method.
SharedObject
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/SharedObject.html?filter_flex=4.1&filter_flashplayer=10.1&filter_air=2
ExternalInterface
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/external/ExternalInterface.html
These links are to Flex references but for this you can just create an ActionScript project with no need for the Flex framework and therefore greatly reduced swf size. There are a number of good IDEs including free open-source ones like FlashDevelop.
FlashDevelop
http://www.flashdevelop.org/
Check out HTML5 Local Storage:
http://people.w3.org/mike/localstorage.html
You may also find this helpful:
HTML5 database storage (SQL lite) - few questions
When Windows 98 first came out, there were a lot of us still stuck on MS-DOS 6.22. Naturally, there were really cool features on the new operating system that wouldn't run in MS-DOS.
There comes a time when some things must be left behind to make room for innovation. If your application is really innovative and will offer cool new functionality that uses the latest and greatest technologies, then some older browsers will naturally need to be left behind.
The advantage that you have is that, unlike upgrading an operating system, upgrading from IE7 to Chrome 8 or Firefox 3.6 is a more reachable goal for the average user of your app, especially if you provide a link and upgrade instructions.
I would try Mozilla's localForage. https://localforage.github.io/localForage/
I want to install a desktop application (on many stations - about 10-20) should access the SQL Server directly, no Services, and no server-DALs.
The application will be installed on a local network on about 10 machines, while one of them is a server.
When I will install the program I will set the connection string, and the applications will talk directly to the SQL server.
Is this a bad idea?
If yes, then how bad?
It is not necessarily a bad idea. If you won't need to scale then it's a valid approach.
What you are describing is often called a 2-tier client-server architecture.
You should probably encrypt the connection string in the config file (but this will only stop prying eyes, not someone intent on recovering your password). The other option is to use Windows authentication via a trusted connection, but you do lose the ability to connection pool, but that should not be an issue with 10 - 50 clients (ballpark).
Of course not.
What your describing is classic Client Server architecture, and around 50% of apps are still
built this way, according to a survey I saw recently.
Bob.
I have built plenty apps like that. I would suggest you build a DAL that is in the app itself so that if you ever need to separate data access and presentation layers, you can do so easily (plus there are other benefits like standardization of code, single place to change things, etc).
I don't see an issue with it as long as you are consistent and follow best practices.
If it's on your local network, go for it.
If it's over the internet, I'd create a web service.
Also note that there are plenty of off-the-shelf DALs (NHibernate, Entity Framework) so you don't need to roll your own, and the work just as well in client server architectures.