X

フィールド名は日本語にするか、英語にするか

0108NAME IS NULL
垢版 |
2008/09/21(日) 15:44:13ID:???
ヘボン式は論外。訓令式も半端。日本式で決まり。
0109NAME IS NULL
垢版 |
2008/10/09(木) 18:12:14ID:???
>>105
アジア訛りで充分だろ
東洋人丸出しの顔で白人気取りに見えんのも逆に痛いし
0111NAME IS NULL
垢版 |
2009/01/03(土) 00:15:19ID:3emwlJX+
フィールド名やテーブル名に２バイト文字(日本語)を使うか、半角アルファベットを
使うかは、難しい問題だけど、半角英数だけにするなら、アルファベットは大文字に統一もしくは
小文字に統一する、２バイト文字使うなら、半角アルファベットは使わないは守らないといけないね。
半角アルファベットで、大文字・小文字を区別して混ぜて使うのは×

Oracleの場合
"ABc"とか"あaあ"とかはやめてほしい。
ちなみに、おれの場合は、Oracleなら半角アルファベット、SQLServerやアクセスなら、全角日本語
かな
0112NAME IS NULL
垢版 |
2009/01/10(土) 10:05:45ID:???
先ずはフィールド定義時にコメントをちゃんと入れて下さい＞＜
0113NAME IS NULL
垢版 |
2009/01/21(水) 04:04:36ID:???
nameだと思ったらnamaeだったりすると、もうやる気なくすわ
0114NAME IS NULL
垢版 |
2009/02/05(木) 01:14:23ID:???
ちとスレ違いではあるが、誰か知ってたら教えて欲しい。
SQLServer2005で、テーブル名、フィールド名ともすべて半角アルファベットで
定義されてるDBがあって、そのなかのいくつかのテーブルをJOINして
ビューを作ってるんだけど、SQL文の中で、テーブル名 as ほにゃらら　みたいに
別名を使うとき、別名に全角文字を使うのと、半角アルファベットを使うのとで、
パフォーマンスが変わる。全角の別名を使うと、パフォーマンスがガタ落ちする。
これってなんだろ？
0115NAME IS NULL
垢版 |
2009/02/19(木) 13:22:28ID:???
全角の別名を使ったから
0120NAME IS NULL
垢版 |
2009/02/20(金) 19:19:01ID:???
全角の別名を使ったから
0121NAME IS NULL
垢版 |
2009/02/21(土) 10:59:37ID:???
つまり SQLServer2005 が出来損ないということか？
0122NAME IS NULL
垢版 |
2009/03/14(土) 12:50:24ID:+CMRFd3I
SQLServerは最強だお
製品C='XXX'
製品ｃ='XXX'
どちらでも問題ないよ
0124NAME IS NULL
垢版 |
2009/03/17(火) 06:45:15ID:t882uXmU
>>36と似てるけど、テーブル名に「ー」を使ったテーブルが読めないな。
oracle10・ole接続で表またはビューがありませんとなる。
ネイティブ接続、odbc接続だと読める。
oleドライバのバグだろうけど。
0126NAME IS NULL
垢版 |
2009/04/06(月) 19:27:09ID:Vb3wrAJR
かっこつけて英語だとﾜｺﾜｶﾁなんで日本語。

病院用は英語。（DICOMとのからみで統一せんとﾜｺﾜｶﾁ）
0127NAME IS NULL
垢版 |
2009/04/24(金) 17:25:10ID:???
↑みたいな悩みは日本人だけなんだろーか？
中東の人とかはどんなSQL書いてんだろ？
) 'obiem' ELBAT ETAERC
,regetni 'di'
:
:
的な？
0128NAME IS NULL
垢版 |
2009/04/24(金) 19:40:38ID:???
英語に拒否反応を起こしてるのは日本人とフランス人だけ
0129NAME IS NULL
垢版 |
2009/04/26(日) 23:43:25ID:???
プロジェクトに外人も参加するなら英語にしといたほうが親切かもね。
0130NAME IS NULL
垢版 |
2009/06/13(土) 01:09:35ID:???
中国人に聞いたらピンインで打つ奴も多いそうだけどｗ
0131NAME IS NULL
垢版 |
2009/10/22(木) 02:03:00ID:???
ってかさ、海外で利用するシステムなら、DBは半角英数字表記が一番だよねぇ？
現地の端末に日本語FEPが入ってるとは思えんので、何かあった時に、現地人が
SQL書けないじゃないか。
0132NAME IS NULL
垢版 |
2009/10/22(木) 09:04:39ID:???
なんで海外利用が前提になってるんだ
0133NAME IS NULL
垢版 |
2009/12/16(水) 01:32:34ID:6MmbHqTl
未だに、大手企業の課長クラスの老害どもは、
英語やローマ字の短縮形を複数組み合わせて
暗号みたいな造語項目作って、別途、項目辞書で管理するのが
当たり前だと思ってやがる…
文字数や日本語の制限とかもう無いし、いいから早く氏んでくれよ。
海外利用どころか、日本でも通用しないよ…
0134NAME IS NULL
垢版 |
2009/12/16(水) 20:15:31ID:???
英語に決まってんだろ！
sql文を書く時、いらいらする。
そんなこともわからんのか。
0135NAME IS NULL
垢版 |
2009/12/16(水) 20:34:08ID:???
日本語の方が短いし、入力時間も速いよ。
0136NAME IS NULL
垢版 |
2009/12/17(木) 21:54:30ID:???
>>135
何が短いの？
いちいち日本語かどうか気にしながらSQLを書くことは、効率的ではない。
0138NAME IS NULL
垢版 |
2009/12/18(金) 23:56:24ID:+v0ZCbDz
>>136
英語の場合、どうせスペルミスするからフィールド名は
テーブル定義からコピペするだろ？
日本語でも英語でもＳＱＬ書く作業に代わりは無いよ。
英語フィールド名を確実に間違えず書ける奴なら話は別だが…
0139NAME IS NULL
垢版 |
2009/12/19(土) 21:44:53ID:???
>>138
おれは、カラム名はコピペしない、タイプする。
なぜなら、どうぜそのカラム名を覚える必要があるから、打って覚える。
だから、カラム名のときに、いちいち日本語にしながらSQLを打つのは、思考能力を妨げる何者でもない。
0140NAME IS NULL
垢版 |
2009/12/19(土) 22:10:11ID:???
>>139
テーブル名、カラム名、データの他にいったい
何が残るというのだろう。
0141NAME IS NULL
垢版 |
2009/12/20(日) 22:56:44ID:???
と言うかスキーマ・テーブル・カラム名を日本語にすると時々変な不具合とか出るのが嫌だ。
今は完全対応済、絶対大丈夫、と言われても、
何か信用できないところがあるのは俺だけだろうか？
0142NAME IS NULL
垢版 |
2010/01/06(水) 17:08:31ID:???
ローマ字読みが一番ムカツク
というか、ほぼ確実に糞なプロジェクト、汎用性を持たせるか割り切るか、どちらもできなかったんだろうな
0143NAME IS NULL
垢版 |
2010/01/09(土) 15:53:29ID:???
間違った英語が当ててあるのもかなり厳しいものがあるけどね
0145NAME IS NULL
垢版 |
2010/03/06(土) 22:18:13ID:paAZYSbY
漢字コードはバグのもと
0146NAME IS NULL
垢版 |
2010/03/06(土) 23:19:08ID:???
20数年日本語のテーブル名、フィールド名以外使ったことないな。
でもこのスレ見てると英数を使ってるところ多いんだね。
0147NAME IS NULL
垢版 |
2010/03/07(日) 13:28:50ID:???
英語でも日本語でもわかりやすければなんでもいい
慣れだよ。
個人的には日本語が好き。
日本語名を使うとプログラムとか環境によってダブルクォートとか必要になったりする。
こっちで動いたプログラムがなんでこっちだと動かないんだ　とか
0148NAME IS NULL
垢版 |
2010/03/10(水) 19:32:14ID:???
いろんな開発環境を想定した場合、半角英数字しかねーだろ？
0149NAME IS NULL
垢版 |
2010/03/12(金) 21:09:27ID:???
テーブル数が数百あるシステムとかだと半角英数字だと暗号みたいになって可読性がものすごく悪い。
日本語のほうが読みやすいしミス防止や作業効率ＵＰのために日本語のほうがよい場合もある。

最近目が悪くなってきて半角英数字より全角日本語のほうが読みやすいし
日本語を使えるならできるだけ日本語を使うべきだと思うようになってきた。
0150NAME IS NULL
垢版 |
2010/03/14(日) 15:17:48ID:DtdqkEWk
>>149
と思ってるとやっぱりミドルウェアの予期せぬバグにやられる罠
0151NAME IS NULL
垢版 |
2010/10/01(金) 08:53:01ID:???
>>150

Oracleの場合(他のDBは知らない)

表名や列名などのOracle Objectは半角英数字とアンスコなど一部
の特殊記号以外を使う場合、つまりマルチバイト文字などが含まれ
るときはダブルクォーディング(ダブルクォートで囲む)しないと
動作保証されない。

たとえ今のバージョンでマルチバイト文字を含んだ表名や列名が
エラーにならなくても、Oracleのパッチを適応したり、バージョン
をアップするといきなりエラーになるかもしれない。

裏付けが欲しければ、OracleサポートやOracle Directに確認せよ。

動作保証外のことをやるのはその人の勝手だが、パッチを適応や
バージョンアップ時に膨大な修正を強いられるだけ。

もっとも、そういう身勝手な設計をする人はバージョンアップ時に
はトンズラしているだろうが。

0152NAME IS NULL
垢版 |
2010/10/01(金) 19:21:43ID:???
>>151
15年以上まったく問題無かったのだが
そうだとすると残念なことだ。
0153NAME IS NULL
垢版 |
2010/10/02(土) 07:21:46ID:???
今後不具合が生じるような改変がなされる可能性はほぼゼロではないか。
技術的にマルチバイト文字を特別視する領域は見つからない。
0154NAME IS NULL
垢版 |
2010/10/03(日) 22:47:10ID:???
環境やネットワーク、連携などにおいて比較的にクローズドな環境なら日本語使っても問題はほぼ無いし(あれば潰せばいいだけ)、そうでなく外部接続やフロントエンドの範囲が不明な場合や将来性において最後まで面倒が見れないような場合は2バイト禁止すればよい。
0155NAME IS NULL
垢版 |
2010/10/19(火) 14:16:22ID:dBdSbcBS
>>152
最初にサポートに確認しない方が悪い。
0156NAME IS NULL
垢版 |
2010/10/19(火) 16:53:15ID:???
順序が逆だね。
ずーと、五年以上 "テーブル名" で使っていて、
ある時実は テーブル名 でも使えることに気づいて、
テストを重ねて、これなら大丈夫となって、
ダブルクオートを外した。サポートなんて、元々完全に
無視している。
0157NAME IS NULL
垢版 |
2010/10/20(水) 12:08:26ID:fiUikrto
>>156
みっともないから、
動作保証されないことに命をかけるのは止めた方がいい。
0158NULL IS NULL
垢版 |
2010/10/20(水) 18:47:30ID:???
>>156
Oracleのバージョンを上げたらダブルクォーティングしていないテーブル名や
列名がいっせいにエラーになるかもしれないリスクを考えていないね。

その時はトンズラすりゃ良いってね。
0159NAME IS NULL
垢版 |
2010/10/23(土) 09:43:48ID:???
いまさらそんなリスクはほとんどないし、命かけるとか馬鹿じゃねーの？
0161NAME IS NULL
垢版 |
2010/10/23(土) 20:00:10ID:???
まあがんばればいいんじゃね。

俺は、あほらしいからやらんけど。
0162NAME IS NULL
垢版 |
2010/10/24(日) 17:19:43ID:???
で、いままで日本語にしたことのあるやついるのか
0163NAME IS NULL
垢版 |
2010/10/24(日) 17:36:56ID:???
あるお客さんの環境では、日本語を使っているを見たことがある。
でも、実際には、英語名のカラムにしたviewが別にあって、そっちを使うように指示が出ていたよ！
0164NAME IS NULL
垢版 |
2010/10/24(日) 19:12:43ID:???
>>162
Oracle7.2で機種依存文字を含んだマルチバイト文字でテーブル名や列名で
作ったもの(当然ダブルクォーティングなし)をOracle9.2に移行したら、
ダブルクォーティングしないとエラーになってとんでもない作業量になった
と泣いていた人を知っている。

胃に穴があいて1年以上休んで、結局退社したそうだ。
0165NAME IS NULL
垢版 |
2010/10/24(日) 19:27:21ID:???
何だかんだで英語のほうが無難ってことにうちの会社は行き着いてる。
そういや、日本語使ってる人はプログラム等でも変数に日本語使ってるのかな？
0166作り話乙
垢版 |
2010/10/24(日) 21:25:21ID:???
>>164
SQL のフィールド名とかをダブルクォーテーションで囲むぐらいのことで
「とんでもない作業量」になるような設計だといずれ破綻してると思うよ。
0167NAME IS NULL
垢版 |
2010/10/25(月) 03:07:07ID:???
>>164
サーバサイドなのかクライアントのアプリなのかは知らんが、その程度のことはデバックさえしっかり出来れば8割9割は自動化出来るだろ
0168NAME IS NULL
垢版 |
2010/10/26(火) 11:42:06ID:???
Oracle Directのセミナーで用意されるテキストのテーブルもマルチバイトの
テーブル名や列名をダブルクォーティングしていない。
自分の会社の看板に泥を塗っているやつらだ。

そういうのを見ていて 159 みたいに思う人が出てくるのであろう。
0169NAME IS NULL
垢版 |
2010/10/26(火) 20:13:46ID:???
アンカの付け方一つ知らないヤシが何言っても説得力ゼロだな
0170NAME IS NULL
垢版 |
2010/10/27(水) 00:06:39ID:???
どうせなんかのセミナーとかで聞きかじって得意になって >>151 を書い
たら馬鹿にされたので、顔真っ赤になってるだけだろ。

こんなことで「リスク」とか言っちゃってるのがほほえましいじゃないか。
0171NAME IS NULL
垢版 |
2010/10/28(木) 11:28:35ID:???
>>166
Oracle7.3で機種依存文字を大量に含んだ表名や列名があるシステムで
テーブル数が1,000以上ってのをOracle10.2.0へ移行するのを助っ人で
手伝ったことがある。

ダブルクォーティングの作業なんか予定になかったからスケジュールの
期限に間に合わなかった。今使われているどうかもわからないプログラム
も含めて、何万とあるSQLの動作確認も必要だったからメンバーを10人
補充してもらったが2ヶ月以上遅れた。

基本給より残業代の方が多かったが、マルチバイトで設計したテーブル
のシステムの依頼はすべて断っている。
0172NAME IS NULL
垢版 |
2010/10/28(木) 11:51:35ID:???
>>171
何でその程度のことを予知できなかったのかな。

0173NAME IS NULL
垢版 |
2010/10/28(木) 12:12:19ID:???
機種依存文字を大量に含んだテーブル名、フィールド名を
ダブルクォーティングすることには、誰も反対していないと
思うけど。
0174NAME IS NULL
垢版 |
2010/10/28(木) 14:34:59ID:???
>>170
マルチバイトでテーブル設計するのが格好良いと思っているのかな？
それもダブルクォートで囲まないで。

将来、会社に多大な出費を強いるかもしれないというリスクを負うこと
がわからないのか？

みっともない仕事はしないように。
0175NAME IS NULL
垢版 |
2010/10/28(木) 21:31:04ID:???
>>171
誰が作業工数見積もったか知らんが（まさかおまえじゃないよな？ｗ）、移行元のDBでマルチバイトが使われているにもかかわらず
ダブルクォーティング作業を工数に入れないのはただの凡ミスだろうが。基本中の基本だろ、そんなこと。

挙句逆切れとか、そんな業者、客の方が願い下げだろjk
0176NAME IS NULL
垢版 |
2010/10/28(木) 22:02:18ID:???
どうせ >>164=>>171 だろうけど...

> 何万とあるSQLの動作確認も必要だったから

Oracle 7.3 → Oracle 10i なら、動作確認はもともと必要だろ。

うそつくにしても素人杉。
0177NAME IS NULL
垢版 |
2010/10/29(金) 12:03:41ID:???
お客様の要望なら全角文字だろうが機種依存文字だろうが、使えば。
後で何が起ころうとそういう要求を出した側の責任。

1995年になってもわが社では年は2桁で持つことにしています、って
豪語していた会社もあったし。
0178NAME IS NULL
垢版 |
2010/10/29(金) 15:53:43ID:???
ダブルクォーツで囲むか囲まないかはたいした問題ではない。つまり、
だから日本語を採用するかしないかと言うような影響のでる事ではない。
読み易さ、使いやすさの問題。
日本語をフィールド名に採用するか、どうかは、データモデルと
プログラミング、オペレーション時の認識に関わる問題でずっと深刻。
一般論としては、フィールドとは集合の事だから、集合の要素の大半が
全角文字で表された場合は、フィールド名(属性)も自ずと全角文字が
使われることが予想される。それが自然ということ。
0179NAME IS NULL
垢版 |
2010/10/30(土) 11:42:04ID:???
> フィールドとは集合の事だから

珍説はチラシの裏にでも書いとけ。
0180NAME IS NULL
垢版 |
2010/10/30(土) 14:50:12ID:???
まとめると
日本語派→わかりやすさ重視
英数字派→互換性重視
ってことだよな。
結局、戦争に勝ったのにろくに英語教育しなかったアメリカが悪い。
占領した朝鮮にちゃんと日本語教育してやった日本はもっと評価されるべき。
0181NAME IS NULL
垢版 |
2010/10/30(土) 21:26:30ID:???
>>178
設計段階では、データベースってのは確かに集合でしかないわけだからあんたの言っていることは正しい。
ただし、実装段階でハードやらソフトの制約を受けた時点で、集合論のそのままを表現できるわけじゃないことぐらい分かるだろjk
0182>>178=>>181
垢版 |
2010/10/30(土) 22:45:24ID:???
>>181
> データベースってのは確かに集合でしかない

珍説はチラシの裏にでも書いとけ。
0183NAME IS NULL
垢版 |
2010/10/31(日) 00:19:43ID:???
>>182
おいおい、人を勝手に自作自演にするなよｗ
T字形でもやれば、データモデルが集合論であることは良く分かる。

ただ、それをそのままデータ設計に持ち込むのは論外だと言っているまでで。
集合論からのアプローチは珍説でもなんでもない。
0184NAME IS NULL
垢版 |
2010/10/31(日) 09:26:47ID:???
フィールド名とデータの中身の区別もついてないのか...。

さすがに珍説を堂々と書ける椰子は頭の構造が違うな。
0185NAME IS NULL
垢版 |
2010/10/31(日) 11:55:41ID:???
中身に日本語が使えて、名前に制約があるのはソフトの問題。
本質的な話じゃない
0186珍説以前だったな
垢版 |
2010/10/31(日) 13:18:35ID:???
> 中身に日本語が使えて

中身の話なんて誰もしてない。

スレタイすら読めてないのか...。
0187NAME IS NULL
垢版 |
2010/10/31(日) 13:25:01ID:???
>>186
名前に日本語の制約がないなら、それでいいんじゃないの？
0188NAME IS NULL
垢版 |
2010/10/31(日) 14:04:17ID:???
>>186
文句が言いたいばかりに、自分の言っていることが支離滅裂になっていることも気がつかない？
0189NAME IS NULL
垢版 |
2010/10/31(日) 18:08:14ID:???
スレ違いを指摘されて逆切れ？
0190NAME IS NULL
垢版 |
2010/10/31(日) 18:35:38ID:???
論理的な話もできずに、派生した話をスレ違いというだけの低脳がなにを言うｗ
0191NAME IS NULL
垢版 |
2010/10/31(日) 20:49:45ID:???
最近は、唐突に違う話題を垂れ流すのを「派生」とか言うのか？

まあ、(リレーショナルデータベースの) データモデルが集合論に
関係しているって知ってるなんてしゅごいでちゅねぇ〜

とか言われれば満足かな (ゲラ
0192NAME IS NULL
垢版 |
2010/10/31(日) 22:53:00ID:???
例えば、全角文字を含むフィールド名はダブルクォーティングしなくては
ならないような愚劣なRDBMSをどれだけ速やかに他のシステムに乗り換える
ことができるかが問われているということだ。
0193NAME IS NULL
垢版 |
2010/11/01(月) 22:08:37ID:???
ダブルクォートするよりシステムを乗り換える方が簡単なのか？
0194NAME IS NULL
垢版 |
2010/11/02(火) 02:58:00ID:???
それは場合によるけど、リプレースする有力な根拠になるということでしょう。
0195NAME IS NULL
垢版 |
2010/11/02(火) 08:07:17ID:???
2バイト項目名がダブルクォートされていないので、リプレースしましょうと提案するのか？ありえないだろｗ
2バイトOK（動作保障的に）なSQL Serverに乗り換えるとかそういうことか？

異なるRDBMSに載せかえるくらいなら、コスト的に素直にダブルクォーティングするか、DBの改修（2バイト名の1バイト化）しかありえん。
0197NAME IS NULL
垢版 |
2010/11/02(火) 09:18:17ID:???
愚劣で未来のない仕様のシステムは次回の選定で外されるということですねw
0198NAME IS NULL
垢版 |
2010/11/02(火) 22:44:53ID:???
その前にそんな提案をするお前が次回の選定ではずされるだろ
0199NAME IS NULL
垢版 |
2010/11/02(火) 23:32:05ID:???
クォートされたマルチバイト文字は通るが、されていなければ問題があるかもしれない
なんてパーサーは、一目見ただけで食欲をなくすようなすごいソースなんだろうな。
0200NAME IS NULL
垢版 |
2010/11/03(水) 04:40:14ID:???
OLracleのバージョンアップでCHARACTERSETをJA16SJISからAL32UTF8に変えたら
テーブル名、列名、ストアドプログラム名など30バイトの制限を超えたユーザー
があって、笑えた。
0201NAME IS NULL
垢版 |
2010/11/03(水) 15:20:42ID:???
SQL Serverなんて、キャラクターセット変えた程度でDB２との通信ができなくなったりする（ドライバがらみのバグ）んだぜ。
これが商用RDBMSとは到底思えないレベル。
こんなことでバグ取り1週間とか、正直笑えない。
0202NAME IS NULL
垢版 |
2010/11/03(水) 16:08:31ID:???
SQL Server 本体ならともかく、ドライバ、しかも DB2 との通信だろ。
馬鹿ですか？
0203NAME IS NULL
垢版 |
2010/11/03(水) 16:53:02ID:???
>>200　>>201
笑うことでリューマチの痛みが軽減するものだとのことでございます。
0204NAME IS NULL
垢版 |
2010/11/03(水) 16:53:30ID:???
>>202
SQL Serverが起因するキャラクタセットのバグでデータ異常が発生して、それがキックにドライバで不具合、結果DB2との通信時に落ちる。
0205NAME IS NULL
垢版 |
2010/11/03(水) 19:30:18ID:???
>>204
> SQL Serverが起因するキャラクタセットのバグでデータ異常が発生して

それは問題だ。
で、どのバージョンの話かな？
ソースつきで、頼むよ。
0206NAME IS NULL
垢版 |
2010/11/03(水) 19:54:42ID:???
>>205
ソースがあるぐらいのバグなら苦労しないだろｗ
SQL Server 2005 Workgroup Editionだったのは覚えているが、ビルド番号や該当するキャラクタセット、
DB2のバージョンやドライバの種類なんかは当時の備忘録紐解かないと覚えてない。
そして、それは面倒くさいから勘弁してくれｗ
0207NAME IS NULL
垢版 |
2010/11/03(水) 20:09:03ID:???
> ソースがあるぐらいのバグなら苦労しないだろ

はあ？ データ異常が発生するようなバグなら、HotFix なり ServicePack
が出てるだろ。何言ってるんだ？

> それは面倒くさいから勘弁してくれｗ

はいはい、言い訳乙。
0208NAME IS NULL
垢版 |
2010/11/03(水) 21:55:49ID:???
>>207
実務で扱ってれば、公式対応されるバグなんてごく一部なことぐらい分かりそうなもんだが。
おまえ、素人だろ。
0209NAME IS NULL
垢版 |
2010/11/03(水) 22:45:47ID:???
なんか状況が目に浮かぶようだw

>>208　「これバグだろ！！」
サポート　「はいはいw」
0210NAME IS NULL
垢版 |
2010/11/04(木) 19:10:21ID:???
ふーん、いきなり電話するんだ、サポートとやらにｗ
実際に仕事してる奴の台詞とは思えないなｗ
0211NAME IS NULL
垢版 |
2010/11/04(木) 20:30:54ID:???
バグだろうがこっちのミスだろうが、なにか自分らで解決できない問題が起きたら
サポートに電話するけどな、うちは。
バグだという確証が得られるまでサポートに連絡しないの？
0212NAME IS NULL
垢版 |
2010/11/04(木) 22:16:16ID:???
俺が知っている限りでは、当時（今もそのはずだが）SQL Serverに関する要望やバグを日本語で直接シアトルに電話でコンタクトする方法はなかったはずだが。
Visual Studio と .NETに関してはルートが存在していたが。

直接やりとりをできるサポートを知ってるなんて、MSの関係者ですか？ｗ
0213NAME IS NULL
垢版 |
2010/11/04(木) 22:36:00ID:???
何で直接シアトル？
0214NAME IS NULL
垢版 |
2010/11/04(木) 22:47:24ID:???
>>208
ああごめん、誰かさんの「脳内バグ」なら公式対応はしないだろうな (w

>>212
保守契約したらＭＳの関係者じゃなくても「サポートと直接やり取り
できる」よ。
て言うか、実務なら保守契約必須だと思うが...。
0215NAME IS NULL
垢版 |
2010/11/05(金) 09:24:43ID:???
それこそ場合によるだろうけど、
データベースの専門企業は別にすると
サポートを受けている方が少数派ではないか。
0216NAME IS NULL
垢版 |
2010/11/05(金) 22:36:54ID:???
データベースの専門企業？OracleやMS自身のことじゃぁないだろうからSIerのことか？
「サポート」って、いわゆるパートナー契約のことを言ってるのか？

もしかして、>>205が「ソース出せ」って言ったのをソースコードと勘違いして、シアトルに
電話するとか頓珍漢な話になったんじゃないだろうなw
0217NAME IS NULL
垢版 |
2010/11/06(土) 09:28:42ID:???
データセンタとかを言ってるんじゃないかな？

まあ、「サポートを受けている方が少数派」とか言ってるぐらいだから、
>>215 はこの手のお仕事したことないんだと思うよ。
0218215
垢版 |
2010/11/06(土) 10:27:28ID:???
私の知っているSQL　Serverを使っている企業は、
業務ソフト入れたら、SQL Serverが入ってました。もったいないから、
ACCESSから乗り換えました、というような所ばかりで、
「実務なら保守契約必須」なんてことはなさそうだから、書いてみた。
私の言葉の選択が適切でなくて、話が通じなかったようだけど。
0219NAME IS NULL
垢版 |
2010/11/06(土) 12:04:23ID:???
社内の運用管理なのかデベロッパーなのかでバグ対応に関する認識が異なるんだろ。
運用管理者や社内の情シスなら、よほどの重大なバグでもない限りいずれかのタイミングでバグフィックスされれば構わない。

デベロッパーの立場になれば、納品までにバグが解消できなきゃまったく意味がない。
0220NAME IS NULL
垢版 |
2010/11/06(土) 16:40:05ID:???
>>218
> 業務ソフト入れたら、SQL Serverが入ってました。

そりゃその業務ソフトのメーカーが保証するからエンドユーザーが
SQL-Server の保守に入らんことは珍しくない。

> もったいないから、ACCESS から乗り換えました

意味わからんのだが...、業務ソフトが使ってる SQL-Server を別
の用途に使ってるってこと？

おれがその業務ソフトのメーカーなら、基本的に他の用途に使うの
はダメと言うけどね。

そもそもそんなことしなくても Access からの乗換えなら
Express で十分だと思うし。

>>219
社内システムでもバグが発生したら困るだろ。
たとえば、給与システムで次の給与の支払いまでにバグが解消でき
なきゃ大問題だぞ。
0223NAME IS NULL
垢版 |
2012/05/26(土) 16:39:53.65ID:???
以前はORACLEでもフィールド名やテーブル名を全角文字にするためには
ダブルクオートが必要だった記憶があるけれど、あれはいつ頃から必要なく
なったのだろう。
0224NAME IS NULL
垢版 |
2012/05/26(土) 22:51:06.10ID:???
ORACLE今もダブルクォート必須だよ。
そうしないと、同じ構文でも正常に動作したりしなかったりする。

0225NAME IS NULL
垢版 |
2013/02/03(日) 07:55:06.50ID:Ri2ixUto
パッケージのバージョンアップでAL32UTF8にしか対応しなくなり、Oracle 9i SJIS → 11g AL32UTF8 に回されてしまった。
AL32UTF8 は半角カタカナとマルチバイト文字が1文字3バイトになるので文字列が桁あふれする可能性が出てくるので、あらかじめテーブルやストアド・プログラムの変数の桁数を見直さなければならない。
それ以前に、マルチバイト文字11文字以上で設計した、テーブル名、列名、索引名、ビュー名、ストアド・プログラム名、SYNONYM名、タイプ名などの定義がエラーになった。
-- //docs.oracle.com/cd/E16338_01/server.112/b56299/sql_elements008.htm#i27570

テーブル定義以外にプログラムの大修正が必要になった上に、CSVをOracleにI/Oする UTF_FILEで CONVERT キャラクタセットを変換したら文字化けするバグが見つかり、来月の納期を延ばしてもらうように管理者に依頼した。
0227靖国参拝、皇族、国旗国歌、神社神道を異常に嫌うカルト
垢版 |
2015/02/14(土) 18:56:51.52ID:m5S6ogoG
★マインドコントロールの手法★

・沢山の人が偏った意見を一貫して支持する
　偏った意見でも、集団の中でその意見が信じられていれば、自分の考え方は間違っているのか、等と思わせる手法

・不利な質問をさせなくしたり、不利な質問には答えない、スルーする
　誰にも質問や反論をさせないことにより、誰もが皆、疑いなど無いんだと信じ込ませる手法


偏った思想や考え方に染まっていたり、常識が通じない人間は、頭が悪いフリをしているカルト工作員の可能性が高い


10人に一人はカルトか外国人

「ガスライティング」で検索を！
...
0228NAME IS NULL
垢版 |
2015/06/01(月) 04:41:04.50ID:7dT47AdX
　
お世話になります。
私、責任者の加茂と申します。以後、宜しくお願い致します。
http://www.apamanshop.com/membersite/27009206/images/kamo.jpg
浪速建設様の見解と致しましては、メールによる対応に関しましては
受付しないということで、当初より返信を行っていないようで、今後につい
てもメールや書面での対応は致しかねるというお答えでした。
　
このように現在まで６通のメールを送られたとのことですが、結果一度も
返信がないとう状況になっています。
　
私どものほうでも現在までのメール履歴は随時削除を致しております
ので実際に１１通のメールを頂戴しているか不明なところであります。
　
　　共通覧
　　http://s-at-e.net/scurl/common-list.html
　
　■http://s-at-e.net/scurl/ia-Pos.html
　■http://s-at-e.net/scurl/ia-0074.html
　
　・A　http://s-at-e.net/scurl/ia-A.html
　・T　http://s-at-e.net/scurl/ia-T.html
　
　　碧　
　　http://s-at-e.net/scurl/Blue.html
　
大阪府八尾市上之島町南 ４-１１ クリスタル通り２番館203
に入居の引きこもりニートから長期にわたる執拗な嫌がらせを受けています。
この入居者かその家族、親類などについてご存知の方はお知らせ下さい。
hnps203@gmail.com
　
　〈 http://s-at-e.net/scurl/kenmou-post_id_28.html 〉
　〈 http://atsites.jp/sate/ImaLin/imaitsuwa/imaitsuwa.html 〉
0229NAME IS NULL
垢版 |
2017/12/29(金) 12:04:17.26ID:dtNZwIie
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

2EFN62JLAQ
0230NAME IS NULL
垢版 |
2018/02/14(水) 13:33:51.59ID:???
☆ 日本の、改憲をしましょう。現在、衆議員と参議院の両院で、
改憲議員が３分の２を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆
0231NAME IS NULL
垢版 |
2023/10/18(水) 18:24:50.02ID:???
ファントムハイヴ家の執事たるもの、この程度の技が使えなくてどうします
新着レスの表示
レスを投稿する

ニューススポーツなんでも実況