DBの話題
PHP+PerlからのWEBPROGなのでDBはMySQLかPostgreSQLなのでほかの影が薄い
Oracle9iとOracle9iASは別物かと思っていたがどうなの?
XMLはPostgreSQLではどうするつもりなの
(゚Д゚)ハァ? なのでsageます オラクルでCSV出力をシェルからする方法を教えてください。
なじょです。
Oracle8iです。 Sql*Plus を使えばいい。
詳細は
http://www2.odn.ne.jp/~cag07740/tech_info/oracle_ans6.html
を参照。 漏れも聞きたいけど、cronでシェルスクリプトを起動して
CSVにしたい場合は?
PL/SQLで関数書いて、sqlplusで実行? Sql*Plus で実行させたい内容をファイルに書いて、
sqlplus USERNAME/PASSWORD @FILENAME
を実行すればいい。cron で定期的に実行したい場合には上記コマンドを
直接 crontab に書くか、shell script 中に書けばいい。
例えば makecsv.sql というファイルに
spool /tmp/hoge.csv;
SELECT col1 || ',' || col2 FROM hoge;
spool off
と書いて、
sqlplus scott/tiger @makecsv.sql
を実行すれば、makecsv.sql ファイルの中の命令が実行される。 RDBMSもいいけど、BarkleyDBもいいよ。
早いしトラブル知らずの頼りになる奴 web上で2万人程度の会員管理を作るとすればperlでは無理ですよね?
検索に時間がかかるという面で。
どういったDBを使うのが最適なんでしょうか? >>13
ちと意味不明、プレーンテキストでは無理ってことですか?
2万件程度だとやり方やアクセス頻度にもよるけど大丈夫だと思う
よ、どのDB使うにしたってperlはインターフェースとして
使えるのだが。。。
実際にperl+PostgreSQLで10万件/日レコード
追加くらいのDBを管理してるし。。。 Oracle8i なんですけど、すっげーでっけーテーブルHOGEがあります。
けっこう検索に時間がかかったりするんですけど、
> analyze table HOGE estimate statistics sample 30 percent
この30percentって、どこまでも数字大きくしちゃって良いの?
解析の時間が増えるのは構わないんだけど。 ZSQLMethodで (select *** from **** where *** and ***)
という、select文を作り、Z Srech Interface を使用しHtmlファイルをはきださせています。
その機能(where句でデータを抽出)はちゃんと働いているんですが、
データ抽出後の画面で、データをテキストボックスにはきだし、
修正し、DBへinsertしたいと考えているのです。
だれかおしえてくれぽ
それにはPythonを使用しなければならないのかな、
と思い質問をさせて頂きました。 >>13
必ずしもムリじゃねぇだろ。
1枚のファイルに全部つめこまずに回避すれば。
もちろん薦めるわけじゃないけどさ。 MySQLとOracle、selectの検索スピードはどちらが速いでしょうか? 検索エンジンのCGI作っててYahooのような木構造のカテゴリ分けを
DBで管理したいんだけど、どのような構成にすればいいでしょう?
↓今考えているのはこんな感じ。
------------------------------
id,path,name
------------------------------
artiste,,芸能人
singer,artiste,歌手
ayu,artiste-singer,浜崎あゆみ
morning,artiste-singer,モーニング娘
ツリー型掲示板のように、
pathではなくてpid(親ID)の方がいいかなぁ。
------------------------------
id,pid,name
------------------------------
artiste,,芸能人
singer,artiste,歌手
ayu,singer,浜崎あゆみ
morning,singer,モーニング娘
1byteだけのデータを格納するのに最適なフィールドの型って何でしょうか?
半角数字を一つだけ入れたいんです。
ちなみに私が使っているのはMySQLです。 >>27
レスありがとう。
数字なんでtinyintの方がいいのかな?と迷ってました。
ここで良いのかな…
DBで画像を扱う事できますか? 何となく間抜けな質問っぽい気がしますが
MySQLやPostgreSQLで毎秒十万アクセスされるような処理って耐えられますか。
というかここ質問アリなのだろうか…。 >>30
requery。
1秒に十万スレッド走るサーバを調達してまでなぜにMySQLやPostgreSQLなの?
>>32
フリーのDBってどのくらいきつい処理に耐えられるのかなーとか…。
でもやはり処理能力はハードウェア依存なのかな…? ハードウェアの能力を越える処理能力をソフトウェアで引き出したら、
チューリング賞もらえると思いまつ。 <血液型A型の一般的な特徴>(見せかけの優しさ・もっともらしさ(偽善)に騙され
るな!)
●とにかく気が小さい(神経質、臆病、二言目には「世間」、了見が狭い)
●他人に異常に干渉し、しかも好戦的・ファイト満々(キモイ、自己中心)
●自尊心が異常に強く、自分が馬鹿にされると怒るくせに平気で他人を馬鹿にしようと
する(ただし、相手を表面的・形式的にしか判断できず(早合点・誤解の名人)、実際に
はたいてい、内面的・実質的に負けている)
●本音は、ものすごく幼稚で倫理意識が異常に低い(人にばれさえしなければOK)
●「常識、常識」と口うるさいが、実はA型の常識はピントがズレまくっている(日本
の常識は世界の非常識)
●権力、強者(警察、暴走族…etc)に弱く、弱者には威張り散らす(強い者にはへつらい、弱い者に対してはいじめる)
●あら探しだけは名人級(例え10の長所があってもほめることをせず、たった1つの短所を見つけてはけなす)
●基本的に悲観主義でマイナス思考に支配されているため性格がうっとうしい(根暗)
●一人では何もできない(群れでしか行動できないヘタレ)
●少数派の異質、異文化を排斥する(差別主義者、狭量)
●集団によるいじめのパイオニア&天才(陰湿&陰険)
●悪口、陰口が大好き(A型が3人寄れば他人の悪口、裏表が激しい)
●他人からどう見られているか、人の目を異常に気にする(「〜みたい」とよく言う、「世間体命」)
●自分の感情をうまく表現できず、コミュニケーション能力に乏しい(同じことを何度
も言ってキモイ)
●表面上意気投合しているようでも、腹は各自バラバラで融通が利かず、頑固(本当は
個性・アク強い)
●人を信じられず、疑い深い(自分自身裏表が激しいため、他人に対してもそう思う)
●自ら好んでストイックな生活をし、ストレスを溜めておきながら、他人に猛烈に嫉妬
する(不合理な馬鹿)
●執念深く、粘着でしつこい(「一生恨みます」タイプ)
●自分に甘く他人に厳しい(自分のことは棚に上げてまず他人を責める。しかも冷酷)
●男は、女々しいあるいは女の腐ったみたいな考えのやつが多い(例:「俺のほうが男
前やのに、なんでや!(あの野郎の足を引っ張ってやる!!)」) >>34
だよな(大笑い)
33がそこまで何も考えてないやつだとは思わなかった・・・
ハードウェアに依存しないでパフォーマンスを発揮するソフトウェアって何だよ。 ツリー型掲示板を作ってるんですけど、ツリーの部分はDBだと遅そうなので、
IDだけを持つようにして、表示するときに、DBから1つ1つ取ってくるっていう
風にしてみたんですけど、何か間違っていますかねえ?
select * from 記事テーブル where id = 123みたいなものを100個くらい出してるんですけど。
他にもっといいやり方とかあるんでしょうか? あぁ。もうちょっと追加すると、
select * from 記事テーブル where parent_id = 123
で取ってくるっていうのだと、大きい枝は省略、みたいなことが出来ないので、
それぞれの記事に子供の数を記録するようにすると、updateが大変な気がするし(親を再帰的に更新?)
どうすればいいかなあ。 >>38
間違ってます。
>>39
子供の数は記録するんじゃなくて数えるべきだと思います。 やっぱりそうでしたか。
普通はDBでツリー型掲示板みたいなものを作るときはどんな感じにするんでしょうか? >>37
初心者ならそう思うこともあるんじゃ?
このソフト大量の処理させると止まるね=ソフトウェアの処理能力の限界が低い
と言う風に。
別に間違っちゃないんだけど。
あるいは、設計的に大量のリクエストが来ても大丈夫かどうか、と言う事を聞いているのかな?
それならYahooかどこかがMySQL使って運営されてるって事だからソフトウェア自体に大きな問題は無いと思うよ。
//ただ大きいシステム運営した事無いから毎秒10万っていうのがどれ程のものなのかさっぱりだが… >>41
>普通はDBでツリー型掲示板みたいなものを作るときはどんな感じにするんでしょうか?
MySQLメーリングリストでちょっと前に話題になっていたね。
データ構造をどうするか、という話題だったのだけど、参考になるんじゃない?
>>42
yahooがMySQLというのははじめて聞きました。「yahooがphp」の勘違いでは? >>42
>>43
google が MySQLだったはず。
MySQLは他の商用使用可DBと比べて、
色んなものを斬り捨てた代わりに速度は最速っぽいから。
レコードの追加も検索もね。 >>38
MySQLのメーリングリストには参加してないが……
書き込みを記録するテーブルと、親子関係を定義するテーブルを別に作るんじゃいか?
>>46
今時のRDBMSはどれも似たり寄ったりだよ。
極端には変わらない。
>>48
googleみたいなところでは、ギリギリの設計が必要だろうから、
「どれもかわらん」みたいなことは言ってられんだろう。
まあ、その辺の中小企業のサイトなら「どれもかわらん」だろうけど。 ていうか、GoogleでMySQL使ってるなんて話は聞いたことないぞ。
Googleくらい技術志向なら、インハウスのものを使ってるんじゃないか?
そもそもああいう検索エンジンでRDBMS使っている例ってあるのかな? 特定の実装に限定しないSQL全般を学ぶのに適した本でお勧めってありますか?
DBをはじめてみようと思ってFireBirdを弄っているのですが、
http://book.mycom.co.jp/MYCOM/html/book/4-8399-0889-3/4-8399-0889-3.shtml
この本はそれなりにDBを扱った経験のある人向けのようで、
ずぶの素人には多少わからない部分があるのです。
そこを補おうと探していて、以下の本を見つけたのですが、
http://www.dart-books.co.jp/books/SQL_To_Detasekkei.html
わかりやすくいのですが、他にもいろいろあるのでどれがいいのか…… >>53
よくそういう質問する人が居るんだけれど、特定の実装に左右されないSQLなんて勉強しても無駄だよ。
今時のDBプログラミングは99%拡張SQLあってのプロシージャだからね。
まずはいずれかのプラットフォームに標的を定めて取り組む方がいい。
>>54
無駄かどうかは場合によるでしょ。
どこぞのシステムを請け負いでやるような仕事が多ければ、特化した技術を磨くのがよい。
あとDBMSを組み込んで製品作る場合も特化するね。
逆にオープンソースなWEBシステムなんかだと、余り特化するとマズい。
商品として出すものだとサポート(動作の手取り足取り)がネックになるので
あまり多種のDBMSに対応することは営業上から避けるべきことも多いだろうが、
オープンソースものの場合、ターゲットDBMSは1種に絞ってもワンクッション置く作りに
する方が後々の苦労がすくない。これは開発者のパワーが特に足りない場合に効いてくるよ ━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━― CGI系で、RDBのセッション保持するにはどうするのですか?
一回一回exeが起動される度にRDBに接続するわけにいかないですよね? >>60
接続のコストが高いRDBを使うなら、
RDBと持続的接続するプログラムと連携するような
CGIプログラムを書けば良いのでは。