アカウント名:
パスワード:
たとえばSJISや独自コード(!)にすれば格納できるでしょうけど、 じゃあその場合、Queryが普通にやれなくなる等の別の問題が生じるわけで。
「無茶な要求」をされるのが一番こまるんだよね、計算機世界って。
# まあ立場によりけりなんだけど # 今の私の立場は無茶な要求大歓迎だなあ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
ウェブの外でも (スコア:1)
英文字では、細長く見せたり、太く見せたり、というフォントが数多くありますけど、日本語では殆ど、プロポーショナルフォントでも、正方形の1マスに1文字というスタイルが原則に成っている
Re:ウェブの外でも (スコア:1)
文字コードEUC-JPで作成したDBに半角カナを格納しようとしてはまったことがあります…(フィールドサイズがたりなくて)
Re:ウェブの外でも (スコア:1)
ハマったという瞬間的(^^;なものならまだ良いです。
どっかの客が、「画面で見たままのバイト数(なんじゃそりゃ?)でDBにも格納できないと困る」
などと言いだしてくれて、頭かかえたことがあります。無理だっちゅーの。
既に作っちゃったDBの定義を今更変えられない、とかいう事情だと言っていましたが、
本末転倒な理由だなあ。
いや、小細工を多数すれば、そりゃどうにでもなるでしょう。
でも小細工を糊塗するために小細工の連鎖をするという悪循環が
待っているわけで、勘弁してほしいものです。
たとえばSJISや独自コード(!)にすれば格納できるでしょうけど、
じゃあその場合、Queryが普通にやれなくなる等の別の問題が生じるわけで。
オフトピ:
「無茶な要求」をされるのが一番こまるんだよね、計算機世界って。
Re:ウェブの外でも (スコア:1)
昨今のまともな商用 RDB なら encoding は選択できるはずですし。 「無茶な要求」によるでしょう。
「資金的・時間的に無茶な要求」は願い下げですが しかるべき対価を提示されているのであれば、それこそ「無茶な要求」==「メシのタネ」というものではないかと愚考する次第です。
# まあ立場によりけりなんだけど
# 今の私の立場は無茶な要求大歓迎だなあ
Re:ウェブの外でも (スコア:1)
SolarisのOracleは初めてだったので結構どきどきしたけどなんとかなってよかったよかった(というかインストーラはLinuxとおんなじですね)
Re:ウェブの外でも (スコア:1)
別のかたのコメントがありましたが、Instance単位なんでしたっけ(なんか忘却してるぞ俺)。
テーブル単位やカラム単位じゃなくて。
となると、やれるかどうかは一概に言えないですね。
>「資金的・時間的に無茶な要求」は願い下げですがしかるべき対価を提示されているのであれば、それこそ「無茶な要求」==「
>メシのタネ」というものではないかと愚考する次第です。
いや、逆に資金や時間が問題なのならば「それを寄越せ」で話が済む(あるいは明示的に決裂する(^^;)のですが、
厄介なのは本質的にやれないことを要求されるとき。
まぁそれも明示的に決裂すればいいといえばそれまでなんですが、
時間の問題だろうが本質的問題だろうが、客にゴネられるときはゴネられる(ぷ)ので、
後者のほうが色々しんどいです。
たとえば、「web」アプリで、webブラウザが普通実装してなかったり、そもそもhtmlとかhttpでは
どうしようもないとか、そういうような機能を設けることを要求されるとか。
どういうわけかそういう無理な要求に限って、客は何度もぶり返すんだよな。無茶だって言ってるのにさー…
それとも、webアプリで出来ないならwebを捨ててクライアントをゼロから作る
という話にしてしまえば(時間と金があれば)可能だ、ということでしょうか?
まぁそれ言い出せばその通りですが、WindowsだのUnixだのInternet通信プロトコルだの(の代替物)
までをも 1つの案件のために「作る」ってのは、無茶苦茶なのであって。
あるいは文字コード体系を作るとか。それを格納してすんなりQueryを通せるDBサーバーも作るとか…
あと、論理的に自己矛盾を起こしてる要求仕様、てのもありますね。
要求仕様書自体にデバッグ機能がついていたら(^^;最初からそんな仕様は無理なのが判るんでしょうけど、
こっちに持ってきた時点で初めて問題が発覚する(プログラム自体は矛盾を見逃してくれませんので)みたいなことが、しばしば…
余談:
あと、本質的無茶ではないものの「スパゲティな」仕様、ってのも嫌なものです。