「東証システム、構築は10年前ですでに耐用年数もオーバーしていた」記事へのコメント

約定件数

[Anonymous Coward]

> 約定件数の1日当たりの上限を500万件に引き上げる

350万件（400万件？）から500万件って、10年たってもあまり変わらないんですね。
素人の目でコンピュータの成長を見ていると、今なら5億万件ぐらい処理できそうな気がするんですが…

Re:約定件数

[nq (16642)]

タレこみ人ですが、処理件数というのが、処理のためのメモリーとかスループットで決まっているのではなく、一日分の記録件数で決まっているのがまず驚きました。
　システム増強といっても、単にハードディスクの容量を増やして、それに対応してプログラムの配列の上限チェックを変更しているぐらいと想像しますが、それで2倍程度にしか増えない、ということにまた驚きます。技術的進歩を考えれば、100倍ぐらい、楽々増やせるはず。

　素人考えですが、500万件の売買記録にどれぐらいの記憶容量が必要かと勘定してみると、銘柄コード、取引時刻、売り手コード、買い

Re:約定件数

[Anonymous Coward]

日本の開発者ってやたらとCHARやVARCHARにしたがる人が多いと思いませんか？
IDにしても英数字を入れるから絶対にCHARだと言い張る人が多くて頭が痛いです。
DBのマニュアルには数値型を使ったほうが速いと書いてあるのですが、なぜ容量が余計に必要なCHARにしたがるのかよくわかりませんが、そのような傾向があるようです。
＃少なくとも某社の人たちは。

Re:約定件数

[minek (14559)]

　だってさ。9(n)にするとさぁ、数字しかはいんないじゃない？ X(n)にしとくとさぁ、いざというときに16進数に逃げる余地がね……。

　でも、集計や計算の必要のない識別子はchar(n)でよいと思いますけど。なんでもかんでもvarchar(n)は、行連鎖を引き起こす危険性があるので好きではないですが。速いからといって、ビット型で構成されたデータベースを使いたいとは思いませんし、適材適所でしょう。
# という判断を標準で殺している場合がある、というのは同意。
## そして、現場に任せたらそれ以上にひどいことになる、というのも同意。
## フラグの判定を半角スペースとNullでやるのはやめて……。

Re:約定件数

[Anonymous Coward]

だまされていませんか？CHARであろうが、BINARYであろうが、検索は同じ速度でやってくれますよ。INDEXを張ってなかったとかそういうことではありませんか？

通貨用10進が無かった頃は

[Livingdead (18685)]

二進数浮動小数点数として扱われてしまうと困るときには、わざわざ文字列にして格納していたと伝え聞いています。でもいまちらっとSQL-92の頃の本を見てみたら、DECIMALとかNUMERICとかありますね。

--
屍体メモ [windy.cx]

Re:通貨用10進が無かった頃は

[minek (14559)]

COBOL-Sにおいては、固定小数点数9(n)V(m)と数値9(n+m)をデータ上で見分けることはできません。レイアウト上のお約束で、そこに小数点がある、と思って読んでいるだけです。REDEFINEしてしまえば、まったく別の型で読むこともできますし……。
# 浮動小数点と通貨型の話はWindows以降の話だと思ってた。

Re:約定件数

[ryokiwind (22763)]

開発者は数値メインで使いたいと思いますよ。
index張るにしても、色々と数値の方が扱いやすいですから。
問題は設計者だと思います。

客の要望が幾ら文字列IDじゃなければ駄目とか言ってきたとしても
たとえば、内部でアスキーコードに変換して数値処理するとか
隠蔽してしまえば客にはわかりません。

Re:約定件数

[Anonymous Coward]

システム全体が自システムだけで完結するんならソレでもいいのだけどね…。

Re:約定件数

[Anonymous Coward]

>日本の開発者ってやたらとCHARやVARCHARにしたがる人が多いと思いませんか？

いや、現場ではシーケンスIDにVARCHARなんて使いたくはないんですが…
(ORDER BY TO_NUMBER(x)なんてやるのよっ!)
DBセンタの人々が
「NUMBERはつかっちゃだめよーん」
だってさ…

#おかげでエンティティBeanが作れなくて泣き目を見たのでAC

Re:約定件数

[Anonymous Coward]

大抵のDBではNUMBERは2進化10進数(2桁で1バイト)だろうから、情報量に対する容量はむしろ不利じゃないか？