SQLite 4 - 暇つぶし2ch

SQLite 4 ..

813:NAME IS NULL
07/03/20 05:08:59
ドトネトのラッパーのことは良く知らんが
C APIで言う
sqlite3_enable_load_extension()を呼んでおかなければならないのでは？

814:NAME IS NULL
07/03/20 19:19:00 zTNCfQkm
インサートした行の主キーってどうやれば取得できますか。
CAPIにそんな関数はあるんでしょうか。

815:NAME IS NULL
07/03/20 19:44:22
あった。。。。

long long int sqlite3_last_insert_rowid(sqlite3*);

816:NAME IS NULL
07/03/21 03:34:36 rOkkBTf+
全角のテーブルとかファイルとかは無理なんでしょか？

817:NAME IS NULL
07/03/21 12:14:06
できないと思った理由は何だ

818:NAME IS NULL
07/03/24 19:37:07 FENpG053
２３日午後１１時５５分ごろ、小田急小田原線の下り急行電車で、
東京都町田市の文科省初等中等教育局係長、大塚智尚容疑者（３６）が
女性会社員（２０）の下半身を触ったとして神奈川県警麻生署員に
迷惑防止条例違反（痴漢）容疑で現行犯逮捕された。当時酒に酔っており
「何もやっていない」と容疑を否認しているという。

819:NAME IS NULL
07/03/24 20:07:39
スレ違うよ。全然関係ないよ。

820:NAME IS NULL
07/03/25 13:32:50
test

821:NAME IS NULL
07/03/25 14:03:51
アクセス使えば良いのに。

822:NAME IS NULL
07/03/25 14:07:10
それだけは勘弁してくれ

823:NAME IS NULL
07/03/25 20:00:07
アクセスはあくせく働く人のデータｰベース

824:NAME IS NULL
07/03/25 20:14:51
うわーおもしろい

825:NAME IS NULL
07/03/25 20:53:08
マイクロソフト国の奴隷ども。苦しゅう無い。ただならアクセスを使ってやっても良いぞ。

826:NAME IS NULL
07/03/25 22:59:10
>821
64ビット環境でmdbをAccess以外の外部プログラムから読み書きする方法を教えてください。

827:NAME IS NULL
07/03/27 00:25:47 D35J0C06
コマンドラインで操作する sqlite-2.8.17 を FreeBSD 4.10 上で実行
したのですが、走りませんでした。

これは sqlite-2.8.17.bin がLinuxの実行ファイルだからでしょうか？
Linuxシステムでは問題なく動いたのですが……。

FreeBSD上で動かすにはどうしたらよいのでしょうか。

828:NAME IS NULL
07/03/27 00:55:12
>827
おまいさんのシステムにはmakeもccも入ってないのかね?

# 最近のFreeBSDはLinuxのバイナリも動かせると聞いたがそっちのが確実だよな
# ……ってかportsあるじゃん。

829:NAME IS NULL
07/03/27 09:13:29
いくらなんでも釣りだろ。バカすぎる。

830:NAME IS NULL
07/03/27 16:51:14
いちいちmake installなんてしないだろ。
pkg_add一発だよ。

このスレってアクセス買う金のない貧乏人の巣窟だな。
オラクル買うことは一生なさそう(w

831:NAME IS NULL
07/03/27 18:06:00
>>830
ずいぶん金銭にコンプレックスがあるようですね

832:NAME IS NULL
07/03/27 19:08:30
金で苦労してるんだろ
そっとしといてやれや

833:NAME IS NULL
07/03/28 00:12:55
この釣り場は「アクセス」このエサ使うと爆釣ですねｗ

834:NAME IS NULL
07/03/28 01:20:26
GROUP BY のパフォーマンスに関して

CREATE TABLE addressbook(address TEXT COLLATE NOCASE,job TEXT);
CREATE INDEX idx_addr_job ON addressbook(address,job);

こういうテーブルがある時、次のクエリーではインデックス idx_addr_job が適切に使われる。

EXPLAIN QUERY PLAN SELECT job, COUNT(address) FROM test WHERE address='東京都' GROUP BY job;

0|0|TABLE addressbook WITH INDEX idx_addr_job ORDER BY

しかし、次のクエリーでは GROUP BY job にインデックスが使われないので

EXPLAIN QUERY PLAN SELECT job, COUNT(address) FROM test WHERE address like '東京都%' GROUP BY job;

0|0|TABLE addressbook WITH INDEX idx_addr_job

次のような書き換えを考えてみた。

CREATE INDEX idx_addr ON addressbook(address);
CREATE INDEX idx_job ON addressbook(job);

案１：ROWID を使ったサブクエリー
EXPLAIN QUERY PLAN SELECT job, COUNT(address) FROM test WHERE ROWID in
( SELECT ROWID from addressbook WHERE address like '東京都%') GROUP BY job;

0|0|TABLE addressbook USING PRIMARY KEY
0|0|TABLE addressbook WITH INDEX idx_addr

案２：EXISTS を使ったサブクエリー
EXPLAIN QUERY PLAN SELECT job, COUNT(address) FROM test WHERE EXISTS
( SELECT * from addressbook WHERE address like '東京都%') GROUP BY job;

0|0|TABLE addressbook WITH INDEX idx_job ORDER BY
0|0|TABLE addressbook WITH INDEX idx_addr

どっちの方が速いだろうか。

835:NAME IS NULL
07/03/28 01:32:15
ダミーデータでも作って実際に計測してみればいいじゃん

836:NAME IS NULL
07/03/28 09:16:28
アクセスなら悩まなくても最速だ。

837:NAME IS NULL
07/03/29 01:08:44
最速でデータ破壊ｗｗｗ

838:NAME IS NULL
07/03/30 05:10:54
C#のSystem.Data.SQLiteの事はこのスレでいいんですかね。

839:NAME IS NULL
07/03/30 11:52:26
Visual C# 2005 Express Edition で ADO.NET 2.0 Provider for SQLite と、 SQL Server 2005 Compact Edition とでは、Desktopアプリではどっちが使い勝手が良いですかねー？元データはWebからCSVダウンロードして取り込む予定です。

840:NAME IS NULL
07/03/31 00:03:25
>839
流石にVC#と組ませるならSQL Serverの方に軍配が上がるだろうなぁ。

841:NAME IS NULL
07/03/31 12:18:12 wYZslmRj
>>840
それは何故ですか？

842:NAME IS NULL
07/03/31 15:15:21
VC#との組み合わせっていうか、
ADO.NET経由でSQL Server系のDBより使い勝手のいいDBって無いだろ。

既存RDBMSがあるとか、ライセンスフィーが出せないとか、技術者があつまらないとか、
そういうことでSQL Server系を選ばないことはあったとしても、
「どっちがいい？」って聞かれたら普通はSQL Server系を選んでおくのが無難だ。

ADO.NETとかADOとかでつまずいたとき腹たつぜ？

843:NAME IS NULL
07/03/31 15:18:41 kitDOn2Q
>>842
両方使って比較してみてそう思ったのですか？

844:NAME IS NULL
07/03/31 15:24:54
>>842
まるで世の中の全てのDBMSを試したかのような台詞ですねｗ

俺は両方使ったことあるが（VC#じゃないけど）一長一短だと思うな

845:NAME IS NULL
07/03/31 15:33:35
>>844
具体的な長所と短所を教えてください。

846:NAME IS NULL
07/03/31 16:22:39
参考にならないスレだなあ。もういいです。

847:NAME IS NULL
07/03/31 17:54:56
SQLite は C API 経由で使わない限り、他の DB に比べてメリットは薄いと思う。

848:NAME IS NULL
07/03/31 18:43:23
>>847
kwsk

849:NAME IS NULL
07/03/31 19:30:44
一般論として、問題が起きたときに自己解決できない人はサポートのある製品を選択
したほうが良いかもしれないね。

850:NAME IS NULL
07/03/31 21:26:45
>>848
だから、
C API経由で使うとメリットある。
それ以外だと、他のDBと対等ということ。

851:NAME IS NULL
07/03/31 21:31:08
>>849
サポートあっても高いじゃん。
あれじゃ、ごく普通の一般家庭の人が
聞くレベルじゃないと思う。

852:NAME IS NULL
07/03/31 22:21:15
Cにこだわる理由が不明。

853:NAME IS NULL
07/04/01 00:01:25
軽さこそ正義

854:NAME IS NULL
07/04/01 00:05:16
○○こそ正義。

はいはい。自分の好きな単語入れてね。あーくだらね。

855:NAME IS NULL
07/04/01 00:05:58 ids7C6Ys
女は見た目こそ正義

856:NAME IS NULL
07/04/01 00:08:03
なんでも正義

857:NAME IS NULL
07/04/01 00:13:59
>>851
そうです。ごく普通の一般家庭の人は SQLite です。

858:NAME IS NULL
07/04/01 00:25:24
高中正義

859:NAME IS NULL
07/04/01 00:25:36
>>850
Perl + DBD::SQLite でめちゃくちゃ便利に使ってる俺は特殊ということか?

860:NAME IS NULL
07/04/01 00:59:32
>>859
それはPerlがSQLite

861:NAME IS NULL
07/04/01 01:00:13
俺様こそ正義

862:NAME IS NULL
07/04/01 01:01:59
ごめん途中で送信しちゃった

>>859
それはPerlがSQLiteをC API経由で使ってるんだから、
>>850の言うところのメリットのある使い方だと思う

863:NAME IS NULL
07/04/01 01:11:51
>>862
「C API経由」でない使い方のほうを教えてくれ

864:NAME IS NULL
07/04/01 01:32:13
他のどんな方法も、結局は C API を経由するんだから
C API を直接使うのが一番ってこと。

C++ でのラッパーくらいならいいけど、Perl だの
python だので使うなら SQLite にこだわる必要ゼロだからね。

865:NAME IS NULL
07/04/01 02:18:52
そうでもないよ

866:NAME IS NULL
07/04/01 03:06:37
ロッキングマンドクサ、でもGDBMは嫌、という向きにはSQLite以外に何がある？

867:NAME IS NULL
07/04/01 03:32:49
>>864
もうちょっと詳しくお願いします。
例えて言うなら、「どうせバイナリになるんだから、Cなんか使わずに
最初からバイナリで打ち込んだほうが良い」みたいな感じですか？
どうも今ひとつメリットと呼んでいるものの実体が理解できないのです。

868:NAME IS NULL
07/04/01 11:14:08
>>867
例えばネットワーク越しに会話するサーバタイプのDBMSなら
ネットワーク機能のある言語ならその言語自身でドライバが書ける。
Javaのtype4ドライバやADO.NETのようにね。
（ま、どっちみち低位のランタイムレイヤはC/C++で実装されていたり
するわけだが）

一方SQLiteはあくまでCの組み込み用ライブラリであって、多言語からの
利用は全てそのラッパの形にならざるを得ない
ってとこじゃないのかな。

だからと言って他言語からの利用が無意味だとは全く言えないはず。
Perl他の動的言語でDBMが十分有用である（これもCライブラリのラッパだ）
ことを見ても分かる。

869:NAME IS NULL
07/04/01 13:15:47
SQLiteのテストは全てTclで書かれていますが、それも否定するんですかあ？

870:NAME IS NULL
07/04/01 13:56:18
SQLiteはもともとはTclの拡張だった。それが他からも使えるように
分離したのがCのAPI。組み込みというのは、アプリケーションに内蔵
するという意味だけで、別にCだけが組み込みっていうわけじゃないよ。

871:NAME IS NULL
07/04/01 14:17:13
C API は、PerlとかPythonから呼び出せるのだから、

何を使おうが、C APIを使っていることになる。

872:NAME IS NULL
07/04/01 14:26:33
PHP(PDO)をyum＠CentOSでバージョンアップしたら
SQLite3のDBファイルが読み出せなくなってしまった・・・ orz
旧バージョンでdumpして再構築したら読めるようになったけどさ・・・
マイナーバージョンアップで互換性が無くなるって、一体、どうよ？

ファイルコピーするだけでバックアップ取れるのが楽ちんだったけど、
もうMySQLに逝きます。MyISAMなら、MySQLでもファイルコピーで済むし。

873:NAME IS NULL
07/04/01 16:12:56
>>872
それは PHP の問題であって SQLite3 の問題ではない。

874:NAME IS NULL
07/04/01 16:18:07
>>873
PHPのどのような問題なんですか？
もうちょっと詳しくお願いします。

875:NAME IS NULL
07/04/01 18:57:39
＞MyISAMなら、MySQLでもファイルコピーで済むし。

ちょっ、おま、うぇうぇうぇ

876:NAME IS NULL
07/04/01 20:59:54
>>864
ワケワカンネ
Perl でやるなら DBD::SQLite を使うんじゃなくて
Perl コード中に直接 C ソースを書けってか?

877:NAME IS NULL
07/04/01 21:01:29
>>871
だったら、C API を使っていない使い方って何?

878:NAME IS NULL
07/04/01 21:03:37
DBD::SQLiteがC APIを使っているだろ。

879:NAME IS NULL
07/04/01 21:08:19
しかしおまえらよく釣られるな。

880:NAME IS NULL
07/04/01 21:15:15
どう考えても >>864 なんか屁理屈だろ。こんなアフォにいちいちかまうなよおまいら。

881:NAME IS NULL
07/04/01 21:20:20
C APIを直接呼ぶのは可能だが、

はっきりいって、使い勝手が悪いので
やめたほうが良い。

SQL文字列を渡すときなんか、ポインタと、
文字列のサイズを渡さなきゃならないんだぜ。

メモリも自分で確保、開放しなきゃならんし、
サイズ設定ミスると、メモリ用破壊されるし。

効率が悪すぎる。

882:NAME IS NULL
07/04/01 21:29:49
でもそれCではふつうのことだよね
LLに慣れちゃうとえらい面倒だけど

LLのwrapperを書いた人はえらいなぁ

883:NAME IS NULL
07/04/01 23:30:21
>>881
> SQL文字列を渡すときなんか、ポインタと、
> 文字列のサイズを渡さなきゃならないんだぜ。

std::string使って
str.c_str(), str.size()
を渡すだけ。

ま、マンドイのは事実だがな。

884:NAME IS NULL
07/04/01 23:39:05
何でマジレスしてんの？バカ？

885:NAME IS NULL
07/04/01 23:41:42
>>878
だから、C API を使ってない使い方って何?

886:NAME IS NULL
07/04/02 00:08:54
たとえばPerl、DBD介しちゃったら、SQLiteにこだわる必要ないじゃん
MySQLのほうが速いし、Postgresqlのほうが高機能だよ

887:NAME IS NULL
07/04/02 00:11:31
>>886
クライアントサイドアプリケーションの場合配布コストだのなんだのまで考える必要があるんだが。
馬鹿なら黙って死んどけ。

888:NAME IS NULL
07/04/02 00:13:01
>>886
またおまえか

889:NAME IS NULL
07/04/02 00:21:34
エイプリルフールは終わりましたよー。

890:NAME IS NULL
07/04/02 00:42:14
>>883
> std::string使って
> str.c_str(), str.size()
> を渡すだけ。

Cじゃないだろｗ

891:NAME IS NULL
07/04/02 00:43:47
>>886
> たとえばPerl、DBD介しちゃったら、SQLiteにこだわる必要ないじゃん
> MySQLのほうが速いし、Postgresqlのほうが高機能だよ

意味わからんｗ

その理屈なら、C言語でもSQLiteにこだわる必要ないということになるじゃん。

自分が何を言っているのか良く考えてから発言しろｗ

892:NAME IS NULL
07/04/02 00:53:52
>>886
>MySQLのほうが速いし・・・
SQLiteのほうが速いだろう

893:NAME IS NULL
07/04/02 01:17:43
>>890
別にC APIはC++から直接呼べるし
Cでコーディングする必要は無い。

894:NAME IS NULL
07/04/02 02:42:56
>>886
マジレスすると、いちいちサーバを立てなくて良いとか
プラットホーム問わずファイル1個コピーするだけで DB 移設できるとか
そういうメリットは…?

895:NAME IS NULL
07/04/02 03:14:33
プラットホームを変えるってそんなによくあることなのかな？

896:NAME IS NULL
07/04/02 06:57:23
プラットフォーム間で互換性があるというメリットと、
バージョン間で互換性がないというデメリット、どちらをとるべきだろうか。

897:NAME IS NULL
07/04/02 07:00:38
プラットホームを変えることは滅多にないだろうけど、
ファイル1個コピーするだけで移設できるメリットは大きいな

898:NAME IS NULL
07/04/02 07:00:52
SQLiteはプラットフォーム間で互換性があるのだが？

899:NAME IS NULL
07/04/02 11:00:43
>>896
またお前か！

900:NAME IS NULL
07/04/02 11:49:17
自分の頭が悪いのが全ての原因だとまだ判らないらしい

901:NAME IS NULL
07/04/02 12:36:57
>>898
誰もその事実を否定などしていないと思うが、
君はいったい誰に対して疑問を投げかけてるのだ?

902:NAME IS NULL
07/04/02 13:53:58
クロスプラットフォームのアプリケーションを作るときだってあるんだよ。
SQLiteの狙ってるポジションはベターBerkeleyDBじゃないの。

903:NAME IS NULL
07/04/02 14:15:03
Mozilla のプロダクツが SQLite を選んだのもまさにそのへんが大きいんだろうね。

904:NAME IS NULL
07/04/02 14:59:50
perlやPHPで使う場合ってほとんど、Webアプリケーションだよね
それこそ、プラットフォーム云々なんて関係ないじゃん

905:NAME IS NULL
07/04/02 15:14:29
>>904
Windowsで開発して、Linuxで運用するという場合もあるよ。

906:NAME IS NULL
07/04/02 15:33:42
>>905
氏に晒せ

907:NAME IS NULL
07/04/02 15:37:38
きちがいが一人混じってますね

908:NAME IS NULL
07/04/02 15:43:25
>>907
気にするな、きちがいはどこにでもいる。

909:NAME IS NULL
07/04/02 15:54:59
そんなわけで、今、おまいらに試されているのはスルー力だ。

910:NAME IS NULL
07/04/02 16:12:50
マカこそ正義、ウィンドウズは悪ってのと変わらないな。頭悪い。

2から3でsqlite dbファイルが壊れると言い続けるアクセス廚の方がマシだ(w

911:NAME IS NULL
07/04/02 16:15:48
>>910を読んで、マカ死ねの人と2→3でファイル壊す人が同一人物だということが判りました

912:NAME IS NULL
07/04/02 16:51:15
>>902
レモンで何が作れるか考えたらこうなったってだけで、
最初からDBが作りたかったわけじゃないでしょ。
SQLのパースって練習問題によくあるもんね。

913:NAME IS NULL
07/04/02 17:31:04
最初から作りたいと思っていたかどうかなんて、ちゃんとしたものかどうかには関係ないと思うよ

914:NAME IS NULL
07/04/02 18:24:01 PxO7et1m
WEBサーバ上に設置したSQLiteってサーバ外からは接続できるのですか？

915:NAME IS NULL
07/04/02 18:41:50
>>914
設定次第

916:NAME IS NULL
07/04/02 19:47:02 PxO7et1m
>915
うーん、わかりません。
phpにてsqlite_openではどうもサーバの内部にしかアクセスできないようですが。
具体的な方法をご存知でしたらお願いします。

917:NAME IS NULL
07/04/02 21:58:46
おーい、こいつの日本語が理解できるエスパー呼んできて!!!

918:NAME IS NULL
07/04/02 23:09:34
>>914
率直に言って無理

919:NAME IS NULL
07/04/02 23:33:44
>>917
すいません。ここにはエスパーがいると聞いてやってきたのですが無理でしたか。

920:NAME IS NULL
07/04/03 00:37:24
SQLiteのリスナープロセスｷﾎﾞﾝてか？それこそ、他のRDBMSに対するアドバンテージなんて皆無だろ

921:NAME IS NULL
07/04/03 09:03:22
マカって本当に馬鹿だな。

922:NAME IS NULL
07/04/03 17:27:04
出来ないっていうと負けた気がするから言わないだけ

923:クリックで救われる名無しさんがいる
07/04/03 18:54:23
自分はSCSIでマウントしてるよ

924:NAME IS NULL
07/04/03 20:59:43
>>914
> WEBサーバ上に設置したSQLiteってサーバ外からは接続できるのですか？

君は基本的なことを勘違いしているようだね。
勉強して出直し。

925:NAME IS NULL
07/04/03 21:26:24
>>924
君は基本的なことを勘違いしているようだね。
勉強して出直し。

926:NAME IS NULL
07/04/03 21:32:50
なんという殺伐とした空気。
これぞSQLiteｽﾚ。

927:NAME IS NULL
07/04/03 23:07:00
馬鹿が大勢集まっている状態を「殺伐」と表現するのは正しくないと思う

928:NAME IS NULL
07/04/03 23:49:16
>>925
nfs や samba でマウントとかそういうことを言いたいのか?

929:NAME IS NULL
07/04/03 23:51:24
ネットワークマウントされてる場合ってロッキングがヤバくね？

930:NAME IS NULL
07/04/03 23:57:22
超やばいよ

931:NAME IS NULL
07/04/04 00:31:42
マカはファイルロックとか考えずに使っているだろうな。

932:NAME IS NULL
07/04/04 01:09:03
マカ(笑

933:NAME IS NULL
07/04/04 02:32:31
マカ不思議

934:NAME IS NULL
07/04/04 12:49:21
黙ってアクセス使えば関係ない。

935:NAME IS NULL
07/04/04 13:28:20
でも、アクセス権がありません。

936:NAME IS NULL
07/04/04 14:23:03
>>929
やばいかどうかは実装によるのでは
SQLite がどうなのかは知らんが…

937:NAME IS NULL
07/04/04 15:13:57
SQLiteの実装のことは、あまり考えたくないな…。
何事もありませんように。

938:NAME IS NULL
07/04/04 15:28:00
技術音痴なマカだな。

939:NAME IS NULL
07/04/04 15:45:39
>>929
やばいかどうかは (その OS の) NFS の実装によるのでは
SunOS の NFSv3 以外がどうなのかは知らんが…

940:NAME IS NULL
07/04/04 15:48:28
昔の人乙ｗ

941:NAME IS NULL
07/04/04 15:58:03
んじゃ、NFSv4で安心ってことか。

942:NAME IS NULL
07/04/04 16:33:41
NFSv4でも不安。
NFSv3ではかなり不安。
それ以前のNFSや他のファイル共有では不安なんてレベルじゃねぇ

943:NAME IS NULL
07/04/04 17:19:03
なんつーかさ、SQL エンジンとネットワークサービスの区別も
できないような根本的な厨がいるけど、意外とそういうのが
IT ゼネコンのえすいーｗだったりするんだよなｗｗｗｗｗ

944:NAME IS NULL
07/04/04 18:46:04
と、根本的な厨が申しております。

945:NAME IS NULL
07/04/04 20:13:43
と、三下えすいーｗが申しております。

946:NAME IS NULL
07/04/04 23:01:57
担当者がマカだったりして基地外な要求とかよくある話。

947:NAME IS NULL
07/04/05 00:33:10
○○省に居たよ、そういうヤツ

948:NAME IS NULL
07/04/05 00:52:50
福建省？

949:NAME IS NULL
07/04/05 02:21:27
今省庁常駐のPLを総研が募集してるなあ。実務よりスペック重視だから、トンデモばかりだろう。

950:NAME IS NULL
07/04/05 02:26:22
どれだよｗ
Wikipedia項目ﾘﾝｸ

PL
出典: フリー百科事典『ウィキペディア（Wikipedia）』
* ポーランド共和国の国名コードおよびccTLD
* ポーランド語のISO 639-1言語コード
* 製造物責任 (Product Liability) ⇒製造物責任法（PL法）を参照
* パシフィック・リーグ (Pacific League)
* パイロットランプ (Pilot Lamp)
* 損益計算書 (P/L,Profit and Loss Statement)
* PLフィルターは偏光フィルターのこと（Polarize から）
* パーフェクトリバティー教団（PL教団）
　o 同教団系の学校法人PL学園
　o 同教団の宗教行事である教祖祭PL花火芸術（PL花火大会）の略称の一つ。
* Perlスクリプトファイルによく使われる拡張子（～.pl）。
* アイピースの種類でプルーセル形式。
* 日本の駅ナンバリング制度で、神戸新交通ポートアイランド線の南公園駅～北埠頭駅間の環状運転部を表す。
* ピンク・レディー
* 海上保安庁で大型巡視船(Patrol vessel Large)のこと。ヘリコプターを積んでいる巡視船はPLHとなる。
* 包装明細書(Packing List)
* PL顆粒、サリチルアミドやアセトアミノフェンを主成分とする総合感冒剤。
* 体積の単位ピコリットル（pl）

951:NAME IS NULL
07/04/05 08:47:18
ピンクレディーに決まってんだろ。

952:NAME IS NULL
07/04/05 10:35:00
どう考えてもプロジェクトリーダーだろ、って思ったけど
英Wikipedia見ても載ってねーのな。マイナーな和製略語か。

URLﾘﾝｸ(www.google.co.jp)

953:NAME IS NULL
07/04/05 10:57:07
プロジェクトマネージャだしな。
リーダは役職無しと同等。

954:NAME IS NULL
07/04/05 12:36:36
今省庁常駐のピンクレディーなら募集してほしいな。スペック重視で。ｗ

955:NAME IS NULL
07/04/05 20:00:54
むしろ見た目だろ。
アクセスのパッケージも格好いいし。

956:NAME IS NULL
07/04/06 15:07:19
じゃあ SQLite のかこいいパッケージを作ろう!
ってことで誰かたのむ…