Subject | Re: [firebird-support] What are the trade-offs of CHAR vs. VARCHAR? |
---|---|
Author | Richard Damon |
Post date | 2019-11-14T02:40:36Z |
On 11/13/19 9:51 AM, blackfalconsoftware@... [firebird-support]
wrote:
as a fixed width, so data is padded with blanks to reach that width, and
then the blanks are removed on retrieval. Because of this, a CHAR field
can not store a value with trailing blanks. On the other hand, since
VARCHAR doesn't need to pad the field, it doesn't need to trim trailing
blanks, so the field CAN store data with trailing blanks.
Firebird might not implement this distinction since it doesn't need to
pad CHAR fields.
--
Richard Damon
wrote:
>By the SQL standard, there are some noticeable effects. CHAR is defined
> Thank you Anne, for your succinct comments regarding the differences
> between the efficiencies of a CHAR and VARCHAR field definitions.
>
> Human observation cannot actually elicit any observable effects
> between the two.
>
> However, internally, the CHAR field definition is more efficient as
> the database does not have to perform any field size calculations at
> the moment that data is being updated to a VARCHAR field. Again, this
> is not noticeable to a user unless the data that is being updated into
> a VARCHAR field is quite large.
>
> Steve Naidamast
> Sr. Software Engineer
as a fixed width, so data is padded with blanks to reach that width, and
then the blanks are removed on retrieval. Because of this, a CHAR field
can not store a value with trailing blanks. On the other hand, since
VARCHAR doesn't need to pad the field, it doesn't need to trim trailing
blanks, so the field CAN store data with trailing blanks.
Firebird might not implement this distinction since it doesn't need to
pad CHAR fields.
--
Richard Damon