在mysql中将int值存储为varchar是否会严重影响性能？

Question

I'm working on a website which should be multilingual and also in some products number of fields may be more than other products (for example may be in the future a products have an extra feature which old products doesn't have it). because of this problem I decided to have a product table with common fields which all products can have and in all languages are same (like width and height) and add another three tables for storing extra fields as below:

field (id,name)
field_name(field_id,lang_id,name)
field_value(product_id, field_id, lang_id, value)

by doing this I can fetch all the values from one table but the problem is that values can be in different types, for example it could be a number or a text. I checked on an open source project "Drupal" and in that they create a table for each field type and by doing joins they will retrieve a node data. I want to know which way will impact the performance more? having a table for each extra field or storing all of their value in one table and convert their type on the fly by casting?

thank you in advance

Answer 1

Yes, but no. You are storing your data in an entity-attribute-value form (EAV). This is rather inefficient in general. Here are some issues:

• As you have written it, you cannot do type checking.
• You cannot set-up foreign key relationships in the database.
• Fetching the results for a single row requires multiple join s or a group by .
• You cannot write indexes on a specific column to speed access.

There are some work-arounds. You can get around the typing issue by having separate columns for different types. So, the data structure would have:

• Name
• Type
• ValueString
• ValueInt
• ValueDecimal

Or whatever types you want to support.

There are some other "tricks" if you want to go this route. The most important is to decimal align the numbers. So, instead of storing '1' and '10' , you would store ' 1' and '10' . This makes the value more amenable to ordering.

When faced with such a problem, I often advocate a hybrid approach. This approach would have a fixed record with the important properties all nicely located in columns with appropriate types and indexes -- columns such as:

• ProductReleaseDate
• ProductDescription
• ProductCode

And whatever values are most useful. An EAV table can then be used for additional properties that are optional. This generally balances the power of the relational database to handle structured data along with the flexibility of an EAV approach to support variable columns.