Standard attributes
Most data within the catalogue is likely to be in the form of simple attributes. These come in several types, each having their own restrictions on the values that they can have, as well as the operations that can be performed on them.
Strings
A string is the most permissive attribute type in the system, in that it can contain anything with no restriction on length or content, with one exception. You cannot set an attribute to contain an empty string, as this will delete the attribute from the product/folder altogether.
As a string can contain anything, there are very few special operations that can be performed on it. It is possible to use it in mathematical calculations or comparisons, should its value be a number, but it is more efficient to use one of the numeric types for those cases.
You will likely find that the majority of the attributes in a catalogue will be strings.
Boolean flags
If you have a piece of data that has no real value, but you just want to store whether it is set or not, you should use a boolean flag. For example, the attribute named "rentable" in Figure 1 only has meaning if it set, so a boolean is used. There is no real difference between using a boolean and using a string with "yes / no" values, except the former is more efficient and is a clearer representation of the data.
Booleans show up as checkboxes when editing them in the administrator. Only a value of "true" can be stored against the product, unset boolean attributes will be deleted similarly to empty strings.
Numeric values
If your data is numeric, you should store it in a numeric attribute. There are two types of numeric attribute, integers and decimal numbers. There is little difference between these types in terms of where they can be used for comparisons/calculations, but an integer attribute is smaller and faster to use, so if you know your data is always going to be an integer you should pick an integer type.
Numeric attributes can be assigned units, which will be displayed in search filters and item pages. The units will also be displayed against the attribute when using the administrator, for ready reference.
Prices
Trivial pricing systems where everyone sees the same price regardless of account information can make use of core pricing, instead of being forced to make a request to an external pricing subsystem. In this case, or if you wish to store an additional common price (e.g. cost price), you can assign a core attribute the price type. This will generate two input fields upon editing, one for the amount and one for the currency.
Prices can be converted to any currency that has an exchange rate available, plus they can be displayed in a multitude of different formats, so if you want this behaviour you should use a price rather than a fixed string attribute which would only have a single representation.
Dates
Lastly, there are date fields. These can be used to store a date independent of any particular display format, and allows the web designer to output dates to a particular user in their preferred format quickly and easily. N.B. only date precision can be stored in these attributes, they are not accurate enough to store time within a day.
There are additional operations on dates that are not available on any of the other attribute types. For example, you can check to see if an expected stock delivery date is longer than a certain period of time (say a week) in the future, and display a message to the user as appropriate.
Within the administrator, you can recognise attributes as being dates if they display a calendar control when you attempt to edit them.