I have settings of users, which I would like to save in the Database.
The question is now, whether or not I should make for each setting a new row, OR save them in a JSON.
What is the best way to go with, strategic- and habitwise?
Depends on several things:
How many settings do you have?
Do you expect them to rapidly change - both creating new settings and deleting old settings?
Do you need to search for users with specific settings?
Basically, JSON is more flexible and is good if you have lots of settings or if your list of settings is rapidly changing.
Fields are conservative but working with them is way faster than unpacking JSON.
Most often for user settings I would use one field per setting. The reason is that it allows easily getting a list of users with specific setting set (same age, same sex, same city etc.), also ordering them and so on.
But you can use both these options at the same time.
For example, put username, password, firstname and basic options as fields. Then you can quickly get the answers to the questions like "Is this username unique?" "is the password valid" etc.
At the same time you may create a field "additional_options" that will be json-encoded field for some not-so-often-used data, like "about me" and answers to secret questions.
JSON is a way to encode objects, or just serialize data in an easy fashion.
If you plan on saving the data and reading it not very often then JSON sounds like a good clean way, easy to upgrade later when you have more settings. If you plan on writing and reading this data a lot then you will have a big overhead of serializing and de-serializing the data and I would not recommend this.
The question is tagged as javascript, so I assume you are consuming them from js. In this case and assuming they are a small number of key-value pairs, and that you probably read them all together (ie you are not querying them individually or comparing their values for different users or things like that), then storing as json is the better option in my opinion.
Related
I have a set of data associating zipcodes to GPS coordinates (namely latitude and longitude). The very nature of the data makes it immutable, so it has no need to be updated.
What are the pro and cons of storing them in a SQL database vs directly as a JavaScript hashmap? The table resides on the server, it's Node.js, so this is not a server vs browser question.
When retrieving data, one is sync, the other async, but there is less than 10k elements, so I'm not sure whether storing these in MySQL and querying them justifies the overhead.
As there is no complex querying need, are there some points to consider that would justify having the dataset in a database?
* querying speed and CPU used for retrieving a pair,
* RAM used for a big dataset that would need to fit into working memory.
I guess that for a way bigger dataset, (like 100k, 1M or more), it would be too costly in memory and a better fit for the database.
Also, JavaScript obejects use hash tables internally, so we can infer they perform well even with non trivial datasets.
Still, would a database be more efficient at retrieving a value from an indexed key than a simple hashmap?
Anything else I'm not thinking about?
You're basically asking a scalability question... "At what point do I swap from storing things in a program to storing things in a databse?"
Concurrency, persistence, maintainability, security, etc.... are all factors.
If the data is open knowledge, only used by one instance of one program, and will never change, then just hard code it or store it in a flat file.
When you have many applications with different permissions calling a set of data and making changes, a database really shines.
Most basically, an SQL database will [probably ...] be "server side," while your JavaScript hash-table will be "client side." Does the data need to be persisted from one request to the next, and between separate invocations of the JavaScript program? If so, it must be stored ... somewhere.
The decision of whether to use "a hash table" is also up to you: hash tables are great when you are looking for explicit keys. But they're not the only data-structure available to you in JavaScript.
I'd say: carefully work out all the particulars of your exact situation, and use these to inform your decision. "An online web forum like this one" really can't step into your shoes on this. "You're the engineer ..."
I have an application that involves storing and retrieving lots of user-formatted content using a WYSIWYG html editor. Kind of like how SO saves formatted questions and answers.
What's the standard approach to do this?
EDIT:
Just to clarify: I am not asking about the data type to store in the DB. Rather I am concerned about storing chunks of html tags with style information in the DB.
This is just text data. Usually a VARCHAR is best.
UPDATE:
Yes, if you want to support Unicode (which you probably do in this case) then make that an NVARCHAR.
As for the OPs update, you are imagining difficulties which don't really exist. HTML is textual data so it goes into a text field. You do not want to separate the formatting from the text at all.
That is the answer but it isn't the end of your concerns on this matter. The reason doing this is bothering you is probably because databases use structured data (all of the data is in named and typed columns) and this is unstructured content. Meaning that the data in this field is not being stored in a DB friendly manner. You should try to structure your data as much as possible because it allows you to quickly search by the field values. We are throwing anything the user types into that field and if we ever need to find data in that field we'll need to search the entire field to find it. This is very slow process and to make things worse we aren't just searching through the text but also the formatting for that text.
This is all true and not good so we should avoid doing this as much as possible. If you can avoid allowing users to enter free form text then do so by all means. From that point you can apply HTML formatting to the data from your client application in a fast and consistent manner.
However, the basis of this question is that you want a field of unstructured content and you are asking how to store that unstructured content. That answer is pretty simple (even though I guess that I didn't get it 100% correct the first try), use NVARCHAR.
Even though storing this unstructured content is not DB friendly it is sometimes website friendly and a common practice in the situation you are describing. The thing to remember is that we want to avoid searching on this unstructured data. We may need to go to fairly extreme measures to do so.
Many applications will solve this slow search problem by creating a separate table and parsing the text out of the HTML and inserting each individual word (along with the foreign key for the original tables entry) into that other table to be searched on later. Even if you do this you'll still want to keep your original formatted text for display purposes.
I generally make this type of optimization Phase II because the site will function without such optimizations; it'll just be slower and that isn't going to even be noticed until the site has plenty of content to search through.
One other thing to note is that often this will not be HTML formatted text. There are several formats commonly used such as BBCode or Markdown. SQL doesn't care though, to your SQL server this is all just text.
The title of the question could be stored in a VARCHAR and the question in a TEXT.
Here, have a look at the data types of the SQL Server: http://msdn.microsoft.com/en-us/library/ms187752.aspx
I'm making a to-do list application with HTML, CSS, and JavaScript, and I think the best way for me to store the data would be a local database. I know how to use localStorage and sessionStorage, and I also know how to use an online MySQL database. However, this application must be able to run offline and should store its data offline.
Is there a way I could do this with just HTML and JavaScript?
Responding to comments:
"You said you know how to use localStorage... so what seems to be the problem?"
#Lior All I know about localStorage is that you can store a single result, as a variable whereas I wish to store a row with different columns containing diffenent data about the object. However, can localStorage hold an object and if so is it referenced with the usual object notation?
Any implementation will probably depend on what browser(s) your users prefer to use.
#paul I think chrome will be most popular.
Okay, I would like to clarify that what I was asking was indeed How can I do this with JavaScript and HTML rather than Is there a way I could do this with just HTML and JavaScript?. Basically, I wanted a type of SQL database that would save its contents on the user's machine instead of online.
What solved my problem was using WebDB or WEBSQL (I think it was called something like that that).
I'm about 3 years late in answering this, but considering that there was no actual discussion on the available options at the time, and that the database that OP ended up choosing is now deprecated, I figured i'd throw in my two cents on the matter.
First, one needs to consider whether one actually needs a client-side database. More specifically...
Do you need explicit or implicit 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 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, as previously mentioned , been deprecated.
Otherwise, IndexedDB is the only option as far as native client-side databases go, given it is the only one that remains on the W3C standards track.
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 the first encountered native database which is supported on a client, for example, is as simple as:
bakedGoods.set({
data: [{key: "key1", value: "val1"}, {key: "key2", value: "val2"}],
storageTypes: ["indexedDB", "webSQL"],
//Will be polyfilled with defaults for equivalent database structures
optionsObj: {conductDisjointly: false},
complete: function(byStorageTypeStoredKeysObj, byStorageTypeErrorObj){}
});
Oh, and for the sake of complete transparency, BakedGoods is maintained by this guy right here :) .
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
At one interview, once I attended, I was asked to create one java script based functionality in which I was said to create one form (say i.e first name, last name, email, age) and one listing(actually listing was kind of another form storing multiple entries) below this form. On submitting this form one new row was added to listing. However it is possible to remove any previously added listing row. and after adding removing, finally need to store this final state of listing. ( Kind of form post and server side scripting comes into picture )
So what I did that, On Form submit, adding a new <tr> row in listing table at the same time I serialized all form data except submit button using jQuery serialize and stored it in one hidden element of listing form.
On removing listing row, I was removing <tr> row along with respective hidden element for the same row.
All was working like great without any error. But the interviewer asked me that "The approach I used (hidden elements) was really proper?".
I replied, I could have used json?
but Could not crack interview.
So I want to know what is best approach that We can use to store data in such conditions?
Another approach for client-side is to keep a list of objects separately and only store the reference to each item inside a property of your DOM element. This approach is very similar to what jQuery's $.fn.data() provides and has these advantages:
You don't have to serialize anything, the data stays in its native format; it should be said that you could have achieved this by adding a property as well.
All your data is kept in one place instead of scattered around in the DOM.
This is an example implementation:
(function(ns) {
var entries = {},
entryId = 1;
ns.Entries = {
addEntry: function(data) {
entries[entryId] = data;
return entryId++;
},
getEntryById: function(id) {
return entries[id] || null;
}
};
}(this));
Calling Entries.addEntry returns an identifier that you can store in one of the DOM element's properties:
tr.entryId = Entries.addEntry(data);
Later you can use that entryId property to find the corresponding data in the entry list and use it.
var data = Entries.getEntryById(tr.entryId);
Demo
Of course, this particular functionality can also be solved server-side by using sessions.
Thanks to HTML5, we now have the ability to embed custom data attributes on all HTML elements. These new custom data attributes consist of two parts:
Attribute Name
The data attribute name must be at least one character long and must be prefixed with 'data-'. It should not contain any uppercase letters.
Attribute Value
The attribute value can be any string.
Using this syntax, we can add application data to our markup as shown below:
<ul id="vegetable-seeds">
<li data-spacing="10cm" data-sowing-time="March to June">Carrots</li>
<li data-spacing="30cm" data-sowing-time="February to March">Celery</li>
<li data-spacing="3cm" data-sowing-time="March to September">Radishes</li>
</ul>
We can now use this stored data in our site’s JavaScript to create a richer, more engaging user experience. Imagine that when a user clicks on a vegetable a new layer opens up in the browser displaying the additional seed spacing and sowing instructions. Thanks to the data- attributes we’ve added to our <li> elements, we can now display this information instantly without having to worry about making any Ajax calls and without having to make any server-side database queries.
source: HTML5 Doctor
There are other methods too I believe.
Actually instead of using hidden elements , you can add data to the html elements using jQuery. This is a better approach to make your data a little less obvious/direct to the users. Check the data() in jQuery.
Nothing wrong with storing data client-side if the user can be trusted with it and nothing terrible happens to your system when he messes with it.
Only problem I can see with using hidden fields (or cookies) is that they get sent with every request, which might waste bandwidth. Not sure if that applies to your case, probably not, because you say you just submit once when all is done.
The problem with solutions that 'just work' is that they are not abstract enough and therefore tend to cause problems in the future. Consider your example; should you decide to store the temporary data in Local Storage (to allow users close their browser and return to it later), you'd have to rewrite how you store your data. If you stored it in a variable, you'd be able to add 'Save to Local Storage' just as easily as 'Submit to server' or 'Pass to Any Other Function' functionality. Your 'hidden element' approach would have to be rewritten for any purpose except posting to service.
To start with, multiple forms on one page are wrong - it's data loss antipattern. The correct approach would be to place everything into one form. This way, it would work even without JS and you could use JS only to improve usability, not to provide basic functionality. This solution would degrade gracefully an it would be easy to debug and maintain.
Of course, saving the data in hidden field is a valid technique.
By writing submitted data into the form itself, and reading again from it, you've tied these two elements together - they are said to be tightly coupled.
What word happen if another requirement came through to displaye previously submitted data in the table also? Or to put the form on a separate page?
If you take a more MVC approach, you can separate out the logic for the various parts - reading, writing and sending data. For example, as you said, writing and reading from a JSON model. This would make each aspect more readily extensible in the future.
I will not answer your question directly but will focus on interview and method you chose.
I would say you chose wrong way and well known IT company you applied this solution for can have problems.
You chose the way to store everything on client's side, but you shouldn't! As your client can lose a lot of data this way, because imagine the case when your listing form will never be sent? User will just forget to hit send (never trust user!). Then you lose everything... whole progress of your work... and let's say you've already added 50 listing items...
Also adding items like this can easily make your session expired (no requests to the server) and no data will be saved, because user will have to log in again. And you will have to handle it as well, or you will lose everything!
Sorry for exclamation marks, but I think data is crucial (especially for your client) so do not ever offer solutions which can make client losing it somehow.
So:
It's not bad to store data in HTML elements, but you need to apply this solution very carefully.
LocalStorage doesn't work here. I am looking for more of a theory type answer and not as much code. I already know how to set and delete cookies, that is now what this question is about; here is the question:
When I submit an order, I want to place
Meal
Ingredients
Name
Phone
inside cookies to be later outputted on a div to the right of the page. This I think I can do quite easily. I might put each value into an object of orders...
But that isn't the real question, how can I have multiple orders that are unique? I want to have many different orders and have the user delete the order they desire. I was thinking of separating each order with a | character and than playing some string games. But I don't know how I would delete one.
My other idea was have a order id and auto-increment it. Any help? website: philipimperato.com/mobileOrder
P.S. Only Javascript and I know how to setCookie and deleteCookie :D
Cookies don't seem the place do to this anymore. Cookies are limited and are sent with each HTTP request, including all of your images and static files unless they are on a different domain. I recommend using localStorage instead. Since this is intended for smartphones like the iPhone and Android you are ok to use localStorage. Webkit browsers have supported it for a long time. If you use localStorage you can use any kind of key value storage mechanism you like. I recommend the redis way of field:id:property for keys.
var order_id = 10203;
var key = 'order:' + order_id + ':drink';
localStorage[key] = 'Pepsi';
By using the order_id in your key field you can easily manage unique orders.
You could serialize an order object array in json and parse it back as you load
(This could present security issues, and maybe you should use a framework to parse json back to life. Many frameworks do some lint on json before evaluating it, some even parse it all by themselves)