トップページ⇒prog
127コメント34KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001仕様書無しさん2007/05/26(土) 03:42:32
いいか、ここにSQL系のDBがあり数値型のフィールドにSQLで数値データを登録するプログラムがあったとしよう。
その数値データはデータソースのプログラムの段階ではコンパイル済みのバイナリデータである。
しかしそれをわざわざSQL用にテキストに変換してDBエンジンに送る訳だ。
送った先のDBではやはりテキストを解析して数値データに戻す処理がなされる。

そんな穴を掘って埋めるような事が今世界中のSQL系DBを使うシステムの内部で行われている訳だ。

なぜ数値を数値のまま送らない？
0002仕様書無しさん2007/05/26(土) 04:40:28
（ﾟДﾟ）ﾊｧ?
0003仕様書無しさん2007/05/26(土) 07:41:03
つ【オブジェクトデータベース】
0004仕様書無しさん2007/05/26(土) 09:06:17
リプレイス時に十分な検討期間が取れず
結局過去の仕様のまま移植するハメになると
汎用機まがいの固定長データ大盛りなシステムを
最新RDB＋．NET系言語で構築しなきゃならないこともざらにある

上流がアレな業界の仕事だからあきらめろ>>1
0005仕様書無しさん2007/05/26(土) 09:19:57
XMLDBなんてのはもっと酷い。DBの実体がテキストだからな。
0006仕様書無しさん2007/05/26(土) 09:25:45
つ【CLOB】
0007仕様書無しさん2007/05/26(土) 21:18:16
穴を掘って埋めるだけで金がもらえるんだから良いではないか？
000869式フリーPG ◆hND3Lufios 2007/05/26(土) 21:52:00
自分で掘った穴に落ちたり、人の掘った穴どころか溝に落ちたり、
調子に乗って掘ってたら地雷を掘り当てたりするから嫌なんだよなー。
0009仕様書無しさん2007/05/26(土) 22:12:46
ワリィ。その地雷追加したの俺だわ。
0010仕様書無しさん2007/05/27(日) 00:33:05
それくらいトランザクションの仕事量の中では屁でもない。
それ以前にSQLをプログラムに埋め込むこと自体を否定しなさい
0011仕様書無しさん2007/05/27(日) 01:18:44
>>10
激しく同意
0012仕様書無しさん2007/05/27(日) 05:53:17
>>10
（ﾟДﾟ）ﾊｧ?
kwsk
0013仕様書無しさん2007/05/27(日) 06:37:40
>>12
激しく便意
0014仕様書無しさん2007/05/27(日) 12:44:55
O/Rマッパとか。
0015仕様書無しさん2007/05/29(火) 23:32:40
マッパって言うと真っ裸ーニバルみたいな感じがして嫌
001669式フリーPG ◆hND3Lufios 2007/06/12(火) 23:21:50
a--------------------------


のmmだ
0017仕様書無しさん2007/06/13(水) 17:33:32
本来のデータ入出力の処理で言うとDBに直接コネクトしてバイナリデータの出し入れをして切断する
のが自然(ADOみたいな)なわけだが、

何の訳かSQLなんて非効率な方法が普及してしまって。
馬鹿でもわかる英語にしてやらないと駄目なんかね？

SQLのせいで関係演算が全く抽象化されていない（できない）のも問題だね。
0018仕様書無しさん2007/06/14(木) 21:36:03
する必要もないと思った。
0019仕様書無しさん2007/06/19(火) 01:48:56
バインド変数でバルク転送すればすげー速いよ。
002069式フリーPG ◆hND3Lufios 2007/06/27(水) 20:08:48
そして、65535行でずっこける。(OCIの場合）
0021仕様書無しさん2007/07/02(月) 11:36:20
…で、
>SQL系のDB
って何さ。

>>17
阿呆はファイルにでも書いとけ。
0022仕様書無しさん2007/07/02(月) 11:57:15
SQLを使ってデータを取得するDBって事だろう。
リレーショナルデータベースという言葉が出てこなかったんだよ。
0023仕様書無しさん2007/10/25(木) 21:50:04
>>1
PreparedStatement の場合どうなりますか？
0024仕様書無しさん2007/10/25(木) 23:51:26
それに加えてOracleのハード解析というプロセスがあるのだけれど…
0025仕様書無しさん2007/10/27(土) 01:52:49
システムは変換機能の追加でどんどん重くなるの法則
0026仕様書無しさん2007/12/07(金) 10:27:19
＞リレーショナルデータベースとSQLを使ってデータを取得するDB
定義が全く違うぞ。

SQLを使う以上穴を掘って埋める作業は永久に無くならない。
こりゃ新しいDB作るしか無いな。
なんでメモリ空間みたいにDBに直接アクセスするインタフェースが無いんだろう。
そこで関係演算も直接実行できれば良いのに、
いちいちSQL書いてjoinとか打たなきゃ行けないのか。
0027仕様書無しさん2007/12/07(金) 10:32:30
それと多分PreparedStatementとかORマッパとか使ってもDB側が
JDBC経由ではSQL以外の接続を認めてないと思うから、
最終処理はSQLを介してると思うけど、違うのか？

MySQLは多分そう。Oracleは知らん。
0028仕様書無しさん2007/12/07(金) 13:54:41
>>20
ＯＣＩって半分じゃなかったかね？
0029仕様書無しさん2007/12/08(土) 03:20:51
1の言うような問題点が解決したDBエンジンが誕生したとして、どんだけーのパフォーマンス改善が見込めるだろうか？
0030仕様書無しさん2007/12/08(土) 08:53:48
http://www.componentsource.co.jp/features/ag-tech/index.html

検索キーで利用するＤＢもあるよ。
ＳＱＬでも利用できる
0031仕様書無しさん2007/12/08(土) 10:36:15
パラメタライズドクエリは、バイナリのデータを送ってるんじゃないの?
0032仕様書無しさん2007/12/08(土) 11:08:46
>>1にはAS/400(iSeries)＋RPGの開発をお勧めするわ。
0033仕様書無しさん2007/12/08(土) 11:28:30
データをテキストに変換した場合、負担増となる個所は
　　CPU負荷
　　I/O負荷
　　ネットワーク負荷
の3点が考えられる

CPU負荷が問題になる可能性は、経験上除外して良い
I/O負荷に関してはデータ変換後にHDDに書き込む為、関係ない

ネットワーク構成
(a)データベース --- (b)アプリケーション --- (c)クライアント
Ⅰ. a-b-cが単一サーバの場合
　ネットワーク負荷は発生しない
Ⅱ.a-bが単一サーバの場合
　ネットワーク負荷は発生しない
Ⅲ.a-bが別サーバの場合
　高速なLANで接続されている為、問題なし


以上、どう考えてもSQLをバイナリに置換してもメリットは発生しません
0034仕様書無しさん2007/12/08(土) 11:38:11
SQLはそもそもが数学的な理論からはじまったひとつの宗教。
オブジェクト指向という宗教となじむかどうかなんて考えていない。
0035仕様書無しさん2007/12/08(土) 17:26:46
事実、本来する必要の無いデータ型変換にどんなに短くても処理時間がかかってるのは間違い無い。
それが全世界のサーバーで毎日数億回のトランザクションがなされていれば数ナノ秒のロスも問題になってくる。
0036仕様書無しさん2007/12/08(土) 17:55:48
そうナノ？
0037仕様書無しさん2007/12/08(土) 17:57:08
そうナノ。
0038仕様書無しさん2007/12/09(日) 08:16:51
そんなどうでも良いロス気にして仕事してたら何の仕事もできなくなるよ。
SQLは簡単だから、チームのみんなが理解できるから、開発効率が上がる、工数が減る。
そのメリットだけ見てりゃ良いじゃないか。もっと早い方法があったとして、それを理解するのに工数が増えるなら
誰も採用しないよ。バカ。
0039仕様書無しさん2007/12/09(日) 08:19:03
アメリカや海外のシステムがどんな仕様だろうが関係ないじゃないか。
俺らに重要なのは目の前の仕事をいかにこなすかだ。
0040仕様書無しさん2007/12/09(日) 23:06:23
>>38-39
お前はあらゆるシステムをPHPとVBで作ってれば良いよ。
0041仕様書無しさん2007/12/10(月) 00:00:23
それいうなら
HTTPもFTPもメールも全てテキストベースだぞ
0042仕様書無しさん2007/12/10(月) 00:13:46
まぁそれより、専門卒の頭の俺には

なんであんなに高速に検索できるのかがわからん
0043仕様書無しさん2007/12/10(月) 00:15:27
>>1
そんな亊言ったら、俺らの仕事は全てが全て　穴掘って掘った穴埋めてを繰り返してるだけだろ？
0044仕様書無しさん2007/12/10(月) 00:16:28
>>42
おまいは電話帳の中から相手の電話番号を何分以内で見つけられる？
0045仕様書無しさん2007/12/10(月) 00:37:14
テキストベースからバイナリベースに変更しても字句解析、意味解析は必要になるので
劇的に速くなるわけじゃないぞ
昔のBASICでいえば変数は7文字より1文字のほうが速いもんね！っていうレベルだ
0046仕様書無しさん2007/12/11(火) 01:59:07
いや、1が言ってるのはコンパイル後の話だから次元が違う。

>>41
その通り、インターネットを作った奴らが、
馬鹿でハードウェア的な効率重視の発想ができなかったから、
あらゆる分野で、無駄が蔓延ってる。

0047仕様書無しさん2007/12/11(火) 02:18:14
インターネット上には暗号はいかなる種類でも流しちゃダメよ♪
0048仕様書無しさん2007/12/11(火) 03:17:51
いいから日本語で書けよ
チョンは日本語書けるようになってから出直してこい
0049仕様書無しさん2007/12/11(火) 04:25:14
いいからどうしたら良いのか、代替案を挙げろよ。
現状に不満があるんだろ？
0050仕様書無しさん2007/12/11(火) 19:32:20
そうだな、例えばこのような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はこういった本質的に異なる操作を一緒くたにしているのが気に食わない。
0051仕様書無しさん2007/12/11(火) 20:12:35
select再現すんのが偉くダルそうだ
0052仕様書無しさん2007/12/11(火) 23:27:59
>>50
今のSQLより大分機能が落ちそうだな
0053仕様書無しさん2007/12/11(火) 23:35:48
GROUP BYしたサブクエリとかどういう関数にするんだろう？

普通にSQLを記述する方が効率的かつ可読性が高いと思うが。
0054仕様書無しさん2007/12/11(火) 23:38:40
>>53
そういう凝った SQL は書かない人なんじゃないか？
単純な構文でできることしか SQL でやらなくて、細かいデータ操作は
言語の中でごりごりやってる。
0055仕様書無しさん2007/12/11(火) 23:59:55
１万件中、9999件更新するような処理は言語でやってもいい様な気がするけど、
普通にデータを抽出して照会やら更新する作業はSQLが一番効率的だと思う。
0056仕様書無しさん2007/12/12(水) 00:51:39
可読性もあるけど速度優先しなきゃいけないような場合もあるしな
運用次第だろうけど使い分けが必要じゃね？
0057仕様書無しさん2007/12/12(水) 06:44:48
使い分けるとしても、あの>>50の様な言語仕様では
可読性と速度も両方期待できないが。

速度命ならRPGでも使えって話になりそうだし。w
0058仕様書無しさん2007/12/12(水) 08:25:46
可読性とか言ってる奴は永久にVBとPHPでシステム書いてれば良いよ。

SQLの唯一で最大の利点は馬鹿でもわかるという点だから、速度なんか
どうでも良いんだよ。
0059502007/12/12(水) 19:40:28
>>53
集計関数はDbObject.extractの後で
DbObject.sum(taA.fld3);
のようにして、定義してやれば良い。

50のソースを見て察しが付くとは思うがテーブルもフィールドもすべてオブジェクト化されているので、
サブクエリの場合は事前にテーブルオブジェクトを作る際に50の手順で作ったサブテーブルをテーブルオブジェクトにして
selectTableで指定してやれば良い。


たかだか5行のソースに可読性とか言ってる馬鹿には理解できないかもしれないが、
このような直接DBを操作するインターフェースがあればどんな複雑なリレーションの操作も
抽出条件もプログラムソースの側で扱うことができる。

SQLで複雑な抽出条件をfor loop等で構成するときにSQLがやたら長くなって、
エラーの出所がわからず苦労した経験は誰にでもあるだろう。
0060仕様書無しさん2007/12/12(水) 19:52:28
このスレマ板とは思えないほどレベル低いなｗ
0061502007/12/12(水) 19:52:34
SQLが関係演算の実装として不完全であることはRDBMSの生みの親のEdgar Codd
も指摘していた事実だ。
唯一の関係演算の標準化された実装であるSQLが不完全ならせめてDBエンジンを直接操作するインタフェースを用意して欲しい。

>>1はMSのADOのような実装の標準化を求めているようだが、ADOには関係演算に関する実装が無い。
俺はDBエンジンがSQLを解析した後にやっている操作を全てプログラムソースから直接実行できるようにして欲しい。
わざわざ不完全なSQLを介さないといけないのはRDBMSの理想からも外れてるし、
本来できるはずの操作もできなくしてしまっている。
OOPとRDBMSの親和性が無いのもそこに原因があると思う。
0062仕様書無しさん2007/12/13(木) 22:59:02
＞SQLで複雑な抽出条件をfor loop等で構成するときにSQLがやたら長くなって、

それはSQLが悪いと言うケースよりも設計がタコなケースがほとんどだと思うが。

あとover(partition by hoge_id)みたいなのはどーすんの？かなり助長になると思うけど。
正直なところSQL書ける人間からするとOOP風味ってウザいんだけど。

そして、おそらくRDBMS内SQLのオプティマイザのほうが
一般的なプログラマの９割以上効率的な実行計画を作成していると思う。

おそらく50の人はレアな１割に入る人間なんだろうと思うけどサ。

漏れは金融系の仕事しているのだけども周りのCOBOLerとかは
99%がヴァカって印象があるぞ。

そいつらにOOPさせるくらいならSQL使わす方が万倍はマシだ。
0063仕様書無しさん2007/12/14(金) 15:44:37
なあ、SQL本来の目的って、DBに対話アクセスするためのものじゃなかったの？

スピード云々なんて次元が違う話だと思うんだが。
0064仕様書無しさん2007/12/14(金) 19:49:18
全てのテーブルに削除フラグと削除日時、作成日時、最終更新日時の列があって、レコード数が億とかなってる。
これって普通なの？
0065仕様書無しさん2007/12/14(金) 19:55:12
間違いなく普通でない。
0066仕様書無しさん2007/12/14(金) 22:55:42
前半分はよくあるけど億はすごいな
年金とかかｗ
0067502007/12/15(土) 00:08:44
>>62
そんなオラクル依存の構文はSQLですらない。どんな機能であれ、OOPである限り、
いくらでも拡張できる。
0068仕様書無しさん2007/12/15(土) 00:15:14
階層的クエリはどうすんの？
0069仕様書無しさん2007/12/15(土) 08:18:10
>>67
あのoverはOracle依存ではなくDB2なワケだが。
50は本当にRDBMSを使った開発したことあるのか？
単にSQLが嫌いなDQNプログラマにしか見えんが。

いくらでも拡張できる、と言うならばSQLも同様にいくらでも拡張できるだろ。
ユーザー関数の記述にはSQLはもちろん、50の好きなOOPのC++、Java
で作成できるしな。w
0070仕様書無しさん2007/12/15(土) 09:35:39
ＳＱＬの素晴らしさを解らない奴は経験不足の学生あがりだけだろ

ストアド使ってもまだパフォーマンスが酷いのって設計が悪い場合がほとんど

反論ある?
0071仕様書無しさん2007/12/15(土) 10:27:29
＞わざわざ不完全なSQLを介さないといけないのはRDBMSの理想からも外れてるし

>>50がホザいているけど、どうしてコイツはAS/400で開発しないんだ？
OSがDBと融合されているから>>1や>>50の様な自称神プログラマーの
脳内理想通りにDBエンジンを直でドライブできるぞ。

正直漏れは飽きたし生産性が低いのでSQLﾏﾝｾｰだが。
0072仕様書無しさん2007/12/18(火) 22:25:16
集合を理解していない奴にSQLを書かせるな

カーソルで１行ずつ取り出して
CSVよろしく全行全カラムを扱う
クソPGのネスト地獄に付き合わされるからな
0073仕様書無しさん2007/12/19(水) 07:04:57
（自称）集合や関係演算を理解してるお前らがSQLに不満を抱かないのが不思議だ。
0074仕様書無しさん2007/12/19(水) 09:40:46
完璧だが少数のアプリでしか使えない独自規格より、
不完全でもどのアプリでも応用できる共通規格がましってだけだよ。

完璧な独自規格は多くの場合、開発者のオナニー。
本当にすばらしければ他のアプリも取り入れるだろうし、そうしたら移行する。
0075仕様書無しさん2007/12/19(水) 13:44:42
つ　LINQ
つ　HANDLER構文（MySQL限定？）
0076仕様書無しさん2007/12/20(木) 00:35:04
実際どんな演算がSQLで不完全なのか教えて欲しいんだが。
0077仕様書無しさん2007/12/20(木) 01:11:41
>73
んで、具体的になにが不満なわけ?

>>1の言ってる事は意味がよくわからんが、要するにストアドとかのDBオブジェクトとかを知らないだけに見える

さあ、全部論破できる自信があるぞ、かかってこい!スライム

本当はあれだろ、言語とかロジックに自信があったけど入社してみたらＳＱＬができないと話にならなくてバカにされて嘆いているんだろ?
0078仕様書無しさん2007/12/22(土) 22:43:39
>>73
昔は小学４年くらいで集合を教えられてたんだけどなぁ
今の集合は義務教育を終えても理解できない代物なんだ？

SQLで集合を表現する事に不満を感じたことはないよ
73は何が不満なワケ？

>>77
彼はスライムではない。スライムにおびえて町を出られない町人の一人だ。
設定されたセリフ「モンスター退治？そんなのできるわけねぇよ」
を繰り返して言うだけのね。
0079仕様書無しさん2007/12/24(月) 04:27:34
SQLに不満を持つのはいいが。
ク　ラ　イ　ア　ン　ト　に　と　っ　て　そ　れ　は　ど　ん　な　メ　リ　ッ　ト　が　あ　る　ん　だ　？

余計な工数がかかるだろが。
メンテナンスとか含めて考えると妥協できる程度じゃねーの？
0080仕様書無しさん2007/12/24(月) 11:03:30
事前に登録できないSQLに対して、ストアドプロシージャは無力だよ
0081仕様書無しさん2007/12/24(月) 15:04:38
どうみてもSQL否定派の負け

マイッタと言えよw

反論するなら具体的な対案くらいだせよ
アメリカの頭の良い連中が一生懸命作って市場でも受け入れられてるモノを否定するならそれなりの具体的な対案があるんだろ?

比較するモノが無いと優劣つけられん
0082仕様書無しさん2007/12/24(月) 15:06:40
汎用機とオープン系を比較して
オープン系が勝てるとでも思ってんの？
0083仕様書無しさん2007/12/24(月) 17:20:55
>>82
汎用機＋DB2　の環境を知らない人？
0084仕様書無しさん2007/12/24(月) 23:44:53
＞汎用機とオープン系を比較して

個人的には10年前の汎用機と今のオープン系だと
オープン系の方が障害少ない現実があるな。

単に汎用機を普通に扱える人間が激減しているだけだろうけど。
0085仕様書無しさん2007/12/27(木) 00:59:33
>>81
SQLに代わる対案を出す

エラベ ナンデモ ホゲテーブル　ドレ　ホゲテーブル.シャチクバンゴウ='012345';　

仮称：PYUT@言語
0086仕様書無しさん2008/01/03(木) 09:02:17
>>85
ぴゅう太ｷﾀ━━━━(Дﾟ(○=(ﾟ∀ﾟ)=○)Дﾟ)━━━━━!!!
0087仕様書無しさん2008/01/04(金) 11:51:12
シャチクバンゴウにﾜﾛﾀ
0088仕様書無しさん2008/05/03(土) 19:51:14
新スレ
0089仕様書無しさん2009/01/07(水) 02:48:26
固定長データが来たらマスタと突き合わせしてインデックスを更新して

なんてやっていたときに出会ったRDBの使いやすさに衝撃うけたけどな
0090仕様書無しさん2009/01/07(水) 07:34:49
SQLは確か数学のなんちゃら賞取った素敵な発明じゃなかったっけ？
0091仕様書無しさん2009/01/07(水) 10:27:57
>>90
http://ja.wikipedia.org/wiki/エドガー・F・コッド
当のコッド博士はSQLイクナイ！と言ってたらしい。
Oracleが先にできたから今でも生き残ってるんだね。
0092仕様書無しさん2009/01/12(月) 14:48:43
SQL終わったな。これからは俺QLを使ってくだされ。
0093仕様書無しさん2009/01/12(月) 15:29:17
彼女にINSERTしてもいいですか？

オマイラをDELETEしてもいいですか？TRUNCATEがいいカイ？

女子高生をSELECTしてもいいですか？

オイラのアスコをUPDATEしちゃうよ？

0094仕様書無しさん2009/01/12(月) 15:42:46
INSERT ERROR : 小さすぎます
009512009/01/14(水) 02:28:27
そーいやLINQではfrom句が頭のほうに行ったんだな。少しSQLの言語仕様の
不合理性に気付いたわけだ。
0096仕様書無しさん2009/01/14(水) 03:35:57
>>1へ

DB板も活用してあげてください。
0097仕様書無しさん2009/01/14(水) 16:32:36
>>91
なんか自分で欠点見つけて凹んだ挙句全否定しだしたらしいね
0098仕様書無しさん2009/01/21(水) 17:11:58
へぇ…全否定することも無いのに。

コッド博士に感謝しまくりですよ。集合の取扱いが楽で良いわ。
0099仕様書無しさん2009/01/21(水) 23:55:47
selectは色々できすぎて困るというのとか聞いたことがある
現行の実装でのそれはrelational algebraで定義されてる演算9種類分の仕事を一手に受けてるとか
0100仕様書無しさん2009/01/24(土) 21:03:00
もしselectに代わるものがあるのなら俺の頭の柔軟性がまだ残ってる間に出てきてほしい。
１０年後でも新しい概念を完全に理解できる自信はない。
必要になったら頑張るけど。
0101仕様書無しさん2009/03/15(日) 17:20:33
sage
0102仕様書無しさん2009/04/02(木) 22:21:44
オラオラage
0103仕様書無しさん2009/06/20(土) 18:04:13
いやそもそもだな、selectの対象になる表の宣言(FROM句)が列(フィールド)の後にあるってどういうことだよ。
表の宣言はselect、update、insert、deleteとは独立にされるべきだと思う。
0104仕様書無しさん2009/06/22(月) 09:59:10
どういうこと、って
そりゃ英文法がそうだから、としか。
0105仕様書無しさん2009/06/23(火) 12:52:17
あの頃(いつ?)の言語は、みんなそうだったんだ。

MOVE 5 TO A

とかな。

今、SQL を作ろうとしたら、処理順、つまり、FROM句からになると思う
0106仕様書無しさん2009/07/05(日) 18:51:21
すみません
誰か教えて下さいーー。

今、Accessのmdbデータを、SQL Developerで開こうとしてるのですが、
「システム表への読み取りアクセス権がありません。
AccessDBを変更してから再試行してください」
って出ちゃいます！！
ちゃんとユーザー名とパスワードは正しいのを入力してるはずなんですが、
どこをどうしたらSQL Developerで開けるようになると思いますか？
すみませんがどなたか教えて下さい！お願いします！！
0107仕様書無しさん2009/07/18(土) 18:17:17
SQL Developer で直接開けないんなら、Access 起動して SQL Developer の
データベースにアクセスして、mdb の内容をコピペすればいいんじゃない？
いくらなんでも Access では開けるでしょう
Access で開けなかったら、mdb に問題ありってことだ
0108仕様書無しさん2009/07/18(土) 18:26:23
くそ、見返したら１週以上前の書き込みか
0109仕様書無しさん2009/07/18(土) 19:30:29
質問ｽﾚでもないのに (つかそれ以前にｲﾀﾁ) 質問しちゃう莫迦に
嬉しげに答えようなんて思うから
そういう目に遭う
0110仕様書無しさん2009/07/18(土) 20:55:26
1週どころじゃねーだろ馬鹿
0111仕様書無しさん2009/08/20(木) 22:58:43
教えてください。
SQLプロファイラって停止させないと、プロファイラ画面閉じても動いているんですか？
0112仕様書無しさん2009/08/22(土) 10:56:14
>>111
こっちで聞け。
ttp://pc11.2ch.net/test/read.cgi/db/1231665917/l50
01131062009/09/22(火) 12:19:20
>>108 さん
すみません、答えて頂いたのに。。気がつかなくて・・・。
あと、質問スレでもないのに質問してすみませんでした。
答えてくれた人たちありがとうございます。
今後気を付けます、申し訳ありませんでした。
0114仕様書無しさん2009/10/22(木) 21:01:44
rollback
0115仕様書無しさん2009/10/22(木) 22:34:08
SQLは不完全な言語である。やはりコボルが完全な言語だ。
0116仕様書無しさん2009/10/23(金) 09:20:47
>>115
問合せ言語とプログラミング言語を比較する、その頭の悪さは生まれつきですか？
0117仕様書無しさん2011/04/23(土) 20:30:01.92
あくまでも経済性の原理が働いているだけ。
おまえらが書かなきゃならないコードは、大量生産品！
行数を書くのが仕事だ！
0118仕様書無しさん2011/04/29(金) 03:42:11.12
量産型なら簡易化されるもんじゃないの
0119仕様書無しさん2011/04/29(金) 10:29:13.17
>>118
よい指摘だが、簡易化できる新しい道具を作るのはおまえらには無理！
0120仕様書無しさん2011/04/29(金) 22:00:31.32
うむ、だからより簡単で楽になるものを待ってるぜ？
それはそうと
いつかきっとできるよね～　待ってま～す♪
あのCMちょっとムカつく
子供がそんな受け身じゃイカンだろうと。

大人はもう良いの夢も希望もとっくに無くなってるから
0121仕様書無しさん2011/12/23(金) 22:05:24.44
RDBで入れ子な構造扱うなら入れ子集合モデルも視野に入れるべき
円に見立ててrgt - lftしつつ、あいだは小数点で理論上は永遠にノード追加できるし
パス的なものなら経路列挙もありかもね
そもそもRDBには苦手なとこだからxmlDBを採用するってのもありか
0122仕様書無しさん2011/12/23(金) 22:06:27.88
ってかnosqlって流行ってんの？
0123仕様書無しさん2011/12/24(土) 00:33:19.76
特に流行ってる訳じゃないよな
0124仕様書無しさん2013/03/12(火) 16:03:23.52
【サラ金】 偽装請負だった奴ちょっとこい。年収172万円だった奴で450万円貰えるぞ！ 【特需ふたたび】
http://engawa.2ch.net/test/read.cgi/poverty/1363064038/
0125仕様書無しさん2014/06/26(木) 01:20:51.84
エンジニアにSQLと帳票やらすな。あと画面デザインも。
CやVBが絶滅したみてーにRDBとSQLも早く消えてくれねーかな。
帳票も消えて欲しいがあれは必要なのは認めるから
帳票は帳票専門職に丸投げできるようにしてくれよ。
0126仕様書無しさん2014/06/26(木) 05:05:14.67
何もできない”エンジニア”は要らんよ
0127仕様書無しさん2014/07/13(日) 02:33:12.97
>>125
投げりゃ良いじゃん
投げずにやっちゃうから、ああ出来るんだなって
■ このスレッドは過去ログ倉庫に格納されています