I have a content management system in which a user can dynamically create an html form. I have all the tables setup for that. But there's one thing that troubles me and that is, the text size for the entered values.
Some forms have textareas and some textareas contain quite an amount of data. But there are also just simple textfields on the form, which contain just a few characters of data.
My database table for saving the values kind of looks like this:
form_values
id | form_id | fk_element_id | value
So in this case the value column will hold the entered data for a specific field type. So in the case of a textfield this will only be a few characters. But in the case of a textarea, this can be alot of data.
That means the value column must be at least of type TEXT. Eventhough most types will not exceed 255 characters (MAX VARCHAR).
Now i'm not sure if this is the right approach. Will this give a performance penalty when i query the table? Do i have to save the textarea data in another table..? Or something like that?
Or can i simply change the value column to a TEXT type without any problems..?
VARCHAR maximum length is 255 prior to MySQL 5.0.3 , from MySQL 5.0.3 onwards the maximum length is 65535 , which is the maximun row size, so that maximum value is shared among all fields in the row.
See dev.mysql.com/doc/refman/5.0/en/char.html
Related
At what point should one consider using the memo field type as opposed to the text field type in a MS Access database? I realize the primary consideration is the length of the field, as text is limited to 255 chars, and the memo field really can't be used in a query criteria, but are there other considerations? The text field reserves the space for every record, but the memo field only uses space for the text entered?
You mentioned text length as the primary consideration. For me, that is more like the only consideration. If the field has to hold no more than 255 characters, it will be text instead of memo type.
The only exception I can remember was bumping up against the per-record 4,000 character limit. See Access 2010 specifications:
Number of characters in a record (excluding Memo and OLE Object
fields) when the UnicodeCompression property of the fields is set to
Yes
4,000
Since memo fields do not count against that limit, I made some fields memo simply to keep the remainder of the record's character count within the limit.
But that was a one-time situation.
If you want to store Access' "rich text", you would want a memo field. (Thanks, Gord.)
Off the top of my head, I can't think of any other reasons to choose memo when text would suffice.
I have a MySQL database table, which have more than 100 columns. I have to add two more columns, which if entered by user, keeps text data in it, but which is hardly used.
Now my question is, what will happen if I make it as "medium text" sized column and most of the user don't enter it. Will that column still takes the given memory, or only when user enters in to it,memory will be allocated.
I dont have much knowledge in this, So any explanations are welcome. Also let me know if any other better method to go.
It's not bad practice to use large texts or blobs even if it's not going to be used frequently, however try to use the smallest data type that suits your needs.
TEXT requires N characters + 2 bytes
MEDIUMTEXT requires N characters + 3 bytes
LONGTEXT requires N characters + 4 bytes
See: https://dev.mysql.com/doc/refman/5.7/en/storage-requirements.html
Additionally, if you allow them to be NULL (and assuming you are using InnoDB engine with COMPACT row format), it will only use 1 bit per column per row). So, if you have 2 NULLs, it will still use 1 byte.
Space Required for NULLs = CEILING(N/8) bytes where N is the number of NULL columns in a row.
More on: https://dev.mysql.com/doc/refman/5.7/en/innodb-physical-record.html
On the other hand, having that many columns might not be ideal. Try restructuring your table into several tables.
I think you need to split that information in three tables. One contains general info about entry, one contains fields list and other holds relation between first and second table.
[Product]
ID | name | model | price
[Fields]
ID | field_name | field_key | is_mandatory
[Field_to_product]
field_id | product_id | value
And in Field_to_product you hold only these values, that product has.
On update delete all entries for that product from Field_to_product and rewrite it's values.
If the length of data on the column used less than 65,535 characters, you should consider using varchar, rather than text type variant.
blob, text, varchar, and varbinary data type are pointer type.
They only store 1-2 byte pointer header and for the data part will acquire space in dynamic manner. they alocate space as the data fill in the column. the N part when creating type such as varchar(N) is for validation purpose.
Blob and binary differ from text and varchar in the way database engine use index for sorting and use matching algorithm to compare data.
Where text based will be stored and compared using collation of character set. The way the database engine store the character in physical is defined by character set. Some character set like Japanese or Chinese, require double byte to store, while Latin character use single digit. And so on.
While Blob and binary data is saved as is and no reference to any character set.
Aside from data type, you should consider normalize the table.
https://en.wikipedia.org/wiki/Database_normalization
A table with 100 columns will hold performance down as the data row grow.
Make searching, inserting and updating the table take more time as it grow.
You can try sql utility syntax from sql query console to show your table status
show table status from your_table_name;
The actual size of table is not only defined by datatype, but also come from index(s), key(s). Index can define on set of column(s), so multiple index can be created on a single table.
The space requirement will also grew exponential if using a text data type column with full text index enabled on that column.
Here is something that troubles me as I am creating a database table columns. For each of these there is a data type which has it's length. For e.g say one of the tables is a file path, and I assume this file path to be not longer than 100 in length at max, obviously i specify this as
filepath Varchar(100)
However, this still takes the same amount of memory space as say varchar(255) which is 1 byte. Given this, what is the benefit of me specifying the length as 100. Taking an outlier example, if my filepath exceeds varchar(100), does the database reject/trim down the filepath value to fit it to 100? Or does it allow it to exceed beyond 100 since the allotted memory space is still around 1 byte?
Essentially the above explanation frames my question as should one try and be very specific about the expected maximum length for a table column? Or just play it safe and specify the upper limit of the expected length of the table column depending on the memory requirement ?
Thanks much !
Parijat
MySQL will auto-truncate the value down to 100 characters. The number in the brackets for text/char fields is the MAXIMUM length. Note that this is a CHARACTER limit. If you've got a multibyte collation on that field, you can store more than 100 bytes in the field, but only 100 characters worth of text.
This is different than saying int(10), where the bracketed number is for display purposes only. An int is an int internally and takes up 16bits, regardless of how many digits you allow with the (#), but you'll never SEE more than those # digits.
very specific about the expected maximum length for a table column? Or just play it safe
If one would make a table containing addresses, you undoubtedly know that there will be some kind of limit to the length of the address. It would be useless to allow longer fields in the database.
You should play it safe, and be very careful.
I am building a table that will receive different values in a field, think of a log table that the "value" field can be a number, a tiny string or a big text etc.
So I was wonderig if I should create that "value" field as Text or create two fields, one for small inputs, like date, numbers and some string and another one only for the Texts inputs.
so, my question is this:
Should this "value" field be a Varchar along with some other "value2" as Text or create one field Text that the mysql will manage this corretcly?
I am afraid that creating only one Text field can be a bad thing for performance.
EDIT: the number, datetime etc are going to be cast as string before insertion, thats not the point
Thanks,
Joe
Do you know how large the largest input will be? If you impose a limit, or know how large the maximum input will be, then you could use varchar (which caps at 255 characters in versions < 5.0.3, and 65,535 in versions >= 5.0.3). Otherwise, you're probably better off with Text, since it holds significantly more (65,535*2^16-1).
As an alternative, if users are creating things that already have tables (such as adding events to a calendar), you could just put an "is_approved" column on the table and only display approved ones, or search through everything to check for duplicates.
http://dev.mysql.com/doc/refman/5.0/en/string-type-overview.html
If there is a limit to the length of that the data stored use varchar() (as MySQL 5.0.3 varchar max length can be up to 65,535)
If there is no concrete limit then use a 'text' field type.
The varchar field can handle the different input's that you are mentioning but as a string, not as an integer or datetime.
So I was creating a table for comments, and I was wondering. What would be a good type for comment details? I put longtext. Well then, why would people need varchar if longtext can handle it? Also, which type would I want for usernames?
What is the purpose of "primary" for index? What is the purpose of index?
Update:
Let's say a comment was actually a review.
It is true that TEXT can handle any input you'd place in VARCHAR or CHAR field. In fact TEXT could handle and data you might want to put in DECIMAL, INT, or almost any other type as well. Following this logic we might as well make every column a TEXT type.
But this would be a mistake. Why? Because using the appropriate column type for the expected input allows the database to better optimize queries, uses less disk space and makes the data model easier to understand and maintain.
In regards to the questions: a username column should use VARCHAR(20), since you would want and expect that most usernames are going to short, usually no more than 10 - 20 characters long. For a review column (like a movie review or book review) a TEXT type would be appropriate as reviews can span a single paragraph to several pages.
In regards to indexes, try this link:
http://20bits.com/articles/interview-questions-database-indexes/
That depends on what a "comment" is in your system. Typically VARCHAR is pretty standard for both comments and usernames. This limits you to about 255 characters, which is generally pretty acceptable. If you need more characters in your comments, you can bump it up to a text, which gives you a little over 65k chars.
For more information, see the String Types Reference.
TEXT NOT NULL. That gives sufficient room, has a 2 byte overhead, and generally presents no problems.
Regarding TEXT
On comparisons, TEXT is space extended
to fit the compared object, exactly
like CHAR and VARCHAR.
For indexes on BLOB and TEXT columns,
you must specify an index prefix
length. For CHAR and VARCHAR, a prefix
length is optional. See Section 7.4.2,
“Column Indexes”.
BLOB and TEXT columns cannot have
DEFAULT values.
If you use the BINARY attribute with a
TEXT data type, the column is assigned
the binary collation of the column
character set.
Regarding VARCHAR:
Values in VARCHAR columns are
variable-length strings. The length
can be specified as a value from 0 to
255 before MySQL 5.0.3, and 0 to
65,535 in 5.0.3 and later versions.
The effective maximum length of a
VARCHAR in MySQL 5.0.3 and later is
subject to the maximum row size
(65,535 bytes, which is shared among
all columns) and the character set
used.
More at: http://dev.mysql.com/doc/refman/5.0/en/blob.html
Have a look at this web page, it lists all the MySQL field types and describes what they are and how they're different from each other.