Both cookies and sessions are available to you as a PHP developer, and both accomplish much the same task of storing data across pages on your site. However, there are differences between the two that will make each favourable in their own circumstance.
Cookies can be set to a long lifespan, which means that data stored in a cookie can be stored for months if not years. Cookies, having their data stored on the client, work smoothly when you have a cluster of web servers, whereas sessions are stored on the server, meaning in one of your web servers handles the first request, the other web servers in your cluster will not have the stored information.
Sessions are stored on the server, which means clients do not have access to the information you store about them – this is particularly important if you store shopping baskets or other information you do not want you visitors to be able to edit by hand by hacking their cookies. Session data, being stored on your server, does not need to be transmitted with each page; clients just need to send an ID and the data is loaded from the local file. Finally, sessions can be any size you want because they are held on your server, whereas many web browsers have a limit on how big cookies can be to stop rogue web sites chewing up gigabytes of data with meaningless cookie information.
So, as you can see, each have their own advantages, but at the end of the day it usually comes down one choice: do you want your data to work when you visitor comes back the next day? If so, then your only choice is cookies – if you have any particularly sensitive information, your best bet is to store it in a database, then use the cookie to store an ID number to reference the data. If you do not need semi-permanent data, then sessions are generally preferred, as they are a little easier to use, do not require their data to be sent in entirety with each page, and are also cleaned up as soon as your visitor closes their web browser.
MyISAM was the default storage engine chosen by MySQL database, when creating a new table. But since 5.5 version, InnoDB is the default storage engine.
The major differences between these two storage engines are :
- InnoDB supports transactions which is not supported by tables which use MyISAM storage engine. InnoDB table supports foreign keys, commit, rollback, roll-and forward operations
- InnoDB has row-level locking, relational integrity i.e. supports foreign keys, which is not possible in MyISAM.
- InnoDB ‘s performance for high volume data cannot be beaten by any other storage engines available.
- The size of MyISAM table can be up to 256TB, which is huge. InnoDB tables can be upto 64 TB
- In addition, MyISAM tables can be compressed into read-only tables to save space.
Tables created in MyISAM are known to have higher speed compared to tables in InnoDB. But since InnoDB supports volume, transactions, integrity it’s always a better option which you are dealing with a larger database. It is worth mentioning that a single database can have tables of different storage engines.
MyISAM is good for read-heavy applications, but it doesn’t scale very well when there are a lot of writes. Even if you are updating one field of one row, the whole table gets locked, and no other process can even read from it until that query is finished. MyISAM is very fast at calculating SELECT COUNT(*) types of queries.
InnoDB tends to be a more complicated storage engine and can be slower than MyISAM for most small applications. But it supports row-based locking, which scales better. It also supports some more advanced features such as transactions.
– Transport Independant (REST requires HTTP. SOAP can work on HTTP, SMTP, etc)
– Built in Error Handling
– Only XML
– Provides good ACID Transactions.
– Exposes pieces of application logic , Exposes operations
– Enterprise level security since it supports WS-Security
– Suitable for banking applications
– Easier Learning Curve
– Efficient and Fast : Smaller message format
– Can use XML, JSON, etc
– REST gives access to named resources
isset — Determine if a variable is set and is not NULL
empty — Determine whether a variable is empty. it will return true if the variable is an empty string, false, array(), NULL, “0″, 0, and an unset variable. (equivalent to !$var without the notice). empty() comes with quite a few caveats, since it considers the integer 0 and the string “0” to be empty (among other things).
is_null — Finds whether a variable is NULL
is_null() is opposite of isset(), except for one difference that isset() can be applied to unknown variables, but is_null() only to declared variables
array_key_exists vs isset
isset() does not return TRUE for array keys that correspond to a NULL value, while array_key_exists() does.
$presidents = array(1 => “washington”, “adams”, “jefferson”);
if(e && e.keyCode == 13)
Then add the event to whatever scope you need eg on the div tag
<div onKeyPress="return checkSubmit(event)"/>
TLS (Transport Layer Security) and SSL (Secure Sockets Layer) are protocols that provide data encryption and authentication between applications in scenarios where that data is being sent across an insecure network, such as checking your email (How does the Secure Socket Layer work?). The terms SSL and TLS are often used interchangeably or in conjunction with each other (TLS/SSL), but one is in fact the predecessor of the other — SSL 3.0 served as the basis for TLS 1.0 which, as a result, is sometimes referred to as SSL 3.1. With this said though, is there actually a difference between the two?
While SSL and TLS differ in ways that make them inoperable with each other, they are generally considered equal in terms of security. The main difference is that, while SSL connections begin with security and proceed directly to secured communications, TLS connections first begin with an insecure “hello” to the server and only switch to secured communications after the handshake between the client and the server is successful. If the TLS handshake fails for any reason, the connection is never created.
Both Internet security protocols ensure that your data is encrypted as it is transmitted across the Internet. They also both enable you to be sure that the server that you are communication with is the server you intend to contact and not some “middle man eavesdropper”. This is possible because servers that support SSL and TLS must have certificates issued to them by a trusted third party, like Verisign or Thawte. These certificates verify that the domain name they are issued for really belongs to the server. Your computer will issue warnings to you if you try to connect to a server and the certificate that it gets back is not trusted or doesn’t match the site you are trying to connect to.
If you are mostly concerned about your level of security, you can’t really go wrong choosing either SSL or TLS.