i am writing a cms system in php 5.3 on top codeigniter. The contents of the data, i have determined, it will very in size and form and i was wondering if storing the data in JSON format in MySQL would be a good choice. I need to be able to store data in a structured way, but the way it is structured, the number of subtitles will very, the use of lists, tables, or other elements may be needed at times.
I want to create a lib of tools in the end for creating different types of sites, have the lib built very modular so that u can strip it down to the minimum sized footprint for each site.
Is JSON a the right choice or would it be to processor intensive?
JSON in MySQL? No, don't do that.
Arrays and structures are readily built from the result of a SQL query, and readily converted to JSON format (json_encode()) when needed which is not much, except when creating JavaScript.
Going the other direction is straightforward too: convert JSON to PHP arrays/hashtables (json_decode()) and use that to create a SQL query to update or insert into a set of tables.
Related
I'm quite new to programming so I apologize if the answer to my question is obvious:
I need to pass data between MySQL and an iOS app. I'm using php as the go between. The query result that I get via php I'm just passing to my app as a comma-separated/new line separated (comma for new column, new line for new row of data).
I keep reading about JSON and I've read (stackoverflow question on why json and it's associated links) to try and figure out why I would convert my php output into JSON format and then deserialize? on my app side. I keep reading how JSON is very light weight etc. but when I look at it, it seems like I would end up sending so much more data.
ex. if I'm sending some vehicle data:
JSON for 2 vehicles:
[{type:'car',wheeles:4,wings:'no'},{type:'plane',wheeles:24,wings:'yes'}]
Same info in csv:
car,4,no[/n]
plane,24,yes
Of course there are no headers in the csv, but I know that the info will come as type,wheels,wings sending it again and again I would think the total number of bits sent would be a lot more.
My questions are:
1. Would sending the CSV be faster than the JSON string (I think the answer is yes, but would like to hear from the Pros)
2. Given that it is faster and I know the order the data is coming in, is there any reason I should still choose JSON over CSV (some form of robustness of the data as JSON vs. CSV or something else)?
Would sending the CSV be faster than the JSON string (I think the answer is yes, but would like to hear from the Pros)
Given that particular data structure: Yes, but it is unlikely to be significantly faster. Especially if you use gzip compression at the HTTP level.
If profiling showed that the transfer times were the cause of a significant slow down (unlikely!), then you could always send arrays of data instead of objects.
Given that it is faster and I know the order the data is coming in, is there any reason I should still choose JSON over CSV (some form of robustness of the data as JSON vs. CSV or something else)?
JSON is properly standardised. CSV isn't (there are some common conventions and it can mostly be decoded reliably, but edge cases can be problematic).
JSON encoders and decoders are widely available and highly compatible with each other.
A JSON based format can be, to some extent, self-documenting which makes maintenance of the code that deals with it easier.
So, I found that making my WebMethod As Object, Return Dictionary rather than As String, Return JavaScriptSerializer.Serialized() reduces the size of the JSON by ~ 20%.
Yeah, I know this isn't a big deal for traditional webapps where you're serving the consumer (in the past) and a few kb would be big, but it's HUGE for B2B where you're trying to serve up to your customers AJAXd jQuery pages with far less data transmission and greater speed when transmitting dynamic tables that could be potentially 100mb before dynamicization and id lists of about 1-2mb, but I digress.
It looks like json_encode does the same thing adding more than necessary to the JSON, from what I've read on other posts. Is there a way to simply output the array as an object or build an object from multiple arrays and export that?
1) Is print (and its' family) the only way to output?
2) Is json_encode (and its' family) necessary? After all, I don't have to decode if I output properly at the jQuery level.
I'm a big fan of speed & efficiency. As AJAX/jsLibs take over, and data becomes bigger while these hunkering server-side scripts go by the wayside, it looks like the next logical objective (aside from a standardized push to client) is to keep the size of the JSON as small as possible.
How can I keep the garbage with AJAX/PHP down to a mininum? How can I export arrays as object directly?
Thanks for bearing with me. I'm terrible with vocabulary. I hope what I want to do is relatively clear enough.
As always, thanks in advance, and thank you stack for being my brain!
The problem I was having with .net webmethod was that I was javascriptserializing my output before sending it out with <ScriptMethod(ResponseFormat:=ResponseFormat.Json)> included. That's what added the extra data to my json output.
Arrays can be exported as is with json_encode, and that's all that's needed.
I am new to jquery and JSON and i am bit confused as what is best and professional approach.
Suppose i have the long list of data like song name , artist , author etc.
Now i dynamically want to dislay records from database.
I have two options
Here i return the full html and update that with the target element
Second is to retrive the JSON data full of songs info and then build that html with javascript and populate it.
I want to know which approach is better and used by high traffic sites
Second is better because of data size being sent over the network. Reducing it will improve the performance.
Write a function that will use JSON data to generate HTML elements.
If you're running a high traffic site with lots of data then the second solution, using JSON does have the advantage of only giving you the raw data and relying on the browser to generate the HTML to display the data.
Personally I would need to hear some really convincing arguments for using the first option at all.
I just started doing jQuery last week, and so far I already made some basic systems with ajax, like basic jQuery CRUD and simple chat system without referencing on other's work for I decided to test myself on how far I can do systems alone in jQuery(without JSON and XML yet).
But when I decided to look at other's work (hoping to get/learn good practices and codes out there) many or almost every program that deals with ajax have some JSON in it. So I decided to study and read JSON specially this one, but I guess because it's my first time dealing with it, I'm having a problem sinking it into my brain. Yeah I know it is a "lightweight way of describing hierarchical data", I also know how to make JSON like mixing a literal array and object in JS, and how to dsplay it in js.
But my question is, what's the difference and what's the advantage than not using it?
When I can still get and store data on the server using ajax and database without JSON.
By the way I haven't focus on XML yet because based from my research it's better to use JSON in AJAX.
Can you give me some actual scenario dealing with
s1. ajax php mysql (this with what disadvantages?)
and
s2. ajax php mysql json (this with what advantages?)
I mean, my focus is to send and get data, and I already can do it with s1.
Sorry if you find my question stupid. Tia. :)
Why use JSON? The answer is portability and structure.
JSON is portable because parsers and writers are available for many, many languages. This means that JSON that a PHP script generates can be very easily understood by a JavaScript script. It is the best way to transmit complex structures like arrays and objects, and have it still be compatible with multiple languages.
JSON provides structure because the data you transmit with it can have consistent formatting. This is instead of transmitting back plain-text (i.e. unformatted) data, like comma-separated or delimited data.
Data that is merely delimited (for example, "BookName1,BookName2,BookName3") is more difficult for humans to understand, debug, and work with. If you wanted to debug a response between your server and your browser and the data was delimited (like my example above), you might have a hard time understanding it. Also, if you want to add different data types, provide separate records, etc., then your custom data format becomes more complicated. Eventually, you might end up reinventing JSON.
As a side note, JSON is indeed better than XML. It is much more efficient space-wise. There are no tag names to take up space. Structure is created via nested braces, instead of verbose tags.
Resources
Here is an interesting article on the differences and pros/cons of XML and JSON: http://www.json.org/xml.html
Examples
Per your request, here is an example of encoding JSON with PHP. This is ripped from the docs:
$arr = array ('a'=>1,'b'=>2,'c'=>3,'d'=>4,'e'=>5);
echo json_encode($arr);
Output:
{"a":1,"b":2,"c":3,"d":4,"e":5}
Contrast this to something like this, without JSON:
a,1
b,2
c,3
d,4
e,5
To parse that, you'd have to iterate through each line, split the values yourself, and then create the array. This isn't that difficult, but imagine you have a nested object:
$arr = array ('a'=> array(1,2,3),'b'=> array('a' => 1, 'b' => 2),'c'=>3,'d'=> array(1,2,3,4,5) ,'e'=>5); // etc.
With JSON, it's no different to encode it. Just use json_encode. But, encoding this manually, and then decoding it manually would be significantly more work.
Programming in any sort of programming language, you have several different types of data at your disposal, including the very useful array type.
Interchanging data between Javascript and any server side language can only happen through strings. I.e. you can send and return any text, but there's no way to send a native array or number type.
JSON is an elegant way to express array and other types using only a string. This way you can pass arbitrary data back and forth between different environments and are not limited to pure text. XML solves the same kind of problem, but is often overkill for simple AJAX requests.
I would like to design a web app that allows me to sort, browse, and display various attributes (e.g. title, tag, description) for a collection of man pages.
Specifically, these are R documentation files within an R package that houses a collection of data sets, maintained by several people in an SVN repository. The format of these files is .Rd, which is LaTeX-like, but different.
R has functions for converting these man pages to html or pdf, but I'd like to be able to have a web interface that allows users to click on a particular keyword, and bring up a list (and brief excerpts) for those man pages that have that keyword within the \keyword{} tag.
Also, the generated html is somewhat ugly and I'd like to be able to provide my own CSS.
One obvious option is to load all the metadata I desire into a database like MySQL and design my site to run queries and fetch the appropriate data.
I'd like to avoid that to minimize upkeep for future maintainers. The number of files is small (<500) and the amount of data is small (only a couple of hundred lines per file).
My current leaning is to have a script that pulls the desired metadata from each file into a summary JSON file and load this summary.json file in PHP, decode it, and loop through the array looking for those items that have attributes that match the current query (e.g. all docs with keyword1 AND keyword2).
I was starting in that direction with the following...
$contents=file_get_contents("summary.json");
$c=json_decode($contents,true);
foreach ($c as $ind=>$val ) { .... etc
Another idea was to write a script that would convert these .Rd files to xml. In that case, are there any lightweight frameworks that make it easy to sort and search a small collection of xml files?
I'm not sure if xQuery is overkill or if I have time to dig into it...
I think I'm suffering from too-many-options-syndrome with all the AJAX temptations. Any help is greatly appreciated.
I'm looking for a super simple solution. How might some of you out there approach this?
My approach would be parsing the keywords (from your description i assume they have a special notation to distinguish them from normal words/text) from the files and storing this data as searchindex somewhere. Does not have to be mySQL, sqlite would surely be enough for your project.
A search would then be very simple.
Parsing files could be automated as post-commit-hook to your subversion repository.
Why don't you create table SUMMARIES with column for each of summary's fields?
Then you could index that with full-text index, assigning different weight to each field.
You don't need MySQL, you can use SQLite which has the the Google's full-text indexing (FTS3) built in.