Hi,
2006/1/17, Karl Pielorz <[EMAIL PROTECTED]>:
>
> Hi All,
> 1. Fixed length CHAR fields are quicker to update than VARCHAR fields
> (because the field size is constant)
There is no advantage if not all your field in your table are fixed
size. as soon as you add a text/blob column, you loose t
thanks.
- philip
On May 28, 2005, at 10:08 PM, Paul DuBois wrote:
http://dev.mysql.com/doc/mysql/en/silent-column-changes.html
At 21:29 -0500 5/28/05, Philip George wrote:
when i create a table with:
CREATE TABLE person (
id char(36) NOT NULL PRIMARY KEY,
firstname varchar(50)
http://dev.mysql.com/doc/mysql/en/silent-column-changes.html
At 21:29 -0500 5/28/05, Philip George wrote:
when i create a table with:
CREATE TABLE person (
id char(36) NOT NULL PRIMARY KEY,
firstname varchar(50) DEFAULT NULL,
lastname varchar(50) DEFAULT NULL
);
...and then use d
Gary,
- Alkuperäinen viesti -
Lähettäjä: "Gary Richardson" <[EMAIL PROTECTED]>
Vastaanottaja: "Heikki Tuuri" <[EMAIL PROTECTED]>
Kopio: <[EMAIL PROTECTED]>
Lähetetty: Thursday, October 21, 2004 4:49 AM
Aihe: Re: Char to Varchar on Innodb
> I
I'm not too worried about it myself, but I can see how less magic on a
database server is better.
Without actually trying it, if I mix CHAR's and VARCHAR's in a table,
does SHOW CREATE TABLE reflect the internal conversion?
If you wanted to reduce fragmentation in an Innodb table, wouldn't all
th
Hello,
> those 'silent column specification changes' affect all table types. That
> feature has caused lots of user questions over years. It is in the TODO to
> remove that feature from MySQL, because it is not standards compliant. In
> InnoDB, a reason to use a CHAR column in some cases is to red
Gary,
those 'silent column specification changes' affect all table types. That
feature has caused lots of user questions over years. It is in the TODO to
remove that feature from MySQL, because it is not standards compliant. In
InnoDB, a reason to use a CHAR column in some cases is to reduce
fr
At 13:56 22.03.2004, Martijn Tonies wrote:
> > I have some problmes with MySQL. We have some CHAR columns, which after
> > CREATE or ALTER TABLE
> >
> > ALTER TABLE `traffic_stat` CHANGE `media_file_class_id`
> > `media_file_class_id` CHAR(32) NOT NULL
> >
> > will be VARCHAR. Is this an MySQL bu
thx.
At 13:43 22.03.2004, [EMAIL PROTECTED] wrote:
Rafal Kedziorski <[EMAIL PROTECTED]> wrote on 22/03/2004 12:36:33:
> hi,
>
> I have some problmes with MySQL. We have some CHAR columns, which after
> CREATE or ALTER TABLE
>
> ALTER TABLE `traffic_stat` CHANGE `media_file_class_id`
> `med
> > I have some problmes with MySQL. We have some CHAR columns, which after
> > CREATE or ALTER TABLE
> >
> > ALTER TABLE `traffic_stat` CHANGE `media_file_class_id`
> > `media_file_class_id` CHAR(32) NOT NULL
> >
> > will be VARCHAR. Is this an MySQL bug? We are using MySQL 4.0.18.
>
> http://ww
Rafal Kedziorski <[EMAIL PROTECTED]> wrote on 22/03/2004 12:36:33:
> hi,
>
> I have some problmes with MySQL. We have some CHAR columns, which after
> CREATE or ALTER TABLE
>
> ALTER TABLE `traffic_stat` CHANGE `media_file_class_id`
> `media_file_class_id` CHAR(32) NOT NULL
>
> will be VAR
In the last episode (Jan 21), Steve Edberg said:
> At 12:17 PM -0600 1/21/04, Joseph S Brunzelle wrote:
> > I'm try to write a query that will return the number of times a
> > specified character appears in a string (I want known how many
> > times the character "M" appears), but I cannot seem to f
At 12:17 PM -0600 1/21/04, Joseph S Brunzelle wrote:
I'm try to write a query that will return the number of times a specified
character appears in a string (I want known how many times the character "M"
appears), but I cannot seem to figure out how to do that. The select
statement is the followin
Namor,
As Paul said we can make a guess, but more information would be
necessary. I would first try looking at this page:
http://www.mysql.com/doc/en/Silent_column_changes.html
In short, the following could be the cause as to why your columns are
being changed:
* If any column
At 9:40 -0700 6/22/03, Namor Taror wrote:
I just created a table with some char columns (I am using Control
Center). Every time I save the table (during the design process) my
char fields are reset to varchar. Does anybody know why?
We can make a guess.
But you need to show the table structure y
>From: christophe barbe <[EMAIL PROTECTED]>
>
>Is it then correct that VARCHAR(255) and TINYTEXT are strictly
>equivalent?
I believe they work almost the same, but there may be performance implications because
they are stored differently.
My understanding is that TINYTEXT is simply a sort of BL
The only time you will gain a speed advantage is if you have no variable
>>length fields in your record (varchar, text, etc.). You may notice that
>>all your CHAR fields are changed to VARCHAR as soon as a variable length
>>field type is added. CHAR is less efficient from a space storage point
Is it then correct that VARCHAR(255) and TINYTEXT are strictly
equivalent?
If no, where is the difference?
Thanks,
Christophe
NOTE: I understand now the "sql,query" stuff. Strange idea.
--
Christophe Barbé <[EMAIL PROTECTED]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B
Thanks, your comments are very helpful, especially the info that if I
have already a not-fixed field in a table the performance cost of adding
a VARCHAR (instead of a CHAR) is 0.
NOTE for the Mailing-list Admins: There is a 1 hour (at least) between
the post and the availability of the mail in th
VARCHAR basically sets a maximum length for the field and only stores
the data that is entered into it, thus saving on space. The CHAR type
has a fixed length, so if you set CHAR(100), 100 character worth of
space will be used regardless of what the contents are.
The only time you will gain a s
Christophe Barbe wrote:
>I am looking about experienced pros and cons on the use of VARCHAR. My
>understanding is that, except if you know that each time the text will
>have the same length, VARCHAR is better. This seems a bit too perfect to
>be true.
>
You do not have to use all the chars ... if
Christophe Barbe wrote:
>Le mar 08/10/2002 à 11:35, Michael T. Babcock a écrit :
>
>
>>Before I forget: SQL, QUERY ... going write a filter for these some day ...
>>
>>
>
>I don't get what you mean by "SQL, QUERY ...".
>I know how to write a SQL QUERY.
>
>
I was making sure I'd get past t
Le mar 08/10/2002 à 11:35, Michael T. Babcock a écrit :
> Before I forget: SQL, QUERY ... going write a filter for these some day ...
I don't get what you mean by "SQL, QUERY ...".
I know how to write a SQL QUERY.
I am looking about experienced pros and cons on the use of VARCHAR. My
understandi
Before I forget: SQL, QUERY ... going write a filter for these some day ...
christophe barbe wrote:
>What are the disadvantages of using VARCHAR instead of CHAR.
>Is it going to be considerably slower?
>
>
It really depends on your table, but if you find it slower, break down
into multiple t
At 10:19 PM 7/9/2002, you wrote:
>I am using MySql with InnoDB and have just discovered
>that tables created using char types show up as
>varchars when I type, describe tableName. Previously,
>I was using MyIsam tables and did not see char types
>being changed to varchars so I am a bit puzzled.
>
In the last episode (Jul 09), Michael Ivanyo said:
> I am using MySql with InnoDB and have just discovered that tables
> created using char types show up as varchars when I type, describe
> tableName. Previously, I was using MyIsam tables and did not see
> char types being changed to varchars so
At 15:18 10/4/2002 +0200, [EMAIL PROTECTED] wrote:
Hi!
>Thank you for your help, but I know that I must compile kernel (mysqld)
>with this char set. But, this I can do with Unix (or Linux, etc.). What
>can I do with kernel for Win32? Is any mysqld with char set win1250
>compiled in?
The 4.01 W
also, note that char is changed to varchar in some cases, such as when there
is a text field in the table.
-Original Message-
From: Jon Haworth [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 10, 2002 10:40 AM
To: 'Luke van Blerk'; [EMAIL PROTECTED]
Subject: RE: Char vs Var
It depends on who you talk to and what you want to do. varchar will use
less disk space, but char is faster to access (except for InnoDB tables,
where varchar has the advantage). The benefit is using char is that the
rows have a fixed length so MySQL knows exactly where each row starts and
can
Luke,
Wednesday, April 10, 2002, 4:18:48 PM, you wrote:
LvB> When is it appropriate to use Char instead of Varchar and vice versa?
CHAR column type has fixed length, VARCHAR is variable-length string.
CHAR column type appropriate to use when you have data with the same
length. Don't forget that
Hi Luke,
> When is it appropriate to use Char instead of Varchar and vice versa?
Use CHAR for when you know in advance how many characters are going to be in
that field. A good example is for MD5 hashes: they are always 32 characters
long, so you can use CHAR(32).
Use VARCHAR for when you don't
[EMAIL PROTECTED] wrote:
>
> When is it appropriate to use Char instead of Varchar and vice versa?
Use char when you expect the length of the field to always be the same.
Use varchar when you're not sure.
Basically, when you're using varchar you're assigning a limit to the size
of the string th
(where is win1250 compiled in)?
Thank you
Pavel Zaklasnik
PS: Apologize me for my bad english.
-Original Message-
From: Victoria Reznichenko [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 10, 2002 1:50 PM
To: [EMAIL PROTECTED]
Subject: Re: Char set Win1250
I have simple question.I have
I have simple question.I have installed on my computer WinNT 4.0, Apache 1.3.14,
PHP4 (4.0.4pl1), MySQL MAX 4.0.1. There's problem with char set win1250. I don't know
how can I link this char
PZ> set. Script with this row $spojeni = MySQL_Connect("localhost"); sends an error
Warning: MySQL Co
Hello.
On Mon, Apr 08, 2002 at 11:24:56AM -0400, [EMAIL PROTECTED] wrote:
[...]
> still...I wonder why I got a 'Query OK, 1 row affected' message
[...]
> > insert into table (key, field) values (1, 'test'||CHAR(59)||' string');
> >
> > it seems to work initially...(Query OK, 1 row affected (
Hi.
Have a look at http://www.mysql.com/doc/E/x/Extensions_to_ANSI.html
(rather at the end). || has a different meaning in MySQL started
without explicit --ansi. Also see
http://www.mysql.com/doc/A/N/ANSI_mode.html.
Bye,
Benjamin.
On Mon, Apr 08, 2002 at 11:08:15AM -0400, [EMAIL PROTEC
nevermind...instead of using '||' to concat the fields i needed to use the CONCAT()
function. So the syntax should have been:
insert into table (key, field) values (1, CONCAT('test',CHAR(59), ' string'));
still...I wonder why I got a 'Query OK, 1 row affected' message
-Don
>
MySQL automagically changes all char columns to varchar if there is one or
more variable-length columns' present. The TEXT column in your first
example is causing ALL char() columns to be converted to varchar(). In
your second example, since there are NO variable-length columns, the
char() colum
Hi,
This behaviour is normal. As long as you have varchar, blob or text field,
the row format used is "dynamic", and so char are converted to varchar type.
If you want to convert you all your varchar to char, just execute ALTER
TABLE your_table ROW_FORMAT=fixed
Take a look at :
http://www.mysq
On 04 Aug 2001 22:57:39 +0300, Khaled I. Hammouda wrote:
> Greetings ALL:
>
> I am developing a database application using mySQL & php for a client
> that requires data entry (at least) to be in Arabic.
>
> I am know that mySQL supports charsets, but it is not clear if it
> supports charsets tha
On Fri, 1 Jun 2001, Toth Dalibor wrote:
> I really need to know this: I have a column defined as char(2), default
> 'no', not null.
> When I create new entry into the table, I skip entering value into mentioned
> column
> because I expect to be filled with the default value, that is 'no'. Bu
Hi,
Char columns are used with fixed-length type table, whereas varchar are used
with dynamic table. If you have varchar columns in your table, all char
columns will be convert to varchar column (you can't have a fixed-length
table if your table contain varchar, blob or text field).
Here are
Alec Solway wrote:
>
> Hi,
>
> In various create table statements char columns are converted to varchar..
> I was wondering why this was happening. Here's an example:
>
> CREATE TABLE realtors(name VARCHAR(255) not null, address VARCHAR(255) not
> null, city VARCHAR(255) not null, state CHAR(2)
http://www.mysql.com/doc/S/i/Silent_column_changes.html
second item, quoted here:
If any column in a table has a variable length, the entire row is
variable-length as a result. Therefore, if a table contains any
variable-length columns (VARCHAR, TEXT, or BLOB), all CHAR columns longer
than three
Anthony Cooke wrote:
> If table a is person_entry and table b is person_account and you will be
> searching according to an exact comparison then why use a CHAR field for the
> ID instead of a numerical equivalent?
>
> Why not normalize so that each record in "entries" would have one Unique
> aut
45 matches
Mail list logo
