The Way to Nowhere

あるITエンジニアの雑文。

2014年04月

DBのキャラクタセット違いでSJISからUTF8への移行 - Oracle -

最近はOracleのデータベースもUTF8で構築することが当たり前な感じになっていますが、何年も使っているレガシーのシステムだとやっぱりSJISとかだったりすると思います。

そんなSJISとかのデータベースから新しく構築するUTF8のデータベースにデータを持ってくる時には、文字コードの変換とかはだいたいミドルなところがやってくれるので、気にしなければいけないのはマルチバイト文字に必要なバイト数が増える事を考慮してデータを格納する領域を確保するってことくらいかな、と普通は思うわけです。

データの中身に関する事はその程度の事でさほど問題はないのだろうけど、古いシステムの中にはテーブルとかのDBオブジェクトの名前にもマルチバイト文字が使われていたりする。
テーブルとかDBオブジェクトを作る際には、その名前に漢字とかひらがなとかのいわゆるマルチバイト文字は使わずに、半角英数字と若干の記号のみを使うべきとは昔から言われているよね、というのが私の印象ではあるのですが、実際のところ物理名にもマルチバイト文字を使っているレガシーシステムはまあまああります。
そのようなシステムからDBリンクで接続してデータを持ってこようとした時に問題が起きる可能性がある。

OracleはSQLの構文としてDBオブジェクト名は30バイト以内という制限がある。
SJISだと漢字やカナなど2バイトで済むのでテーブル名などにマルチバイト文字を使った場合15文字まで使えるということになる。
しかし、UTF8では漢字とかカナは3バイトが必要になるので、SJISの旧システムと同じ名前ではDBオブジェクトが作れない、ということになってしまう。
新しく構築するんだから物理名にマルチバイト文字なんか使わなければよいのですが、データを移行する為に新しいUTF8のDBからDBリンク経由でSJISのDBに接続してデータを持ってこようとした時に、UTF8のDB上でアットマークをつけてDBリンク先のSJISのDBのテーブルにアクセスしようとすると、UTF8としての30バイトの制限に引っ掛かってSQLが構文エラーになってしまいます。
「DBリンク先の文字コードがSJISだからUTF8としては長い名前だけどもOK」みたいな気は使ってはくれないわけです。

対応策としてはテーブル名やカラム名、その他DBオブジェクト名のバイト数がUTF8にしても30バイト以下になるように、SJIS側のDBにビューとかを作るって事になると思います。
内容や元々の名前がわかるように短縮した名前をつけるとかって、対象のボリュームにもよりますが、結構地味にダルい話だと思います。
まあ、パフォーマンスとか考えて許容されるのであれば、DBリンクを使わないでファイル渡しする、とかでもよいのかもしれませんけどね。

個人的には最近こんなのばっかりで慣れてしまった。
物理名に漢字とかひらがなで日本語を使われていると、ブラックボックスなシステムの中を調査する上ではとっつきやすいのですけどね。

やっぱりそういうDBの物理名にも漢字とか使っているシステムって、COBOLの影響なんのかな?さらにもっと昔にはCOBOLとかでシステム構築していた人たちが90年代のオープン化の流れで技術領域をシフトさせつつ作ったのかな?とかとか思ってしまいます。すごい偏見だけど。


経費で落とせるとか、落とせないとか

別にあえてこういう本を読もうと探したわけではないんだけど、ちょうど独立して経費処理の自分なりのルールを確立しようと色々と考えていたところに、なぜかAmazonのレコメンドに出てきたので勢いでポチッとしてしまった。
この手の本がたくさんある中で、なぜあえてこの2冊かとか、特に意味はありません。なんとなくで。

経費で落ちるレシート・落ちないレシート
梅田 泰宏
日本実業出版社
2013-12-21






それぞれ、『経費で落ちるレシート・落ちないレシート』は税理士、『あらゆる領収書は経費で落とせる』は元国税調査官と、それぞれの立場や経験に基づいて事業における経費処理の考え方を説いていて、タイトルから想像できる通り個人事業主とか中小企業向けの節税対策本。
元国税調査官の方はタイトルが明らかに釣りですが、どちらも基本的な考え方は概ね同じで、要するに「事業に関係のある支払であることが説明できれば経費にできる。」という当たり前のことであったりする。
で、それぞれに具体的な事例を提示しながら個々のケースを説明しているという感じ。

各論では正反対の事を言っている所もありますが、福利厚生費の扱いとか。
なので、実際のところはやはり自分の実態を踏まえた個々のケースについて税理士に相談するのがよいのだと思います。

それから『あらゆる領収書は~』の方は初版が2011年ということで若干情報が古い所があるな、という事があるのと、「税金払うくらいなら経費として使っちまえ!」的な発想が散見されるのが、なんだかなぁ、と思ったりもした。

一応、この数ヶ月で私が自分自身の経費処理をやりながら色々と見聞き考えてきた事の答え合わせになった感じでもあります。
合計金額と但し書きだけの領収書って、むしろ詳細を隠す効果があって、ある意味で「経費処理しやすい」とか思っていたんですが、税務署的にはそういう領収書よりも、いわゆるレシートの方が何を買ったか明細がわかってむしろいい、とかいう話が確認できたりとか。
サラリーマンとして経費精算している時は「常識」と思っていた事が、税務的には実はそうでもないということがいろいろあるとか。もちろん、税務署的にOKでも、会社の社内規程的にNGなケースも多々あるとは思いますが。

こんな感じで法人税とか所得税とかグレーゾーンがいっぱいな状況を見ると、より明確で公正に課税・徴収できそうな消費税とかにシフトさせた方がよいんじゃないかな、とか思ったりする。ちょうどこの4月から消費税の税率アップしたところで、それはそれとして別の問題はあるとは思うけど。
あえてグレーゾーンがそれなりにある事で、官僚の裁量でどうにでもできる部分を確保しているという面もあるのかな、という気もするけど。

だからなのか、『経費で落ちるレシート~』の方では細かいテクニック以前に税務署に対する「心象」を悪くしないようにしよう、という主旨の話だとか、税務官によっても対応が違うという話とかもあったりする。

ともかく、一応の指針とか慣例も含めてのルールはあるわけなので、それを自分自身の実態に即したルールに落としこんでルーチン化していくだけの事だと思います。
ちゃんとやらないと相当な金額にハネてくるからやりますけど、そもそも本当はこんな事には時間かけたくないですからね。
記事検索
プロフィール

ntakano75

フリーランスでシステムエンジニアをやっておりました。

Twitter
AdSense
Amazon
  • ライブドアブログ