SQL?（´,_ゝ｀）ﾌﾟｯ（ﾟДﾟ）ﾊｧ?

1 ：2007/05/26 〜 最終レス ：2013/03/12

いいか、ここにSQL系のDBがあり数値型のフィールドにSQLで数値データを登録するプログラムがあったとしよう。
その数値データはデータソースのプログラムの段階ではコンパイル済みのバイナリデータである。
しかしそれをわざわざSQL用にテキストに変換してDBエンジンに送る訳だ。
送った先のDBではやはりテキストを解析して数値データに戻す処理がなされる。
そんな穴を掘って埋めるような事が今世界中のSQL系DBを使うシステムの内部で行われている訳だ。
なぜ数値を数値のまま送らない？

2 ：

（ﾟДﾟ）ﾊｧ?

3 ：

つ【オブジェクトデータベース】

4 ：

リプレイス時に十分な検討期間が取れず
結局過去の仕様のまま移植するハメになると
汎用機まがいの固定長データ大盛りなシステムを
最新RDB＋．NET系言語で構築しなきゃならないこともざらにある
上流がアレな業界の仕事だからあきらめろ>>1

5 ：

XMLDBなんてのはもっと酷い。DBの実体がテキストだからな。

6 ：

つ【CLOB】

7 ：

穴を掘って埋めるだけで金がもらえるんだから良いではないか？

8 ：

自分で掘った穴に落ちたり、人の掘った穴どころか溝に落ちたり、
調子に乗って掘ってたら地雷を掘り当てたりするから嫌なんだよなー。

9 ：

ワリィ。その地雷追加したの俺だわ。

10 ：

それくらいトランザクションの仕事量の中では屁でもない。
それ以前にSQLをプログラムに埋め込むこと自体を否定しなさい

11 ：

>>10
激しく同意

12 ：

>>10
（ﾟДﾟ）ﾊｧ?
kwsk

13 ：

>>12
激しく便意

14 ：

O/Rマッパとか。

15 ：

マッパって言うと真っ裸ーニバルみたいな感じがして嫌

16 ：

a--------------------------

のmmだ

17 ：

本来のデータ入出力の処理で言うとDBに直接コネクトしてバイナリデータの出し入れをして切断する
のが自然(ADOみたいな)なわけだが、
何の訳かSQLなんて非効率な方法が普及してしまって。
馬鹿でもわかる英語にしてやらないと駄目なんかね？
SQLのせいで関係演算が全く抽象化されていない（できない）のも問題だね。

18 ：

する必要もないと思った。

19 ：

バインド変数でバルク転送すればすげー速いよ。

20 ：

そして、65535行でずっこける。(OCIの場合）

21 ：

…で、
>SQL系のDB
って何さ。
>>17
阿呆はファイルにでも書いとけ。

22 ：

SQLを使ってデータを取得するDBって事だろう。
リレーショナルデータベースという言葉が出てこなかったんだよ。

23 ：

>>1
PreparedStatement の場合どうなりますか？

24 ：

それに加えてOracleのハード解析というプロセスがあるのだけれど…

25 ：

システムは変換機能の追加でどんどん重くなるの法則

26 ：

＞リレーショナルデータベースとSQLを使ってデータを取得するDB
定義が全く違うぞ。
SQLを使う以上穴を掘って埋める作業は永久に無くならない。
こりゃ新しいDB作るしか無いな。
なんでメモリ空間みたいにDBに直接アクセスするインタフェースが無いんだろう。
そこで関係演算も直接実行できれば良いのに、
いちいちSQL書いてjoinとか打たなきゃ行けないのか。

27 ：

それと多分PreparedStatementとかORマッパとか使ってもDB側が
JDBC経由ではSQL以外の接続を認めてないと思うから、
最終処理はSQLを介してると思うけど、違うのか？
MySQLは多分そう。Oracleは知らん。

28 ：

>>20
ＯＣＩって半分じゃなかったかね？

29 ：

1の言うような問題点が解決したDBエンジンが誕生したとして、どんだけーのパフォーマンス改善が見込めるだろうか？

30 ：

http://www.componentsource.co.jp/features/ag-tech/index.html
検索キーで利用するＤＢもあるよ。
ＳＱＬでも利用できる

31 ：

パラメタライズドクエリは、バイナリのデータを送ってるんじゃないの?

32 ：

>>1にはAS/400(iSeries)＋RPGの開発をお勧めするわ。

33 ：

データをテキストに変換した場合、負担増となる個所は
　　CPU負荷
　　I/O負荷
　　ネットワーク負荷
の3点が考えられる
CPU負荷が問題になる可能性は、経験上除外して良い
I/O負荷に関してはデータ変換後にHDDに書き込む為、関係ない
ネットワーク構成
(a)データベース --- (b)アプリケーション --- (c)クライアント
�T. a-b-cが単一サーバの場合
　ネットワーク負荷は発生しない
�U.a-bが単一サーバの場合
　ネットワーク負荷は発生しない
�V.a-bが別サーバの場合
　高速なLANで接続されている為、問題なし

以上、どう考えてもSQLをバイナリに置換してもメリットは発生しません

34 ：

SQLはそもそもが数学的な理論からはじまったひとつの宗教。
オブジェクト指向という宗教となじむかどうかなんて考えていない。

35 ：

事実、本来する必要の無いデータ型変換にどんなに短くても処理時間がかかってるのは間違い無い。
それが全世界のサーバーで毎日数億回のトランザクションがなされていれば数ナノ秒のロスも問題になってくる。

36 ：

そうナノ？

37 ：

そうナノ。

38 ：

そんなどうでも良いロス気にして仕事してたら何の仕事もできなくなるよ。
SQLは簡単だから、チームのみんなが理解できるから、開発効率が上がる、工数が減る。
そのメリットだけ見てりゃ良いじゃないか。もっと早い方法があったとして、それを理解するのに工数が増えるなら
誰も採用しないよ。バカ。

39 ：

アメリカや海外のシステムがどんな仕様だろうが関係ないじゃないか。
俺らに重要なのは目の前の仕事をいかにこなすかだ。

40 ：

>>38-39
お前はあらゆるシステムをPHPとVBで作ってれば良いよ。

41 ：

それいうなら
HTTPもFTPもメールも全てテキストベースだぞ

42 ：

まぁそれより、専門卒の頭の俺には
なんであんなに高速に検索できるのかがわからん

43 ：

>>1
そんな亊言ったら、俺らの仕事は全てが全て　穴掘って掘った穴埋めてを繰り返してるだけだろ？

44 ：

>>42
おまいは電話帳の中から相手の電話番号を何分以内で見つけられる？

45 ：

テキストベースからバイナリベースに変更しても字句解析、意味解析は必要になるので
劇的に速くなるわけじゃないぞ
昔のBASICでいえば変数は7文字より1文字のほうが速いもんね！っていうレベルだ

46 ：

いや、1が言ってるのはコンパイル後の話だから次元が違う。
>>41
その通り、インターネットを作った奴らが、
馬鹿でハードウェア的な効率重視の発想ができなかったから、
あらゆる分野で、無駄が蔓延ってる。

47 ：

インターネット上には暗号はいかなる種類でも流しちゃダメよ♪

48 ：

いいから日本語で書けよ
チョンは日本語書けるようになってから出直してこい

49 ：

いいからどうしたら良いのか、代替案を挙げろよ。
現状に不満があるんだろ？

50 ：

そうだな、例えばこのようなSQLの実行にあたって
select taA.fld1,taA.fld2,taB.name from taA left join taB on taA.bid = taB.id where fld3 < 5000;
テーブルの選択、行の抽出、値セットの取得、を別の関数にしたい。
javaっぽく書いたら
//テーブルの選択
DbObject.selectTable(taA,taB);
DbObject.relateTables(taA,taB,tableOperate.leftJoin,taA.bid,taB.id);
//行の抽出
DbObject.extract(taA.fld3,tableOperate.lessThan,5000);
//値セットの取得
Row[] = DbObject.getValueSet(taA.fld1,taA.fld2,taB.name);

みたいな感じかな。こういうインターフェースを標準化してDB側に持たして欲しい。
そもそもSQLはこういった本質的に異なる操作を一緒くたにしているのが気に食わない。

51 ：

select再現すんのが偉くダルそうだ

52 ：

>>50
今のSQLより大分機能が落ちそうだな

53 ：

GROUP BYしたサブクエリとかどういう関数にするんだろう？
普通にSQLを記述する方が効率的かつ可読性が高いと思うが。

54 ：

>>53
そういう凝った SQL は書かない人なんじゃないか？
単純な構文でできることしか SQL でやらなくて、細かいデータ操作は
言語の中でごりごりやってる。

55 ：

１万件中、9999件更新するような処理は言語でやってもいい様な気がするけど、
普通にデータを抽出して照会やら更新する作業はSQLが一番効率的だと思う。

56 ：

可読性もあるけど速度優先しなきゃいけないような場合もあるしな
運用次第だろうけど使い分けが必要じゃね？

57 ：

使い分けるとしても、あの>>50の様な言語仕様では
可読性と速度も両方期待できないが。
速度命ならRPGでも使えって話になりそうだし。w

58 ：

可読性とか言ってる奴は永久にVBとPHPでシステム書いてれば良いよ。
SQLの唯一で最大の利点は馬鹿でもわかるという点だから、速度なんか
どうでも良いんだよ。

59 ：

>>53
集計関数はDbObject.extractの後で
DbObject.sum(taA.fld3);
のようにして、定義してやれば良い。
50のソースを見て察しが付くとは思うがテーブルもフィールドもすべてオブジェクト化されているので、
サブクエリの場合は事前にテーブルオブジェクトを作る際に50の手順で作ったサブテーブルをテーブルオブジェクトにして
selectTableで指定してやれば良い。

たかだか5行のソースに可読性とか言ってる馬鹿には理解できないかもしれないが、
このような直接DBを操作するインターフェースがあればどんな複雑なリレーションの操作も
抽出条件もプログラムソースの側で扱うことができる。
SQLで複雑な抽出条件をfor loop等で構成するときにSQLがやたら長くなって、
エラーの出所がわからず苦労した経験は誰にでもあるだろう。

60 ：

このスレマ板とは思えないほどレベル低いなｗ

61 ：

SQLが関係演算の実装として不完全であることはRDBMSの生みの親のEdgar Codd
も指摘していた事実だ。
唯一の関係演算の標準化された実装であるSQLが不完全ならせめてDBエンジンを直接操作するインタフェースを用意して欲しい。
>>1はMSのADOのような実装の標準化を求めているようだが、ADOには関係演算に関する実装が無い。
俺はDBエンジンがSQLを解析した後にやっている操作を全てプログラムソースから直接実行できるようにして欲しい。
わざわざ不完全なSQLを介さないといけないのはRDBMSの理想からも外れてるし、
本来できるはずの操作もできなくしてしまっている。
OOPとRDBMSの親和性が無いのもそこに原因があると思う。

62 ：

＞SQLで複雑な抽出条件をfor loop等で構成するときにSQLがやたら長くなって、
それはSQLが悪いと言うケースよりも設計がタコなケースがほとんどだと思うが。
あとover(partition by hoge_id)みたいなのはどーすんの？かなり助長になると思うけど。
正直なところSQL書ける人間からするとOOP風味ってウザいんだけど。
そして、おそらくRDBMS内SQLのオプティマイザのほうが
一般的なプログラマの９割以上効率的な実行計画を作成していると思う。
おそらく50の人はレアな１割に入る人間なんだろうと思うけどサ。
漏れは金融系の仕事しているのだけども周りのCOBOLerとかは
99%がヴァカって印象があるぞ。
そいつらにOOPさせるくらいならSQL使わす方が万倍はマシだ。

63 ：

なあ、SQL本来の目的って、DBに対話アクセスするためのものじゃなかったの？
スピード云々なんて次元が違う話だと思うんだが。

64 ：

全てのテーブルに削除フラグと削除日時、作成日時、最終更新日時の列があって、レコード数が億とかなってる。
これって普通なの？

65 ：

間違いなく普通でない。

66 ：

前半分はよくあるけど億はすごいな
年金とかかｗ

67 ：

>>62
そんなオラクル依存の構文はSQLですらない。どんな機能であれ、OOPである限り、
いくらでも拡張できる。

68 ：

階層的クエリはどうすんの？

69 ：

>>67
あのoverはOracle依存ではなくDB2なワケだが。
50は本当にRDBMSを使った開発したことあるのか？
単にSQLが嫌いなDQNプログラマにしか見えんが。
いくらでも拡張できる、と言うならばSQLも同様にいくらでも拡張できるだろ。
ユーザー関数の記述にはSQLはもちろん、50の好きなOOPのC++、Java
で作成できるしな。w

70 ：

ＳＱＬの素晴らしさを解らない奴は経験不足の学生あがりだけだろ
ストアド使ってもまだパフォーマンスが酷いのって設計が悪い場合がほとんど
反論ある?

71 ：

＞わざわざ不完全なSQLを介さないといけないのはRDBMSの理想からも外れてるし
>>50がホザいているけど、どうしてコイツはAS/400で開発しないんだ？
OSがDBと融合されているから>>1や>>50の様な自称神プログラマーの
脳内理想通りにDBエンジンを直でドライブできるぞ。
正直漏れは飽きたし生産性が低いのでSQLﾏﾝｾｰだが。

72 ：

集合を理解していない奴にSQLを書かせるな
カーソルで１行ずつ取り出して
CSVよろしく全行全カラムを扱う
クソPGのネスト地獄に付き合わされるからな

73 ：

（自称）集合や関係演算を理解してるお前らがSQLに不満を抱かないのが不思議だ。

74 ：

完璧だが少数のアプリでしか使えない独自規格より、
不完全でもどのアプリでも応用できる共通規格がましってだけだよ。
完璧な独自規格は多くの場合、開発者のRー。
本当にすばらしければ他のアプリも取り入れるだろうし、そうしたら移行する。

75 ：

つ　LINQ
つ　HANDLER構文（MySQL限定？）

76 ：

実際どんな演算がSQLで不完全なのか教えて欲しいんだが。

77 ：

>73
んで、具体的になにが不満なわけ?
>>1の言ってる事は意味がよくわからんが、要するにストアドとかのDBオブジェクトとかを知らないだけに見える
さあ、全部論破できる自信があるぞ、かかってこい!スライム
本当はあれだろ、言語とかロジックに自信があったけど入社してみたらＳＱＬができないと話にならなくてバカにされて嘆いているんだろ?

78 ：

>>73
昔は小学４年くらいで集合を教えられてたんだけどなぁ
今の集合は義務教育を終えても理解できない代物なんだ？
SQLで集合を表現する事に不満を感じたことはないよ
73は何が不満なワケ？
>>77
彼はスライムではない。スライムにおびえて町を出られない町人の一人だ。
設定されたセリフ「モンスター退治？そんなのできるわけねぇよ」
を繰り返して言うだけのね。

79 ：

SQLに不満を持つのはいいが。
ク　ラ　イ　ア　ン　ト　に　と　っ　て　そ　れ　は　ど　ん　な　メ　リ　ッ　ト　が　あ　る　ん　だ　？
余計な工数がかかるだろが。
メンテナンスとか含めて考えると妥協できる程度じゃねーの？

80 ：

事前に登録できないSQLに対して、ストアドプロシージャは無力だよ

81 ：

どうみてもSQL否定派の負け
マイッタと言えよw
反論するなら具体的な対案くらいだせよ
アメリカの頭の良い連中が一生懸命作って市場でも受け入れられてるモノを否定するならそれなりの具体的な対案があるんだろ?
比較するモノが無いと優劣つけられん

82 ：

汎用機とオープン系を比較して
オープン系が勝てるとでも思ってんの？

83 ：

>>82
汎用機＋DB2　の環境を知らない人？

84 ：

＞汎用機とオープン系を比較して
個人的には10年前の汎用機と今のオープン系だと
オープン系の方が障害少ない現実があるな。
単に汎用機を普通に扱える人間が激減しているだけだろうけど。

85 ：

>>81
SQLに代わる対案を出す
エラベ ナンデモ ホゲテーブル　ドレ　ホゲテーブル.シャチクバンゴウ='012345';　
仮称：PYUT@言語

86 ：

>>85
ぴゅう太ｷﾀ━━━━(Дﾟ(○=(ﾟ∀ﾟ)=○)Дﾟ)━━━━━!!!

87 ：

シャチクバンゴウにﾜﾛﾀ

88 ：

新スレ

89 ：

固定長データが来たらマスタと突き合わせしてインデックスを更新して
なんてやっていたときに出会ったRDBの使いやすさに衝撃うけたけどな

90 ：

SQLは確か数学のなんちゃら賞取った素敵な発明じゃなかったっけ？

91 ：

>>90
http://ja.wikipedia.org/wiki/エドガー・F・コッド
当のコッド博士はSQLイクナイ！と言ってたらしい。
Oracleが先にできたから今でも生き残ってるんだね。

92 ：

SQL終わったな。これからは俺QLを使ってくだされ。

93 ：

彼女にINSERTしてもいいですか？
オマイラをDELETEしてもいいですか？TRUNCATEがいいカイ？
女子高生をSELECTしてもいいですか？
オイラのアスコをUPDATEしちゃうよ？

94 ：

INSERT ERROR : 小さすぎます

95 ：

そーいやLINQではfrom句が頭のほうに行ったんだな。少しSQLの言語仕様の
不合理性に気付いたわけだ。

96 ：

>>1へ
DB板も活用してあげてください。

97 ：

>>91
なんか自分で欠点見つけて凹んだ挙句全否定しだしたらしいね

98 ：

へぇ…全否定することも無いのに。
コッド博士に感謝しまくりですよ。集合の取扱いが楽で良いわ。

99 ：

selectは色々できすぎて困るというのとか聞いたことがある
現行の実装でのそれはrelational algebraで定義されてる演算9種類分の仕事を一手に受けてるとか

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

アルファベットを全角で打つ奴が許せない (181)
プログラマ川柳 (124)
JavaScriptプログラマーだけど何か質問ある？ (184)
お前ら単価いくら？ (144)
フリー/SOHOプログラマの確定申告2010/2011 (720)
これからコードを書く人に絶対やって欲しいこと★3 (447)
--log9.info------------------
【�V】エイシン軍団を応援するスレ XI 【�V】 (611)
ぼきんちゃん　part1 (202)
■張田　京■ (122)
競馬見始めた頃まだ現役だった騎手 (158)
【北斗の】宮崎北斗【拳闘士】 (100)
【Darley】ダーレー・ジャパンpart8【Japan】 (741)
サクラバクシンオー応援スレ　その12 (154)
【競’s馬】ＫＥＩ’ｓ　ＢＡＲ【憩’S場】２４号店 (235)
メジロライアン＆ブライト産駒応援スレPart9.5 (211)
【沖厩舎】ﾜﾀﾅﾍﾞ観察日記21【渡辺薫彦】 (532)
どの競馬新聞が読みやすいか Part10 (211)
トーチュウ・中日スポーツ愛読者スレ (106)
小倉競馬場 (469)
【佐賀の】小山紗知伽【ですでしょ】 (979)
【ＧＣ】炎の十番勝負2013春 参加者スレ (107)
【酒を飲み】佐藤洋一郎 15【馬券は飲まれる】 (254)
--log55.com------------------
おまえら！初心者のために絵講座サイトつくれ！！ 3
同人よりトレスが叩かれる風潮はおかしい
絵初心者である営業マン達の成長過程を見るスレ
ここに書き込んだら何が何でも原稿へ向かうスレ 2
●実在の人物をリアルに描くには？
【絵描き専用】何が何でも大手になりたい◆795
触手孕ませ最下層から5年で壁に　第4子
四コマ漫画について語るスレ