ホームページ  >  記事  >  データベース  >  データ型を変更した後でも列「incoming_Cid」のデータが切り捨てられるのはなぜですか?

データ型を変更した後でも列「incoming_Cid」のデータが切り捨てられるのはなぜですか?

DDD
DDDオリジナル
2024-11-02 07:59:02269ブラウズ

Why Is My Data Truncated for Column 'incoming_Cid' Even After Modifying the Data Type?

データの切り捨て: 「列のデータが切り捨てられる」という難問を掘り下げる

データベース管理の領域では、データの切り捨ては、割り当てられたデータが割り当てられたときに発生します。特定のデータ要素を保存するためのスペースが、その全体を収容するには不十分です。これにより、データの切り捨てが発生し、損失や破損が発生する可能性があります。

データの切り捨ての 1 つの例には、MySQL 列のデータ型の変更が含まれます。 Twilio コール ID (34 文字の文字列) を格納するための列のデータ型が変更されるシナリオを考えてみましょう。列のデータを手動で更新しようとすると、エラー メッセージが表示され続けます:

| Level ||| Code | Message
| Warning | 1265 | Data truncated for column 'incoming_Cid' at row 1

このエラーは、列のデータ型を適切に変更したにもかかわらず発生します。

問題の根本: 長さの不一致

この場合の根本的な問題は、incoming_Cid 列の文字の長さが正しくないことにあります。データ型は CHAR(34) に変更されている可能性がありますが、実際の列の長さは CHAR(1) のままです。この不一致により、34 文字のコール ID を保存しようとするとデータが切り捨てられます。

切り捨ての問題を解決する

この問題を修正し、適切なデータ ストレージを確保するには、次の手順に従ってください。プロシージャ:

  1. 列の長さの確認: コマンドを使用して、incoming_Cid 列の文字長が現在 1 であることを確認します:

    SHOW COLUMNS FROM calls LIKE 'incoming_Cid';
  2. 列の長さを変更します: 列の長さを 34 文字に拡張するには、次のコマンドを実行します:

    ALTER TABLE calls CHANGE incoming_Cid incoming_Cid CHAR(34);
  3. 変更を確認します: SHOW COLUMNS コマンドを再実行し、更新された文字の長さを観察して変更を確認します。

サンドボックスの例

このソリューションの対話型デモが利用可能ですSQLFiddle: https://www.sqlfiddle.com/#!9/4a752/1.

以上がデータ型を変更した後でも列「incoming_Cid」のデータが切り捨てられるのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。